Free Financial-Services-Cloud Practice Test Questions 2026

Explanation:

Person Accounts as Accounts
In the Financial Services Cloud data model, when using Person Accounts, every individual client is modeled as an Account record with the IsPersonAccount field set to true.

Relationship Modeling
Relationships between these clients, such as Spouse, Business Partner, or Child, are managed using a junction object designed to link two Account records together: the Account Account Relationship object (API name: AccountAccountRelation).

Custom Fields for Reporting
To track specific details about how two people are related, such as a partnership start date or custom reporting metrics, the custom fields must be added to this junction object. This is because the data describes the relationship itself, not attributes of either individual client.

Why Other Options are Incorrect

A. Account Contact Relationship
This object is primarily used in the Individual Data Model, where a client is modeled as a Contact linked to a generic Account record, such as a Household or Business. It is not the correct object when using the Person Account model.

B. Contact-Contact Relationship
This object is also specific to the Individual Data Model, where relationships link two Contact records rather than Account records.

C. Person Account
Custom fields on the Person Account object track attributes of the individual person, such as hobbies or addresses, not the relationship between two people.

Explanation:

In Salesforce Financial Services Cloud, when the Intelligent Need-Based Referrals and Scoring managed extension package is installed, three specific Lead record types are added to the Lead object. This setup is standard for most Financial Services Cloud implementations that use referral features.

Referral
Used for leads originating from internal or external referrals, such as from existing clients or partners. This record type enables scoring, referral-specific fields, and integration with referral dashboards and incentive tracking.

General
A catch-all record type for standard inbound leads that do not fall into referral or specialized categories.

Retirement Planning
A specialized record type for leads related specifically to retirement planning services. This allows tailored page layouts, fields, and processes for a common wealth management use case.

These three record types allow advisors to configure different page layouts, picklist values, and business processes based on the lead source or lead type.

Why not the others?

B. Opportunity ❌
Incorrect. Opportunity is a separate object in Salesforce. Leads can convert into Opportunities, but there is no Opportunity record type on the Lead object.

D. Adjustments ❌
Incorrect. No record type named Adjustments exists on the Lead object in Financial Services Cloud.

References:
Salesforce Help and Trailhead — Intelligent Need-Based Referrals and Scoring setup documentation (lists Referral, General, and Retirement Planning as the Lead record types created by the managed extension package)
Financial Services Cloud implementation guides and Accredited Professional practice exams (commonly test this multi-select question with A, C, and E as the correct answers)

Explanation:

In Salesforce, relationships between two Business Accounts (non-person accounts such as companies or trusts) are defined using Account Relationships, which rely on Reciprocal Roles to describe the connection from both sides.

Why C is Correct:

Purpose of Reciprocal Roles:
When you link two Business Accounts, you define the relationship from the perspective of each account. For example, if Account A is a Parent of Account B, then Account B must be the Subsidiary of Account A. A Reciprocal Role is a paired set of role labels that ensures the relationship is logically defined in both directions. Creating a new reciprocal role pair guarantees consistency and clarity.

Object in Use:
The underlying object is the Account Relationship object (often AccountAccountRelation in Financial Services Cloud–enhanced orgs). When configuring relationships between business accounts, users select from predefined Account Reciprocal Roles created by the administrator.

Meeting the Requirement:
To allow users to relate two business accounts with a relationship type that does not exist in the standard picklist, the administrator must first create a new Reciprocal Role pair in Setup (for example, “Investor Of” and “Invested In”). Only after this configuration can users select that role when creating an account-to-account relationship.

Why the Other Options Are Incorrect:

A. Create a new Contact Reciprocal Role for the required value
Incorrect. Contact Reciprocal Roles are used for defining relationships between Contacts, or between a Contact and an Account. Since the requirement is to relate two Business Accounts, this is the wrong object type.

B. Update the Role picklist on the Account-Account Relationship object with new value
Incorrect and misleading. There is no standard object named “Account-Account Relationship.” More importantly, you cannot simply add a single value to a role picklist. Salesforce requires a Reciprocal Role pair to properly model the bidirectional nature of the relationship. Adding only one side would break the relationship logic.

D. Update the Role picklist on the Account-Contact Relationship object with new value
Incorrect. The AccountContactRelation object is used to relate an Account to a Contact, not to relate two Business Accounts. Additionally, as with option B, you must create a Reciprocal Role pair rather than updating a single picklist value.

Key References & Concepts:

Setup Path:
Setup > Object Manager > Account > Relationships > Reciprocal Roles (for account-to-account relationships).

Process:
Admin creates a new Reciprocal Role pair (for example, “Vendor Of” and “Client Of”).
Users then create a new Account Relationship record by selecting the primary account, the related account, and the new role (such as “Vendor Of”).
Salesforce automatically applies the reciprocal role (“Client Of”) on the reverse relationship.

FSC Context:
In Financial Services Cloud, Business Accounts can represent trusts, foundations, or corporate entities. Correctly relating these entities, such as linking a trust to a beneficiary corporation, is essential for understanding complex ownership and organizational structures.

Reporting:
Account Relationships surface in the Actionable Relationship Center and can be reported on to visualize hierarchies and entity connections.

Summary:
To enable users to relate two Business Accounts with a new type of relationship, the administrator must create a new Account Reciprocal Role pair in Setup. This configuration provides the consistent, bidirectional labels required by Salesforce’s relationship model.

Explanation

Why A is correct
With Compliant Data Sharing (CDS), opportunity participants can generate share table entries that grant access beyond the org-wide defaults. When an Opportunity is set to Private, Salesforce removes (deletes) those share table records, effectively revoking the access that was granted through CDS sharing.

Why D is correct
When the Opportunity is set to Private, Salesforce does not delete the Opportunity Participant records themselves. The participant rows remain, but their related share table entries are removed, so they no longer provide additional access.

Why the other options are incorrect

B. Share table records need to be manually deleted ❌
Salesforce deletes the share table records automatically when the Opportunity is made Private; manual deletion is not required.

C. All opportunity participant records are deleted ❌
Participant records are not deleted—only the share table entries associated with them are deleted.

References (Official Salesforce Sources)
Salesforce Help — Manage Participants for Private Opportunities in Compliant Data Sharing
Salesforce Help — Control Who Sees What with Compliant Data Sharing

Explanation:

Action Plans in Financial Services Cloud are structured, templated sets of tasks designed to standardize processes. A critical concept is the distinction between an Action Plan Template and a published/associated Action Plan.

Why B is Correct:

"Published" State is Locked:
Once an Action Plan Template is published and associated with client records, it becomes a locked, standardized template. Its structure—including tasks, their order, and due date offsets—cannot be modified directly by an end-user like Jen.

Administrator Control:
Only a user with sufficient permissions, typically a System Administrator or someone with the "Customize Application" permission, can edit the published Action Plan Template in Setup. This ensures process integrity and prevents uncontrolled variations.

Correct Process:
Jen's requirement is to modify the template itself to support an additional task for future annual reviews. The proper channel is to request this change from her Salesforce Administrator, who can update the template and republish it if necessary.

Why the Other Options Are Incorrect:

A. Use the 'task creator' tool to create a new task and associate with the existing Action Plan
Incorrect. There is no standard "task creator" tool for adding tasks to a locked, published Action Plan template. While individual tasks can be created, they cannot be inserted into the sequenced structure of an existing, in-use Action Plan template via a simple tool.

C. Use the Action Plan item feature to add an additional task to a published Action Plan
Incorrect. The "Action Plan item" feature refers to the tasks within the template. For a published template, this feature is not editable by standard users. This option suggests a capability that does not exist for published plans in production without administrative rights.

D. Create an independent Task not related to original Action Plan
Incorrect. This addresses the symptom but not the root requirement. While Jen could manually create a separate task for one client, the requirement is to modify the Action Plan to support an additional task for the process itself. Creating a one-off, unrelated task does not update the standardized template for future use, leading to inconsistency and manual work.

Key References & Concepts:

Action Plan Lifecycle:
- Create/Edit Template: Done by Admin in Setup (FinServ__ActionPlanTemplate__c).
- Publish Template: Makes it available for users to associate with records.
- Associate Template: User attaches the published template to a Client, Group, or Opportunity, which generates the individual task records.

User Permissions:
- Standard users (like Financial Advisors) can view and associate published templates.
- They can mark generated tasks as complete.
- They cannot modify the template's structure.

Best Practice:
Process changes, like adding a step to an annual review checklist, should follow a change management procedure involving the Admin to ensure the template is updated correctly, tested, and then made available for future use.

Alternative for Single Client:
If Jen only needs the extra task for one specific client's existing action plan instance, she could clone the Action Plan, create a custom version, and add the task there. However, the requirement implies modifying the published plan for ongoing use, which requires an admin.

Explanation

Configuration vs. Personalization:
In the FSC data model, the Life Events (for individuals) and Business Milestones (for accounts) components are configured by the Administrator. While users can view the events, they do not have permissions to change the underlying component logic or global sorting rules.

Chronological Order:
By default, life events are often displayed by category. However, an Admin can customize the component in the Lightning App Builder to ensure events are displayed chronologically. This allows agents to immediately see the most recent or upcoming events at a glance, reducing cognitive load during a fast-paced call.

Hiding/Showing Types:
The Admin can also choose to hide certain event types that are irrelevant to a specific business unit to further declutter the view.

Why Other Options Are Incorrect:

Options B and C:
Salesforce FSC does not currently support a standard feature to change the icon or text color to "red" for specific life events. Visual differentiation is typically handled through the unique icons associated with each event type, such as a graduation cap for education or a ring for marriage.

Option D:
Standard users cannot customize the sorting logic or the order of life events across the org. This is a metadata/layout change that must be performed by a System Administrator.

References:
Salesforce Help — Customize Life Events and Business Milestones
Trailhead — Life Events and Business Milestones in Financial Services Cloud

Explanation:

During the planning phase of a Financial Services Cloud (FSC) implementation, the team should focus on strategic activities that assess the organization's needs against FSC's capabilities and identify key requirements early. This includes:

A: Preparing for integrations
Critical because financial services firms often rely on external systems, such as core banking platforms, custodians, or market data providers. Early planning for integration methods, tools, data flows, and challenges ensures seamless data exchange and avoids costly rework later.

B: Evaluating the need for advanced customizations
Determines the scope of the implementation. Prioritizing configuration over customization leverages standard FSC functionality wherever possible, reducing complexity and risk.

D: Reviewing out-of-the-box capabilities
Examining features like householding, rollups, Action Plans, and the Actionable Relationship Center against current business needs forms the foundation of gap analysis, enabling informed decisions on adoption versus customization.

These activities align with Salesforce best practices for industry cloud implementations: understand standard features first, plan integrations early, and scope customizations thoughtfully.

Why not the others?

C: Enabling Person Accounts and assigning permission set licenses
These are setup/configuration tasks typically performed in the early implementation phase (e.g., in a sandbox), not prioritized during initial planning or discovery.

E: Detailed design of field/picklist/layout modifications
Occurs after gap analysis, during the design and build phase, not during initial planning.

References:
Salesforce FSC Implementation Best Practices — Lists A (integrations), B (evaluate customizations), and reviewing OOTB vs. needs as planning priorities.
Salesforce Help/Trailhead — Emphasizes discovery of requirements, OOTB feature adoption, and integration scoping before configuration.
Accredited Professional Exam Focus — Tests understanding of the implementation lifecycle, prioritizing planning activities like gap analysis and integration readiness over hands-on setup.

Explanation:

Why B is Correct
A Parent FlexCard provides the overall container for the 360-degree view of the customer.

To display different types of related data (Account info, Opportunities, Contracts/Policies), the consultant should use multiple Child FlexCards. Each child card can be designed to handle one dataset:

Child FlexCard 1: Account information (name, phone, website).
Child FlexCard 2: Active Opportunities related to the Account.
Child FlexCard 3: Active Insurance Policies related to the Account.

Card Actions allow the agent to perform tasks directly from the console, such as viewing or renewing policies.

This modular design ensures scalability, reusability, and clarity — each child card focuses on one dataset, while the parent orchestrates the overall view.

❌ Why the Other Options Are Incorrect

A. Parent FlexCard with single Child and Card Actions
Incorrect: A single child card would force all data (Account, Opportunities, Policies) into one card, making it cluttered and harder to maintain.

C. Parent FlexCard with multiple Children and different Card States
Incorrect: Card States are used to display different views of the same card depending on conditions (e.g., active vs. inactive). Here, we need different datasets, not conditional states.

D. Parent FlexCard with single Child and multiple Card States
Incorrect: Same issue as C — Card States are for conditional rendering of one dataset, not for displaying multiple distinct datasets like Accounts, Opportunities, and Policies.

📚 References
Salesforce OmniStudio Documentation — FlexCards Overview
FSC AP-208 Exam Guide — OmniStudio FlexCards and Integration Procedures section

Explanation:

In the Individual Account Model, Salesforce represents a person using a combination of one Account record and one Contact record, linked by a specific lookup. Because FSC is designed to provide a 360-degree view of a client’s financial life, it uses specialized objects to store data that doesn't fit into standard banking fields:

Assets and Liabilities: These are tracked using the Assets and Liabilities object (FinServ__AssetsAndLiabilities__c). This is a custom object included in the FSC managed package. It stores items like real estate, collectibles (assets), or personal loans and mortgages (liabilities).

Financial Goals: These use the Financial Goal object (FinServ__FinancialGoal__c), another custom object used to track progress toward milestones like retirement or a home purchase.

Modeling Relationship: In the Individual model, these records are linked directly to the Account record of the individual. This allows the system to roll up the values into the "Financial Summary" component visible on the client's profile.

Identification Documents: While document tracking uses Document Checklist Items, the actual metadata about assets or revenue is stored in these structured custom objects rather than as simple file attachments.

Analysis of Incorrect Answers:

A & B. The Attachment object is used...
Incorrect. Using the standard Attachment or File object to represent an asset (like a $500,000 home) would make the data "unstructured." You cannot run financial rollups, calculations, or reports on a file. FSC uses custom objects so that the numerical values can be aggregated into a client's net worth.

D. Document, Note, and Attachment objects are used... related to the person account:
Incorrect. This answer is a double-distractor. First, "Notes and Attachments" are for files/prose, not for structured financial modeling. Second, the question specifically asks about the Individual Account Model, but this answer mentions "Person Accounts." While they are similar, they are technically distinct data models in FSC. In the Individual model, records relate to the Account (the "header" of the individual), not a Person Account record type.

References:
Salesforce Help — How Are Identification Documents, Other Assets, Liabilities, and Goals Modeled?
Salesforce Help — Assets and Liabilities in Financial Services Cloud
Trailhead — Financial Services Cloud Data Modeling Module

Explanation:

Why A is correct
The Financial Services Cloud free trial is specifically designed to let you explore FSC in a preconfigured org with sample data and the right features/licenses enabled so you can learn the product hands-on without needing to install packages, buy licenses, or set up a production/sandbox environment. This matches the question’s requirement exactly: pre-configured org + data + right licenses for learning.

Why the other options are incorrect

B. Request a Salesforce developer org. ❌
A standard Developer Edition org does not automatically come with FSC preconfigured, sample data, and the required FSC licensing experience. The question is specifically asking for a Financial Services pre-configured org with the right licenses and data, which is what the trial provides.

C. Purchase one license of Financial Services Cloud and install it in a production org. ❌
This is unnecessary (and risky) for evaluation/learning. Salesforce provides a purpose-built trial experience so you can learn without modifying production.

D. Spin up a Salesforce sandbox org. ❌
A sandbox is a copy of an existing org—if FSC isn’t already implemented, a sandbox won’t magically provide FSC configuration, sample data, and licenses for learning.

References:
Salesforce Help — Create a Financial Services Cloud Trial Org and Explore (trial experience to explore FSC)
Salesforce Developer Site — Financial Services Cloud Free Trial (30 days, configured, sample data)

Explanation:

B. In a household, each of the household members is modeled as a Person Account and the household is modeled as an Account.
Correct. This is the core FSC data model for households.
Person Account: Represents an individual client (with fields like First Name, Last Name, SSN). It is an Account record with a specific "Person Account" record type.
Household/Group: Represented as a standard Business Account record (record type often "Group" or "Household").
Relationship: The connection is made via the FinServ__GroupMember__c (Group Membership) object, which links a Person Account (Member) to a Group Account and defines the Role (e.g., Primary Owner) and Primary Group flag.

D. Both the Financial Deal object and the Opportunity object support Compliant Data Sharing.
Correct. Compliant Data Sharing (CDS) is a critical FSC feature for enforcing strict, rules-based access to sensitive financial records.
Opportunity: The standard Salesforce object, which CDS can govern.
FinServ__FinancialDeal__c (Financial Deal): An FSC-specific object designed for complex, multi-stage financial transactions (like loan origination). It is a first-class object in the CDS framework, meaning it can be configured with its own sharing rules independent of Opportunities.

E. Interaction Summary is an enhancement of the standard Activity object.
Correct. The FinServ__InteractionSummary__c object is an FSC-specific extension of Activities (Tasks/Events).
Enhanced Tracking: It includes additional fields critical for financial services, such as Engagement Topic, Engagement Channel, Interaction Status, and links to Related Financial Accounts and Goals.
Best Practice: For a true FSC implementation, Interaction Summary should become the primary object for logging client interactions, as it enriches the data model for better reporting (e.g., "How many retirement planning conversations did we have this quarter?") and integrates with other FSC features like Action Plans.

Why the Other Options Are Incorrect:

A. In a household, each household member is modeled as a Contact, and the household is modeled as an Account.
Incorrect. This describes the standard Salesforce B2C model (Contacts under a Household Account), not the Financial Services Cloud model. FSC uses the Person Account model for individuals. Person Accounts consolidate person and account data into a single record, which is better suited for financial services where the individual is the primary client entity.

C. Role Hierarchy-based sharing can be disabled for the Financial Deal object but can't be disabled for the Opportunity object.
Incorrect. The statement is backwards and false. Role Hierarchy sharing is a platform-level sharing mechanism that applies to all objects. It can be disabled for standard objects like Opportunity (by setting OWD to "Private" and not granting "View All" to higher roles). For the Financial Deal custom object, the same platform rules apply; you can configure its OWD and decide whether to enforce role hierarchy. There is no special rule that makes one disable-able and the other not.

Key References & Concepts:
Data Model Decision (B): Choosing the Person Account model is a foundational, irreversible decision in an FSC implementation. It enables the full FSC feature set.
Security Model (D): CDS should be planned early. Understanding which objects (Opportunity, Financial Deal, Financial Account) require its rules is crucial for design.
Adopting FSC Objects (E): A key consultant role is guiding the client to adopt native FSC objects (Interaction Summary, Financial Account Role, Action Plans) over their standard Salesforce equivalents to unlock industry-specific functionality and reporting.

Summary: During delivery, the consultant must ensure adoption of the Person Account & Group model (B), plan Compliant Data Sharing for key objects (D), and migrate activity tracking to the enhanced Interaction Summary object (E). These are critical for a successful, full-featured FSC implementation.

Explanation:

In Salesforce Financial Services Cloud (FSC) implementations, the consultant's deliverable for documenting the current state business processes (also called "as-is" processes) is typically an end-to-end visual map. This map uses standard process mapping elements such as swimlanes for personas (e.g., Advisor, Client, Back Office), boxes or icons for systems involved, arrows for flow, and annotations for inputs, outputs, decision points, and outcomes.
Visual process maps provide a clear, at-a-glance understanding of the existing workflows, pain points, handoffs, and system interactions—essential for gap analysis against FSC's out-of-the-box capabilities and for designing future-state ("to-be") processes. Salesforce partners and implementation methodologies (e.g., Salesforce's own Accelerator workshops or standard discovery phases) strongly recommend visual process maps over purely textual or tabular formats for this purpose.

Why not the others?
A: A narrative Word document ("story of the process") is subjective and harder to use for detailed analysis or stakeholder alignment; it lacks structure for comparing current vs. future state.
B: An Excel spreadsheet with steps, systems, and personas is useful as supporting detail but is not the primary deliverable—it's tabular, not visual, and difficult to follow for complex end-to-end flows.
D: A PowerPoint deck with screenshots and callouts is helpful for walkthrough presentations but is not a true process map; it focuses on static screens rather than dynamic flow, inputs, and outcomes across personas and systems.

References:
Salesforce Partner Community & Implementation Guides: Discovery phase deliverables emphasize visual current-state process maps (often using tools like Lucidchart, Visio, or Miro) with swimlanes for roles/personas and systems.
FSC Accelerators & Trailhead (Prepare for FSC Implementation): Recommend mapping as-is processes visually to identify gaps and opportunities.