* Financial Services Cloud *

A few high-priority ones for a wealth management move: 

1. Person Accounts are a one-way door. Once enabled in production you cannot turn them off, and they merge Account and Contact into a single record, which forces account sharing to Controlled by Parent or Private and rewrites your legacy B2B sharing. Prove the whole migration in a full sandbox first. 

2. Automation and integration re-platforming. Every trigger, flow, validation rule, report, and integration built on the old Account/Contact split has to be re-pointed at the Person Account and FSC model. This is usually the biggest hidden effort. 

3. Relationship and household modeling. FSC value for wealth is the household plus reciprocal roles (client, spouse, beneficiary, POA, advisor). Design this up front, because it drives both sharing and rollups. 

4. Financial data model and rollups. Decide which FSC objects you actually need (Financial Accounts, Assets and Liabilities, Goals) and configure rollups such as AUM to the household. Adopt selectively rather than switching everything on. 

5. Licensing and compliance. FSC needs an FSC Permission Set License per user and costs more, so confirm license mapping and budget. Wealth is regulated, so plan advisor book-of-business visibility and evaluate Shield (encryption, field audit, event monitoring) and data classification early. 

Since you are already on Person Accounts plus Households, your data-model direction is right — the risk is mostly the sharing changes and re-platforming existing automation. 

if this helps, please mark it as the Best Answer so it helps the next person — thanks 🙂

Good catch, and you are right — that Location lookup does exist on Branch Unit, so let me correct my earlier framing. The reason it still gives you no related list is that the lookup is a standard/system relationship, and Salesforce does not expose a reciprocal related list on the standard Location object for it. For certain standard lookups (especially into system objects like Location), the add-this-related-list-to-the-parent-layout option simply is not offered — so you can see the lookup on Branch Unit but cannot surface it as a related list on Location. 

Two ways to get the view you want: 

1. Quickest: a report on Branch Units grouped or filtered by their Location field — an instant list of all branch units per location. 

2. Native related list: add your own custom lookup from Branch Unit to Location. A custom lookup does generate an addable related list, which you can then drop onto the Location page layout. 

So the standard lookup is real, it is just reverse-related-list blocked; a custom lookup or a report is how you surface it.

We solved this with two tax ID fields and two separate imports for the same object. 

Person Accounts store the SSN in one field (SSN__c). Trusts and other entities are business Accounts and store their tax ID in a different field (EIN__c). Two fields means the same number can live in both places without conflict. 

Each row in our custodian feed says what type of client it is (Individual or Entity), so we split the file into two imports before matching. Individual rows only search Person Accounts on SSN__c. Entity (trust) rows only search business Accounts on EIN__c.  

Example: Brenda's Person Account has 123-45-6789 in SSN__c. The Brenda Family Trust is a separate business Account with that same 123-45-6789 in EIN__c. When an update comes in for her individual brokerage account, it's flagged as an individual, so it only searches Person Accounts and finds Brenda. When an update comes in for the trust account, it's flagged as a trust, so it only searches business Accounts and finds the trust. Same number, no collision, because the flag decides where to look, not the number. 

For this to work for you, data feed has to tell you which rows are trusts and which are individuals (a registration type or account type field, something like "individual" vs "revocable trust"). If it has that, you're set. 

HI @Martin Dahlquist If the standard rollup settings are already enabled, no additional Flow is normally required. Activity rollups only work when the task is related through the expected relationship (for ex : the Related To (WhatId) points to the Financial Account and the Financial Account is correctly linked to the Person Account and Household). If tasks are being created in bulk through automation or an integration, verify that the WhatId and related records are populated correctly. If everything is configured correctly and the rollup still doesn't occur, it may be a limitation of how the tasks are being created or a product-specific issue worth checking in the debug logs or with Salesforce Support.