Financial Services Cloud implementation: data model and phases

You implement Financial Services Cloud by settling the data model and security design first. Then you connect the systems that hold balances and policies, migrate clean data, and pilot with one team before expanding. Timeline depends less on the software than on your integrations, the state of your legacy data and how many lines of business go live together. Wealth, banking and insurance share the same foundation but differ in their source systems and compliance rules.

What are the phases of an FSC implementation?

Most projects run through five phases: discovery, data model and security design, build and integration, migration and testing, then a pilot followed by staged expansion. The order matters more than the labels, because each phase depends on decisions made in the one before.

• Discovery: document how advisors, bankers or agents work today, which systems hold client and account data, and which rules compliance enforces.
• Design: decide the relationship model, the object lineage, the sharing model and which system owns each balance or policy field.
• Build and integrate: configure households, financial accounts, rollups, action plans and page layouts, and connect the systems of record.
• Migrate and test: load data in dependency order into a full sandbox, reconcile totals, and test access with realistic user personas.
• Pilot and expand: go live with one team or branch, fix what they struggle with, then add each further line of business in turn.

This guide assumes you have already decided Financial Services Cloud is the right product. If you are still weighing it against core Sales or Service Cloud, start with our guide on when it fits.

Which data model decisions come first?

Decide how people, households and financial accounts are represented before anything else is configured. These choices shape rollups, sharing, reports and every integration, and reversing them after data loads is expensive.

Person accounts come first. Financial Services Cloud expects individual clients to be stored as person accounts, which merge Account and Contact fields into one record. Salesforce notes that person accounts cannot be disabled once enabled. Test their effect on existing contacts, integrations, reports and any third-party apps in a sandbox before switching them on in production.

Households and relationship groups come next. A household is typically an account tied to a Party Relationship Group record, with members linked through Account Contact Relationship records. Agree what a household means at your firm. Some firms group only spouses and dependents; others include trusts, family businesses and adult children with their own advisors.

Financial accounts and holdings follow. Decide which account types you will bring in, such as investment, deposit, loan, card or policy records, and who owns each joint account. Decide whether holdings are needed at all. Many firms only need balances and summary values, with position detail left in the portfolio system.

Action plans deserve early attention too. They turn repeatable processes, such as onboarding a trust or running an annual review, into templates of tasks with owners and deadlines. Designing them early shows which fields and record types each process really needs.

How does FSC connect to custodians, core banking and policy systems?

Financial Services Cloud should display and roll up data from your systems of record, not replace them. Integrations bring balances, positions, loans or policies in, while the source system stays the authority.

The patterns repeat across segments. Wealth firms usually connect custodial platforms and portfolio management or financial planning tools. Banks connect core banking, loan origination and servicing platforms. Insurers and agencies connect policy administration or agency management systems. For each feed, decide three things: what data comes in, how often it refreshes, and who reconciles it when numbers disagree.

• Scheduled batch loads suit balances and positions that change daily and are reviewed rather than acted on in the moment.
• Near real-time or event-driven updates suit service interactions, such as a banker confirming a payment during a call.
• On-demand lookups suit detailed history that is too large to copy, such as years of transactions.
• Outbound calls suit processes that must update the source system, such as starting an account opening in core banking.

Data spread across systems is common in lending as well. A business lender we worked with had customer data sitting across a risk engine, a servicing platform and Salesforce. The work there was a Data 360 (then Data Cloud) architecture and roadmap to unify that data, not an FSC build, but the lesson carries over: map every source before you design the target.

What compliance and security design does FSC need?

Design sharing, supervision and audit requirements with your compliance officer before real client data moves. Access mistakes found after go-live are costly to fix and may be reportable.

Start with who may see what. Many firms require that one advisor or agent cannot see another's clients. Household structures can quietly widen access if sharing is designed separately from them. Compliant Data Sharing lets you grant access by participant role or branch rather than by ownership alone, which suits joint coverage teams and information barriers.

Private sharing is not unique to the industry cloud. An insurance agency we worked with used Sales Cloud, not Financial Services Cloud. Org-wide defaults were set to private so agents could not see each other's clients. Rules then exposed closed-lost records after 14 days.

Supervision and archiving come next. Any client communication sent from Salesforce must reach your archiving and review process. A fee-only RIA we worked with automated post-meeting surveys and prospect journeys in Marketing Cloud Account Engagement. A BCC-to-advisor configuration fed the firm's archiving system, so every automated message stayed archived and supervised.

Then settle the audit trail. Standard field history tracking records changes on a limited number of fields per object, for a limited retention period. If regulators or contracts require longer retention, encryption at rest or detailed event logs, review Salesforce Shield. Our guide on whether you need Shield covers Platform Encryption, Event Monitoring and Field Audit Trail.

How do you migrate from Redtail, Wealthbox or another legacy CRM?

Treat migration as a mapping exercise first and a load exercise second. The source structure rarely matches households, person accounts and financial accounts one to one.

Common sources include wealth-focused CRMs such as Redtail and Wealthbox, older Salesforce orgs built on custom objects, and spreadsheets. Contact data held in agency or banking systems is another. Whatever the source, the steps are similar:

• Export everything, then decide what to leave behind, such as inactive prospects or duplicate contacts.
• Map source fields to person accounts, households, relationships and financial accounts, and note every gap.
• Rebuild household membership explicitly, since legacy tools often store it as tags, notes or free text.
• Load in dependency order: people, then households and relationships, then financial accounts, then activities and notes.
• Reconcile record counts and household totals against the source after every load, not only at the end.
• Move only the history people will use; link to or archive the rest.

Existing custom objects need the same care. A broker-dealer we worked with ran capital raising on Salesforce with 5+ custom objects, including Engagement and Investment objects joined by junction objects. Any firm with a build like that should decide object by object what maps to the industry model and what stays custom.

How do you get advisors and bankers to use it?

Make the household view the fastest way to prepare for a client conversation. If staff still open a spreadsheet or the custodian portal first, adoption will stall.

• Build page layouts around the questions staff ask most, such as total relationship value, open tasks and the next review date.
• Validate household totals against statements for a sample of real clients before launch, so the first impression is a correct one.
• Train on real scenarios, like preparing an annual review or taking a service call, rather than tours of every tab.
• Give assistants and operations staff their own views, since their work differs from an advisor's.
• Watch the pilot team for side spreadsheets and skipped screens, then fix those before wider rollout.

What drives the length of an FSC implementation?

The number of integrations, the quality of legacy data and the lines of business in scope drive timeline more than configuration does. The table shows common factors that stretch or shorten a project.

What are the most common FSC implementation mistakes?

Most failures trace back to decisions made too late or not made at all. These come up again and again.

• Enabling person accounts in production before testing their effect on existing data and integrations.
• Loading financial accounts without configuring rollups, leaving households at zero or double-counting joint accounts.
• Copying full transaction history into Salesforce, bloating storage and creating a second copy that drifts.
• Designing sharing after households are built, which can expose clients to the wrong staff.
• Staffing only standard administrators when the scope depends on OmniStudio components.
• Launching every line of business at once, so problems cannot be isolated or fixed quickly.

How should you scope phase one?

Scope phase one around one team, one primary source system and the few processes that team runs every week. A narrow first release proves the data model and security design with real users before they spread.

• Pick one line of business and one team or branch as the pilot group.
• Include person accounts, households, core relationships and the financial account types that team needs.
• Connect the single most important system of record, with reconciliation ownership agreed.
• Build two or three action plans for the processes that cause the most missed steps today.
• Finish the sharing model and audit requirements in full, even if features are limited.
• Defer discovery questionnaires, client portals and AI agents to later phases unless they are the reason for the project.

We are a Salesforce Select partner since 2017 and a Salesforce Financial Services Accredited Partner. We usually settle this scope in discovery, before writing any build estimate.