Every CRM marketing deck for two decades has promised a 360-degree client view. Most production deployments deliver a 90-degree view. The remaining 270 degrees live in spreadsheets, in the core banking system, in the advisor's head, and in a folder of PDFs nobody opens twice.
Financial Services Cloud (FSC) does not magically solve this, but it gets closer than most CRMs because the data model already aligns with how wealth advisors think. The Wealth Console, the standard Lightning app FSC ships, surfaces the model in a way that maps onto an advisor's actual workflow.
What "Client Profile" actually means in FSC
Client Profile is not a single object. It is a composite view that pulls from several:
- Person Account. The client's identity, contact details, KYC status, risk profile, segment classification.
- Household. The family-level summary, with net worth, total deposits, total investments.
- Financial Accounts. Every bank account, brokerage account, mortgage, and insurance policy the bank knows about.
- Financial Goals. What the client is saving for, with progress against each goal.
- Life Events. Recent and anticipated life moments that drive planning conversations.
- Activity History. Calls, emails, meetings, document sharing, recent transactions.
- Relationship Map. Connected family members, business partners, advisors.
The composite view is the Client Profile. The advisor sees one screen; the underlying data lives across seven or eight related objects.
The Wealth Console layout
The Wealth Console is a Lightning app, with the standard layout designed for an advisor's typical morning workflow:
Left panel: client navigator. A searchable list of the advisor's book, sorted by recent activity or by next-touchpoint date. The advisor scans the book and clicks the client they need.
Centre panel: client overview. The composite view, organised in tabs:
- Summary tab with net worth, asset allocation chart, recent activity.
- Accounts tab with the list of Financial Accounts and balances.
- Goals tab with each Financial Goal and progress.
- Relationships tab with the Actionable Relationship Center.
- Activity tab with recent and upcoming touchpoints.
- Documents tab with relevant client documents.
Right panel: contextual actions. Quick actions tuned to the client's current state. If a Life Event is unresolved, the right panel surfaces the recommended Action Plan. If a Goal is off-track, the panel surfaces a re-planning quick action.
The default layout works for most wealth-management orgs. Customisation comes in the form of additional tabs (estate-planning, charitable-giving, family-office reporting) and additional contextual actions per business line.
What goes wrong with default layouts
Two patterns kill advisor adoption of the Wealth Console:
Too much data on the Summary tab. The temptation is to show everything. Net worth, asset allocation, recent activity, life events, goals, holdings, relationships, all on one screen. The result is an unscanned wall of cards. Advisors give up and revert to spreadsheets.
Too many custom fields on Person Account. Implementation teams add custom fields for every business request. Within a year, the Person Account has 80 fields, none of which anyone consciously uses. Page-load times slow. Advisors stop scrolling. The data that mattered gets lost in the noise.
The fix for both is editorial discipline. The Summary tab should show 4 to 6 high-value cards. The Person Account should carry the 20 fields the advisor actually references. Everything else goes on secondary tabs or related-object views.
Risk profile and segment
Two custom-field patterns that almost every FSC wealth implementation needs:
Risk Profile. A picklist or numeric field capturing the client's risk tolerance (conservative, moderate, aggressive, or 1-to-10 scale). Drives portfolio construction, product eligibility, and compliance documentation. Captured at onboarding through a structured questionnaire, refreshed annually or after major Life Events.
Segment. A picklist capturing the client's value tier (mass affluent, HNW, UHNW, family office). Drives service-level expectations, advisor assignment, and pricing. Computed from Household total assets, with manual override for known cases.
Both fields show prominently on the Wealth Console summary. Both fields drive a significant amount of downstream automation. Both fields need a defined refresh process, not a "set at onboarding and forget" pattern.
The Activity History problem
Activity History is the second-most-common Wealth Console adoption killer. The default activity feed shows every call, every email, every task. For an active client with a 10-year relationship, the feed is overwhelming.
Three patterns that work:
Filtered default view. Show the last 90 days by default. Show all activity behind a "view all" link. The advisor sees the recent context they need; the historical context is one click away.
Activity Type emphasis. Filter by activity type. Show meetings prominently, calls less prominently, automated email sends collapsed. The advisor cares about advisor-touchpoint activity, not system-touchpoint activity.
Linked-object context. Each activity record carries a "regarding" field that links it to a Financial Account, a Goal, or a Life Event. The advisor sees not just what happened but what it was about.
The filtered, typed, contextual activity view is the difference between an advisor who reads the activity feed every morning and an advisor who never opens it.
Cross-device and the field-of-vision question
Wealth advisors work from desktops, tablets, and phones. The Wealth Console renders on all three; the field-of-vision changes dramatically.
On desktop, the 3-panel layout shows the navigator, overview, and contextual actions simultaneously. On tablet, the navigator collapses to a search field. On phone, only one panel shows at a time and navigation is sequential.
The implementation question: which fields are critical enough to survive the phone view? 2 fields per card, 6 cards per screen, is the rough budget on a phone-sized layout. Anything beyond that gets cut. The discipline forces the implementation team to identify what truly matters.
The pattern Sapota recommends: design the phone view first. The constraints there force the editorial discipline. The desktop view then expands the same data without adding new information density.
When the Wealth Console is not the right tool
For some advisor roles inside an FSC wealth implementation, the Wealth Console is not the primary surface. Three cases:
Operations and middle-office. Operations users need transaction-level views, account-level documentation, and bulk-update capabilities. The Wealth Console is client-centric; the operations surface is transaction-centric. Build a separate Lightning app for the ops team.
Compliance officers. Compliance users need filtered views across clients (all clients with KYC expiring this month, all clients with a sanctions hit). The Wealth Console is single-client; the compliance surface is multi-client. Build a compliance dashboard.
Branch bankers. Retail bankers need a different surface again. The Banking Console (FSC's standard retail-banking Lightning app) layouts differently: less emphasis on goals and net worth, more emphasis on transaction history and product cross-sell.
Each persona deserves a Lightning app tuned to their actual workflow. The Wealth Console is the wealth-advisor's tool. The other personas have their own.
Configuring the Wealth Console and Client Profile for an FSC rollout? Sapota's Salesforce team, certified on Financial Services Cloud Accredited Professional (AP-208), runs Console design, persona-specific layout, and field discipline on every FSC engagement. Get in touch ->
See our Salesforce service page for the team.
