#Financial Services Cloud11 discutindo

@Sarah Chen

The reason the validation fires when you edit the Household in the relationship map but not when you create the Account Contact Relationship is that these are two different code paths writing to two different objects, and only one of them runs the membership validation. 

When you add a relationship through the Related Contacts list, you're creating an AccountContactRelation record. That's the standard association of a contact to an account, and it does not enforce Household membership rules, because an ACR is just a relationship link, not a membership assertion. Your CPA and attorney contacts, parented to their own accounts, link fine here.

When you open the Household group in the relationship map and save, you're invoking FSC's group membership logic, which writes to the AccountContactRelation with the Household context but runs through the FSC-managed validation that governs who can be a member of a Household. That validation enforces the rule you're hitting: in FSC, Household members are modeled as individuals, and FSC expects Household membership to resolve to Person Accounts (or the individual model equivalent). The relationship map's save path re-evaluates all members of the group against that rule, which is why it throws even when you made no change, it's validating the whole group membership on save, and your externally-parented business contacts fail that check because they aren't Person Accounts. 

So to your specific questions.

Is there a hidden Account-to-Account relationship created? Not exactly an Account-to-Account record, but yes, there's more happening under the covers than a single link. FSC's group membership and the relationship map operate on the group's member set, and the map's save recomputes and validates that full set. The ACR creation path skips that group-level validation entirely, which is the whole reason you see the discrepancy. It's not that one creates a hidden object the other doesn't, it's that one triggers the group membership validator and the other doesn't touch it. 

Is there no way to relate contacts to Households in FSC? You can relate them, you just can't make them Household members through the relationship map, and that distinction is the crux. The relationship exists and is valid at the ACR level. What fails is trying to represent professional contacts as members of the Household group, because FSC reserves Household membership for the individuals who belong to that household, not their external advisors. 

The approach I'd take: keep the professional contacts linked via AccountContactRelation, which you've already got working, and surface them at the Household level through a related list or a custom Lightning component on the Household record rather than through group membership. You get the household-level visibility the firm wants without triggering the membership validator, because you're presenting the relationships in the household context rather than asserting them as members. If the driver is really "we want to see the household's professional advisors in one place," that's a presentation problem, solvable with a related list or component, not a membership problem.

If you genuinely need these to behave as first-class relationships with reciprocal roles, FSC's Reciprocal Relationships (the party-to-party relationship model) is the sanctioned path, and you can configure role types like CPA and Attorney there. It's slightly more to maintain than your single-ACR wish, but it's the model-aligned way and it won't fight you on save.

Just wanted to share this in case someone else is looking for a solution — I recently needed to mass assign Interest Tags to Accounts

in the new Nonprofit Cloud, and here's what worked: 

You can use the Topic and Topic Assignment objects to do this, no Apex or Flow required.

✅ Steps to Mass Assign Interest Tags:

1. Open Data Loader
2. Export all Interest Tags:
   • Select "Show All Salesforce Objects"
   • Choose the Topic object
   • Export to get the full list of Topic IDs (each Interest Tag is a Topic)
3. Prepare your CSV for upload:
   • EntityId = the Account ID you want to tag
   • TopicId = the ID of the Interest Tag (Topic) you want to assign
4. Insert into Topic Assignment:
   • Back in Data Loader, select Insert
   • Again, choose "Show All Salesforce Objects"
   • Select the Topic Assignment object
   • Upload your CSV

That’s it! The tags will now appear on the Account records under the Interest Tags component. 

Hope this helps someone down the line — worked great for us!

@Ben Bolding

, did you ever identify a solution? 

, with Action Plans you don't create the tasks directly through a flow.  You create an Action Plan record, which then creates the tasks/events/etc. 

During the plan creation, these are the options you are given to determine who is assigned to the task that is created during plan execution. 

I have the same requirement as Ben, when a record changes, the owner of that record should be assigned the tasks defined in the action plan.  The person/integration changing the record is NOT the owner of the record.  

@Simran Singh the key is to separate case creation from email threading.

If the requirement is only "let the manager create a Case from an email," then Salesforce Outlook/Gmail integration can work. You can expose a Create Case quick action in the Salesforce side panel, and Salesforce docs confirm users can create Cases directly from the email side panel. Attachments can also be logged to Salesforce as Files, depending on the email integration setup (https://help.salesforce.com/s/articleView?id=sales.outlookcrm_side_panel_create_actions.htm&type=5) 

But if the requirement is "all future client replies must automatically stay on the same Case," then Email-to-Case needs to be part of the flow. Salesforce’s Email-to-Case threading works when outgoing Case emails and incoming customer replies are routed back through Email-to-Case. If replies only go back to the Account Manager’s personal inbox, Salesforce will not automatically attach those replies to the Case (Email-to-Case Threading) 

The scalable design is usually: use one central Email-to-Case routing address, then configure mail-system forwarding or a controlled forwarding process from the AM inboxes into that address. Once the Case is created, assign it to the right Account Manager using Flow, assignment rules, or a mapping based on the original recipient/customer/account. Salesforce documents Email-to-Case forwarding as the standard pattern for routing emails into Cases (Salesforce Help | Article) 

The one point to be careful with is the “send from the individual AM email” requirement. If the email truly goes out from the AM’s personal address and the customer replies only to that address, the reply will land in Outlook/Gmail, not automatically in Salesforce. You can show the AM as the owner/agent, but for automatic Case threading, the Reply-To path should route back to Email-to-Case. Salesforce also notes that the default reply From address can be the user’s address, so this needs to be tested carefully in your org (Default Email-to-Case 'From' address for replies to email) 

My recommendation is to use Outlook/Gmail integration for manual Case creation if needed, but use Email-to-Case as the system of record for the lifecycle. If the business insists on true personal inbox ownership for the full thread, then you are likely looking at a custom Microsoft Graph/Gmail API integration rather than standard Email-to-Case alone.

Bob — yes, you're not alone. We've heard the same from others navigating this with large SaaS vendors. Salesforce routing it through a legal addendum is pretty consistent with how they've handled similar requests. 

To your second question: beyond a formal addendum, other approaches that firms have used include a written questionnaire or attestation from the service provider acknowledging the 72-hour notification obligation, or documenting a risk-based vendor oversight decision if a contractual commitment isn't obtainable. The SEC gave some flexibility here — what matters is that your written policies reflect a reasonable effort to obtain that assurance and that you can demonstrate it during an exam. 

On the preparedness side, it's worth getting clear now on exactly what NPI lives in your Salesforce org — things like account numbers, SSNs, income data, credit info, or transaction history. If a breach occurs, Reg S-P requires you to notify affected individuals within 30 days of becoming aware, and the notice needs to clearly describe what information was compromised, the potential risk of harm, and what steps individuals can take to protect themselves. Knowing your data footprint in advance makes that process significantly less painful. 

For what it's worth, our team at LASER Credit Access works with financial institutions on Salesforce regularly and these compliance questions come up a lot. Happy to compare notes if it's helpful. Good luck on the deadline.