Home / admin / wealth-management-requirements

wealth-management-requirements

Use this skill when gathering, structuring, and documenting requirements for a Financial Services Cloud (FSC) wealth management implementation — including financial planning workflow discovery, portfolio review process mapping, client lifecycle requirements, advisor tooling needs, and FSC architecture determination (managed package vs.

• v1.0.0
• Salesforce Spring '25+
• Updated 2026-04-11
• Operational Excellence
• Reliability
• Security

• financial-services-cloud
• fsc
• wealth-management
• requirements-gathering
• financial-planning
• portfolio-review
• advisor-tools
• fsc-core

Open the skill folder on GitHub

Wealth Management Requirements

This skill activates when a Business Analyst or admin needs to elicit, structure, and document requirements for an FSC wealth management implementation — before any build begins. It covers the first critical decision (managed package vs. FSC Core architecture determination), the object model scoping conversation, financial planning and portfolio review workflow discovery, advisor tooling requirements, and the fit-gap analysis that drives sprint planning.

This skill is strictly for requirements and process mapping. Do NOT use it to configure FSC objects, write Apex, or design data architecture. Those tasks have dedicated skills.

Before Starting

Gather this context before conducting any wealth management requirements discovery:

• Determine managed package vs. FSC Core first. This single decision changes every API name, every SOQL query, every integration design, and every ISV package compatibility conversation. Managed-package orgs use the FinServ__ namespace (e.g., FinServ__FinancialAccount__c). FSC Core orgs — General Availability since Winter '23 — use no namespace (e.g., FinancialAccount). Do not proceed with object scoping until this is confirmed; the wrong answer causes silent failures throughout the project.
• Identify the household model. FSC wealth management can be configured for individual Person Accounts, multi-member household Accounts, or both. The household model drives rollup behavior, page layout design, advisor view requirements, and client portal scope. Confirm which model is in use or desired before mapping any process.
• List third-party ISV packages in scope. Custodian data feeds and portfolio management platforms (Black Diamond, Orion, Addepar, Tamarac) are common in wealth management implementations. These packages may not be certified for FSC Core and must be validated before the architecture decision is finalized.
• Understand the advisor persona. Wealth management has distinct advisor archetypes: financial planners who build goal-based plans, portfolio managers who monitor positions and allocations, relationship managers who focus on client lifecycle and AUM, and support staff who handle onboarding and documentation. Requirements differ substantially between these roles.

Core Concepts

Managed Package vs. FSC Core Determination

The most consequential requirements decision is whether the org uses the FSC managed package or FSC Core. This must be confirmed — not assumed — at the start of requirements discovery.

Managed package (FinServ__ namespace):

• All FSC objects carry the FinServ__ prefix: FinServ__FinancialAccount__c, FinServ__FinancialGoal__c, FinServ__FinancialAccountRole__c.
• Rollups to household totals are executed via Apex triggers, not native Record Rollup fields.
• The managed package is typically one API version behind the FSC Core release cadence.
• Financial account ownership is modeled via two lookup fields: Primary Owner and Joint Owner. This limits ownership to two named individuals per account.
• Third-party ISV packages with FSC integrations are more likely to be certified against the managed package namespace.

FSC Core (GA since Winter '23, no namespace):

• Objects use standard API names: FinancialAccount, FinancialGoal, FinancialPlan, ActionPlan.
• Rollups use native Salesforce Record Rollup fields — no Apex trigger required for standard rollup behavior.
• Financial account ownership uses the FinancialAccountParty junction object, which supports unlimited owners with typed roles. This enables complex ownership structures (trusts, partnerships, family accounts with multiple members).
• AccountFinancialSummary is a Core-only rollup target that aggregates balances at the household/account level. It requires a dedicated FSC PSL integration user to populate correctly.
• Third-party ISV packages must be individually validated for FSC Core support. As of Spring '26, not all custodian feed packages are certified for Core.

Requirements impact: If a requirements document specifies SOQL queries, object names, or API field references without confirming the architecture, those references will be wrong for at least one of the two models. Requirements should describe business intent (e.g., "advisor can see total household AUM across all accounts") — not implementation field names.

Key FSC Objects for Wealth Management Scoping

Requirements discovery must explicitly confirm which of these objects are in scope:

Financial Account types to scope: The FinancialAccountType picklist drives record type and page layout selection. Standard types include: Investment (brokerage), Deposit (checking/savings), Insurance (life, annuity), and Loan (mortgage, HELOC). Confirm which types are needed before mapping workflows.

Financial Planning and Portfolio Review Workflows

Wealth management requirements involve two distinct workflow categories that are commonly conflated:

Financial planning workflow — goal-based, client-centric:

1. Client discovery and data gathering (household, income, assets, liabilities, goals)
2. Goal definition and prioritization (retirement, education, home purchase, estate)
3. Plan creation linking goals to projected financial account allocations
4. Periodic plan review (typically annual or semi-annual)
5. Plan update based on life events (marriage, inheritance, job change)

Portfolio review workflow — performance-based, advisor-driven:

1. Custodian data load (positions, transactions, market values)
2. Portfolio analysis against allocation targets
3. Rebalancing recommendations generation
4. Client review meeting preparation (agenda, performance report)
5. Post-meeting action tracking (trades, documentation, follow-up)

Each workflow maps to a distinct set of FSC features. Financial planning uses FinancialGoal, FinancialPlan, and ActionPlan for review cadence. Portfolio review uses FinancialHolding, integration with custodian data feeds, and advisor reporting tools. Requirements discovery must separate these two categories to avoid scope conflation.

Action Plans for Repeatable Advisor Workflows

ActionPlan and ActionPlanTemplate are the FSC mechanism for creating and tracking repeatable advisor workflows such as annual client reviews, client onboarding checklists, and KYC document collection sequences. Requirements discovery for advisor tools must determine:

• Which review workflows should be standardized as templates
• What task list each template should contain
• Whether tasks have sequential dependencies or can be completed in parallel
• Who is responsible for each task (advisor, client, compliance, operations)
• What records (Account, FinancialAccount, FinancialGoal) each Action Plan should be associated with

Common Patterns

Pattern: Architecture Determination Workshop

When to use: At the start of every FSC wealth management engagement, before any other requirements activity.

How it works:

1. Ask: "Is this a net-new FSC implementation or an existing FSC org?" If existing, run SELECT Id, Name FROM Organization and check field API names on any FSC object to confirm namespace.
2. Ask: "Are any third-party custodian data or portfolio management packages installed or under evaluation?" List them. Validate each against the Salesforce AppExchange for FSC Core certification.
3. Ask: "Is unlimited multi-owner account support required (e.g., trusts, family LLCs with more than two owners)?" If yes, FSC Core's FinancialAccountParty junction is the only supported path.
4. Document the architecture decision and its rationale in the requirements document. All subsequent object names, workflow descriptions, and integration scope should reference the confirmed model.

Why not to skip this step: Requirements written with managed-package object names (FinServ__FinancialGoal__c) will fail silently in a Core FSC org where the object is FinancialGoal. This causes integration errors, broken SOQL in validation rules, and miscommunication between admins and developers.

Pattern: Advisor Tooling Discovery Interview

When to use: When gathering requirements for advisor-facing features: record pages, action plans, financial goal tracking, household views, and performance reporting.

How it works:

1. Current state questions: "Walk me through a typical client review. What do you look up first? What do you manually check before the meeting? What do you need to document after?"
2. Pain point questions: "What information is missing from your current view? What do you have to log into multiple systems to find? What falls through the cracks between meetings?"
3. Automation questions: "Which parts of the review process should be automatic? What should Salesforce remind you to do and when?"
4. Volume questions: "How many clients do you manage? How many reviews do you do per week? How many accounts per client household?"
5. Map each answer to a specific FSC feature or a gap:
   • Household summary view → AccountFinancialSummary (Core) or custom rollup (managed package)
   • Annual review checklist → ActionPlan + ActionPlanTemplate
   • Goal progress tracking → FinancialGoal with target amount and target date
   • Portfolio performance → FinancialHolding + custodian feed integration

Why volume matters for requirements: Advisors managing 200+ households with weekly reviews create significant Action Plan record volume. This surfaces data storage requirements, SOQL governor limit considerations for batch processing, and list view performance design decisions that must be captured at the requirements stage.

Decision Guidance

Recommended Workflow

Step-by-step instructions for an AI agent or practitioner activating this skill:

1. Confirm FSC architecture — determine whether the org uses managed package (FinServ__ namespace) or FSC Core (no namespace, Winter '23+). All subsequent requirements must reference the confirmed model.
2. Scope FSC objects — work through the FSC object table in Core Concepts, confirming which objects are in scope for this engagement. Document in-scope and out-of-scope objects explicitly.
3. Conduct advisor tooling discovery — interview advisor personas using the Advisor Tooling Discovery Interview pattern. Map each workflow step to a specific FSC feature or flag as a gap.
4. Map financial planning and portfolio review workflows separately — use the workflow categories in Core Concepts to avoid conflating goal-based planning requirements with performance-monitoring requirements.
5. Validate ISV package compatibility — if any third-party packages are in scope, confirm FSC Core certification status before finalizing architecture recommendation.
6. Produce fit-gap analysis — classify each requirement as Standard FSC Feature, FSC Configuration, Custom Development, or Integration Scope.
7. Review against checklist — run through the Review Checklist below before handing off requirements to the build team.

Review Checklist

Run through these before handing requirements to the build team:

• [ ] FSC architecture (managed package vs. FSC Core) is confirmed and documented with rationale
• [ ] All object API names in requirements documents match the confirmed FSC architecture (no mixing of FinServ__ and no-namespace names)
• [ ] FinancialAccount types in scope are listed (investment, deposit, insurance, loan) with record type and page layout implications noted
• [ ] Financial account ownership model is confirmed: two-owner (managed package) vs. unlimited via FinancialAccountParty junction (FSC Core)
• [ ] Financial planning workflow and portfolio review workflow are documented as separate process flows
• [ ] ActionPlan template requirements are captured: which workflows, which tasks, which record associations
• [ ] All third-party ISV packages are listed and validated for FSC Core compatibility if Core is the chosen architecture
• [ ] AccountFinancialSummary requirements (if any) are flagged as Core-only and the PSL integration user requirement is noted
• [ ] Custodian data feed requirements are documented as integration scope (source, format, frequency, field mapping)
• [ ] Advisor volume data is captured: number of clients, review frequency, accounts per household

Salesforce-Specific Gotchas

Non-obvious platform behaviors that cause real production problems:

1. Namespace mismatch between requirements and implementation — If requirements are written with managed-package object names (FinServ__FinancialGoal__c) but the org runs FSC Core, every SOQL query, every validation rule field reference, and every integration mapping will fail silently or with a confusing error. Confirm the architecture once and enforce consistent naming throughout the requirements document.
2. AccountFinancialSummary requires a dedicated integration user — FSC Core's AccountFinancialSummary object is not populated by standard user activity. It requires a dedicated FSC PSL (Platform Service Layer) integration user to run the rollup aggregation. Requirements that assume advisors will see household-level AUM automatically without this setup will not behave as expected after go-live.
3. Managed package ownership limits break complex household structures — Managed-package FSC financial accounts support exactly two ownership lookup fields (Primary Owner, Joint Owner). Requirements for trusts, partnerships, or family accounts with three or more named owners cannot be met with the managed package model without custom fields that break rollup behavior. Surface this constraint during requirements, not during UAT.
4. FinancialPlan licensing is not always included — The FinancialPlan object and the financial planning module may require a separate FSC license add-on depending on the customer's contract. Gathering requirements for financial plans without confirming license entitlement leads to scope surprises. Verify with Salesforce AE or review the order form before scoping FinancialPlan features.
5. ActionPlan volume drives list view and query performance — If an advisor manages 300 clients each with an annual review Action Plan generating 10 tasks, that is 3,000 open task records per advisor. At scale across a firm, this creates significant record volume that affects list view performance, report query time, and batch job governor limits. Volume must be captured during requirements discovery, not treated as an afterthought.

Output Artifacts

Related Skills

• financial-account-setup — use after requirements are gathered to configure FinancialAccount types, roles, and household rollup behavior
• fsc-action-plans — use to implement ActionPlan and ActionPlanTemplate once workflow requirements are documented
• architect/wealth-management-architecture — use when technical architecture decisions (feature flags, data model, Compliant Data Sharing) are needed alongside or after requirements
• apex/fsc-financial-calculations — use when requirements surface custom rollup or portfolio calculation needs that FSC Core Record Rollups cannot meet
• requirements-gathering-for-sf — use for general Salesforce requirements gathering methodology; this skill is the FSC wealth management specialization of that skill

Package files

• references/examples.md
• references/gotchas.md
• references/llm-anti-patterns.md
• references/well-architected.md
• templates/wealth-management-requirements-template.md
• scripts/check_wealth_management_requirements.py