Free Financial-Services-Cloud Practice Test Questions 2026

Explanation:

Why D is correct
An Integration Procedure (IP) is the best-practice OmniStudio method when you need to combine multiple data sources in one response for a FlexCard—specifically:
- External data (weather API callout via HTTP Action), and
- Salesforce data (Account field retrieval, often via a DataRaptor Extract inside the IP)

Integration Procedures are designed to orchestrate multiple steps (get Salesforce data + call external service + shape the JSON output) so the FlexCard can render everything cleanly.

Why the other options are incorrect
A. APEX classes ❌
Apex can do callouts, but OmniStudio best practices favor declarative Integration Procedures for this type of UI-driven data aggregation, using HTTP Actions and DataRaptors where possible.

B. Streaming API ❌
Streaming API is for event-driven updates (Change Data Capture, Platform Events, etc.), not for retrieving external weather data + Account fields on demand for a FlexCard.

C. Data Raptor Extract ❌
A DataRaptor Extract is best for pulling Salesforce data. It does not handle the full orchestration pattern needed here (external API call + Salesforce field + response shaping). Best practice: use Integration Procedure when external integration logic is required.

References:
Salesforce Help — When to Use OmniStudio Data Mappers (DataRaptors) and Integration Procedures (use IPs when you need more flexibility and multiple calls; IPs typically call DataRaptors)
Trailhead — Extract External Data with an Integration Procedure (explicitly uses a weather API as the example for displaying external data on a FlexCard/OmniScript)
Salesforce Developer PDF — Extract External Data with an Integration Procedure (weather API example for FlexCards/OmniScripts via Integration Procedure)

Explanation:

Identity Verification is a customer-facing, guided, and often multi-step process that requires collecting information, performing real-time checks (potentially against external systems), and presenting clear screens to agents or customers. The tools must support complex UI, conditional logic, and system integrations.

Why A and D are Correct:

A. OmniStudio
Correct for Agent-Guided Processes. OmniStudio (specifically OmniScripts) is ideal for designing structured, multi-step guided scripts that an agent can follow in a console. For identity verification, an OmniScript can:
- Present a clear sequence of steps to the agent (e.g., "Request Government ID," "Verify Address," "Ask Security Questions").
- Integrate with external verification services via Integration Procedures.
- Dynamically show/hide steps based on customer responses or risk scores.
- Be embedded directly in the Service Console or Financial Services Cloud console as a component, keeping the agent in context.

D. Screen Flows
Correct for Flexible, Platform-Native UI. Screen Flows (Lightning Flows with screens) are Salesforce's powerful, low-code tool for building dynamic, interactive user interfaces. They are perfectly suited for identity verification because they can:
- Create a tailored UI to collect customer information step-by-step.
- Include conditional logic to branch based on verification results (e.g., if ID check passes, proceed to address verification; if it fails, escalate).
- Call Apex Actions or External Services to perform real-time checks.
- Be launched from Flow Actions in the console, from a button, or from a record page, providing flexibility in how the process is triggered for agents.

Why the Other Options Are Incorrect:
B. Process Builder
Incorrect. Process Builder is an automation tool for record-triggered processes (e.g., "When a Case is created, update a field"). It is not designed to create user interfaces or guide an agent through a screen-based interaction. It works behind the scenes, not as a front-end tool for a conversational process like identity verification.

C. Discovery Framework
Incorrect. The Discovery Framework is a reporting and analytics feature within Financial Services Cloud used for client segmentation and insights (e.g., identifying clients with similar profiles or needs). It is a data analysis tool, not a process automation or UI tool. It cannot be used to design an interactive identity verification business process.

Key References & Design Considerations:
- Hybrid Approach: Often, OmniStudio (for complex, heavily integrated agent scripts) and Screen Flows (for lighter-weight or more flexible UI processes) are both valid tools in an FSC consultant's toolkit. The choice may depend on the bank's existing tech stack and the process's complexity.
- Compliance: Both tools allow for audit trails—each step and collected data point can be logged to the customer record, which is critical for regulatory compliance.
- Integration: Both can integrate with external identity verification services (like LexisNexis, Jumio) via API calls.
- User Experience: The primary goal is to give the agent a seamless, guided, and efficient process that ensures no verification step is missed, which both OmniScripts and Screen Flows are designed to provide.

Summary:
To design a compliant, agent-led identity verification process, the consultant should leverage OmniStudio (OmniScripts) for rich, guided scripts and/or Screen Flows for dynamic, platform-native UI interactions. Both are capable of orchestrating the complex logic and integrations required.

Explanation:

Why A is Correct
FSC provides Relationship Groups (sometimes referred to as Household or Group structures) that allow you to link multiple client records together and view them as one consolidated entity.

This is particularly useful when duplicate records exist due to multiple systems of record.

Relationship Groups let bankers see a 360-degree view of the individual without physically merging or deleting records.

Exam insight: FSC emphasizes using its native data model (Relationship Groups, Account-Account Relationships, etc.) rather than building custom hierarchies or components.

❌ Why the Other Options Are Incorrect
B. Implement deduplication rules in Salesforce and let the integration handle updates
Incorrect: Deduplication rules prevent future duplicates but don’t solve the need for a consolidated view across multiple systems of record.

C. Create a custom Person Account hierarchy
Incorrect: FSC already provides Relationship Groups and Account-Account Relationships. Creating a custom hierarchy is unnecessary and not best practice.

D. Create custom components to provide a single view of the client
Incorrect: Custom components add complexity and bypass FSC’s native capabilities. FSC Relationship Groups are designed for this exact scenario.

E. Link individuals using related contacts
Incorrect: Related Contacts are used to model relationships between Contacts and Accounts, not to consolidate duplicate Person Accounts.

📚 References
Salesforce Help: Relationship Groups in FSC
FSC AP-208 Exam Guide – Households and Relationship Groups

Explanation:

In Financial Services Cloud (FSC), Financial Accounts (FinServ__FinancialAccount__c) are a distinct object from the Account object. To meet the specific requirement of limiting visibility to certain products (the special deposits) for a specific group of users, a criteria-based sharing rule on the Financial Account object is the best practice.

Criteria-Based Sharing: This allows the administrator to define a rule such as: "If the Financial Account Record Type is 'Special Employee Deposit' (or a similar identifying field value), share this record."

Targeted Access: The rule can specifically share these records with a Public Group containing only the authorized customer service employees.

Standard Security Model: For this to work effectively, the Organization-Wide Default (OWD) for the Financial Account object must be set to Private. This ensures no one sees the records by default, and access is only "opened up" via the sharing rule for the designated group.

Analysis of Incorrect Answers
A. Create an Account sharing rule based on record owner: Incorrect. This would share the entire Client Profile (Account) based on who owns the record. It does not target the specific "special deposit products" (Financial Accounts) and doesn't handle the "employee-customer" criteria effectively.

B. Create Account sharing rules based on criteria: Incorrect. While this could control who sees the employee's Account record, it doesn't specifically manage the visibility of the underlying Financial Accounts. In FSC, access to an Account does not automatically grant full visibility into all related Financial Accounts if the Financial Account OWD is set to Private.

C. Create a Financial Account sharing rule based on record owner: Incorrect. Ownership-based sharing is used when you want to share all records owned by a specific role or group. In this scenario, the records are "special products" that might be owned by various people or automated systems; the criteria (the product type) is the relevant factor for the restriction, not the owner.

References
Salesforce Help: Set Up Sharing Rules for Financial Services Cloud
Salesforce Security Guide: Criteria-Based Sharing Rules
FSC Admin Guide: Security and Data Integrity in FSC

Explanation:

Why C is correct
The bank needs repeatable follow-up steps and the ability to track and report progress in FSC.

Action Plans in Financial Services Cloud are designed exactly for this: you create an Action Plan Template with a sequence of Tasks (with due dates relative to plan start), and then generate an Action Plan on the right business trigger so relationship managers can track completion and you can report on it.

Triggering the action plan when Account status becomes “Customer” best matches the business moment described: “after a new customer opens their first bank account”. In many banks an Account record can exist before the person is truly a customer (prospect/referral), so using the status change aligns the automation with the actual lifecycle milestone.

Why the other options aren’t
A (on Account creation): An Account might be created earlier (prospect, imported household, referral placeholder). That would start the follow-up process too soon and inflate reporting with non-customers.

B (on lead/referral conversion): Conversion can represent onboarding in some orgs, but the requirement is tied to becoming a customer after opening the first account—not necessarily to lead/referral conversion (which may not be used consistently in a bank).

D (emails only): Email reminders don’t provide structured in-system progress tracking/reporting the way Action Plans and their related Tasks do. Action Plans explicitly support standardized processes and tracking.

Explanation:

Business Hours and Holidays: Salesforce uses Business Hours and Holidays objects to manage working time calculations for various features, including Action Plans.

Non-Working Day Logic: The system determines a non-working day by whether any business hours are associated with that specific day in the assigned Business Hours record. To designate an entire day (like a Saturday/Sunday or a bank holiday) as a non-work day, the administrator must ensure that the "Day's Start Time" and "Day's End Time" fields are left blank or configured as a 0-hour duration within the Business Hours setup.

Action Plan Behavior: When an Action Plan is calculating the due date for the next task using a "date offset" (e.g., "Due in 2 days"), it automatically skips any days marked as non-working days in the associated Business Hours and Holidays settings.

Why Other Options are Incorrect:
Option A: This is close but slightly imprecise terminology. The configuration involves leaving the time fields blank for the specific day of the week in the Business Hours record or defining a Holiday record that spans that full day.

Option B: While you can define "recurring holidays," the fundamental way the system recognizes a day off is by the absence of assigned business hours on that specific day.

Option D: The calculation is automatic once the business hours and holidays are configured correctly. Simply adding non-work days to an "offset" isn't a setup step; the underlying configuration (Option C) is required for the automation to work.

References:
Salesforce Help: Set Up Business Hours and Holidays
Salesforce Help: Considerations for Action Plan Task Due Dates

Explanation:

Flow Orchestration is a Salesforce tool for automating complex, multi-participant business processes (like loan origination or account opening). Its architecture is built on three core, hierarchical components.

Why A, C, and E are Correct:

A. Steps
Correct. Steps are the atomic units of work within a Flow Orchestration. Each step represents a single, specific action that needs to be performed, such as:
- Running a Flow (Screen Flow, Auto-Launched Flow).
- Sending an Email Alert.
- Creating a Record.
- Running an Apex Action.
- Assigning the work item to a user or queue.
Steps are organized within Stages.

C. Stages
Correct. Stages are the major phases or milestones of the overall process. They group related Steps together in a sequence. For example, an "Application Intake" stage might contain steps for "Collect Client Info" and "Run Credit Check." Stages provide a high-level view of the process's progression.

E. Work Items
Correct. A Work Item is the runtime instance of a Flow Orchestration. It represents a single execution of the process for a specific record or case (e.g., "John Doe's Loan Application Work Item"). It tracks the current stage, step, assignee, and overall status for that particular item as it moves through the orchestrated process.

Why the Other Options Are Incorrect:
B. Blocks
Incorrect. "Blocks" is a term commonly associated with the individual elements inside a Flow Builder canvas (like Decision, Assignment, Loop blocks). It is not a component of the Flow Orchestration architecture. This is a common point of confusion between Flow and Flow Orchestration.

D. Processes
Incorrect. While "Process" is a general term for a sequence of activities, it is not one of the three named building blocks of the Flow Orchestration product. The configuration itself is called a "Flow Orchestration," and its runtime instance is a "Work Item." Using "Process" here is too vague and not the official terminology.

Key References & Concepts:
Hierarchy: Flow Orchestration (Definition) -> Contains Stages -> Contain Steps. When launched, it creates a Work Item.
Analogy: Think of it like building a house:
- Work Item: A specific house being built (123 Main St.).
- Stages: Foundation, Framing, Plumbing, Electrical.
- Steps within "Framing" Stage: Erect walls, install roof trusses, sheathe walls.
Use Case in FSC: Perfect for processes that require handoffs between different roles (e.g., Advisor -> Underwriter -> Compliance Officer -> Closer) with clear stages and audit trails.
Setup: Configured in Setup -> Flow Orchestrations.

Summary:
The three fundamental building blocks of Flow Orchestration are Steps (the individual actions), organized into Stages (the major phases), which are executed within a runtime Work Item.

Explanations

A. The bank wants to use this project as an opportunity to retire customization
Why this indicates a new org:
Financial Services Cloud (FSC) provides industry-standard data models and processes.
If the bank wants to eliminate heavy legacy customizations, starting with a clean org avoids carrying technical debt forward.
A new org allows the team to adopt FSC features out of the box instead of retrofitting them into existing custom logic.

B. The current implementation is using a product-centric view and the bank wants to move to a customer-centric view
Why this indicates a new org:
Moving from product-centric to customer-/relationship-centric is a fundamental architectural shift.
FSC introduces core concepts such as Person Accounts, households, relationships, and financial accounts.
These structural changes are often easier and less risky to implement in a new org rather than refactoring an existing data model.

E. Existing business capabilities and processes can be redesigned to deliver a higher business impact
Why this indicates a new org:
A new org is ideal when the business is open to process re-engineering, not just technical upgrades.
FSC implementations benefit most when organizations redesign processes to align with FSC best practices instead of preserving legacy workflows.
This supports higher long-term business value rather than a “lift and shift.”

Why the Other Options Are Incorrect
C. Data migration is a big concern… wants to minimize data migration efforts
This actually favors upgrading the existing org, not creating a new one.
A new org increases data migration complexity, risk, and cost.

D. The bank has limited redesign opportunities for business capabilities
Limited redesign opportunities suggest the bank wants to preserve existing processes, which aligns better with enhancing an existing org rather than starting fresh.

Exam Tip (AP-208 / FSC)
When deciding new org vs existing org:
New org → major transformation, retiring customizations, customer-centric redesign, process re-engineering
Existing org → data preservation, minimal change, incremental improvement

Explanation:

Converting from the Individual Account Model (where individual clients are modeled as standard Accounts with a custom "Individual" record type) to the Person Account Model in Financial Services Cloud requires careful preparation to avoid data loss or errors. Salesforce provides a built-in conversion tool, but strict prerequisites must be met.

The three key preparation steps are:
C: Ensure all individual account records to be converted are only linked to exactly one contact record. Each Individual Account must have precisely one associated Contact (typically via a lookup or master-detail). The conversion merges this Account-Contact pair into a single Person Account record.
D: Test out the conversion in a sandbox, including all integrations and customizations. The conversion is irreversible in production and impacts many FSC features (e.g., rollups, relationships, ARC). Thorough sandbox testing with representative data, integrations (e.g., MuleSoft, external systems), Apex, Flows, and custom components is essential.
E: Ensure each individual account to be converted is not a parent account of any other account records. Person Accounts cannot participate in Account hierarchies (no Parent Account field), so any hierarchy links must be removed or restructured beforehand.

Why not the others?
A: Incorrect — Opportunity ownership is not a prerequisite for Person Account conversion. Opportunities can remain linked and will function post-conversion.
B: Incorrect — The Account.Phone field does not need to be blank. During conversion, phone (and other standard fields) from the Contact takes precedence if duplicated, but blanking is not required.

References:
Salesforce Help: "Convert Individual Accounts to Person Accounts" (lists prerequisites: exactly one Contact, no parent/child hierarchies).
Trailhead: "Person Accounts in Financial Services Cloud" & FSC Data Model modules (emphasizes testing in sandbox due to irreversible impact).
FSC Implementation Guide: Recommends full sandbox testing for model conversions, including integrations/customizations.
Accredited Professional exam resources: Common multi-select question on Individual to Person Account conversion prerequisites.

Explanation:

RBL rules allow administrators to calculate and display summary data (like total balances or counts) at the individual client or group/household level. The building blocks for these calculations are available for a specific set of industry objects:

Financial Accounts (B): This is the most common use case. RBLs calculate the "Total Bank Account Balance," "Investment Account Value," or "Total Outstanding Loans" by looking at all financial accounts related to a person or household.
Assets and Liabilities (C): RBLs can summarize non-financial account assets (like real estate or high-value collectibles) and liabilities (like external mortgages or credit card debt) to provide a complete picture of a client's net worth.
Claims (E): In the Insurance version of FSC, RBLs are used to aggregate data about insurance claims (e.g., total claim amount paid or count of open claims) to help agents understand a policyholder's history and risk profile.

Analysis of Incorrect Answers
A. Life Events:
Incorrect. Life Events (and Business Milestones) are used for visualization on a timeline. While they provide context, they do not hold numerical "balances" or "amounts" that typically require an RBL summary for financial aggregation.

D. Contacts:
Incorrect. In FSC, the Account (specifically the Person Account) is the "Parent" record where summary data is displayed. Contacts are part of the individual model, but the RBL logic pushes the calculated values to the Account object, not the Contact object.

References:
Salesforce Help: Rollup By Lookup Rules (Managed Package)
Salesforce Help: Financial Summary Rollup
Salesforce Ben: Data Processing Engine and RBL Rules

Explanation:

The Referral Score in Intelligent Need-Based Referrals is a performance metric for the referring user (the person who made the referral). It is designed to measure the quality and success of their referrals, not just their activity.

Why D is Correct:

Measures Business Outcome: The score is fundamentally tied to revenue generation. It updates when a referral leads to a successful sale, which is indicated by an Opportunity linked to the referral being marked "Closed Won." This proves the referral was valuable.
Scoring Logic: The score typically increases based on the value of the won Opportunity. Higher-value closed deals from your referrals result in a higher referral score. This incentivizes quality, revenue-generating referrals over sheer quantity.
System of Record: The referral record (Referral__c) has a lookup to an Opportunity. When that Opportunity's stage changes to Closed Won, a workflow or process (often part of the managed package) recalculates the referring user's score.

Why the Other Options Are Incorrect:

A. The Referral Score updated when a referral is converted to an Opportunity or closed:
Incorrect. This is partially true but imprecise. The score is not updated when a referral is simply "converted to an Opportunity." Creating an Opportunity shows potential, but not success. The score is also not updated when a referral is "closed" (e.g., rejected or disqualified) without a win.

B. The Referral Score updated when a lead is created using the referral record type:
Incorrect. Creating a lead from a referral is just the first step in the process. Scoring at this point would reward users for generating leads, not for generating successful business. This would not measure the quality or outcome of the referral.

C. The Referral Score updated when a referral is assigned from the queue to a user:
Incorrect. Assignment is an internal workflow step for routing. It has no bearing on the quality or success of the referral itself and does not trigger a score update. The score is about the originator's performance, not the assignee's actions.

Key References & Concepts:
Purpose of Referral Score: To identify and incentivize top referrers within the organization. It helps answer: "Which advisors or branch employees are best at identifying high-potential client needs for other specialists?"
Components of Score: While the primary driver is Closed Won Opportunities, the score may also incorporate other factors like the referral's status or age, but the most significant update event is a closed-won deal.
Visibility: The score is typically displayed on the referring user's profile or within referral reports and dashboards.
Configuration: The exact scoring algorithm can sometimes be customized, but the trigger event (Closed Won Opportunity) is the standard, foundational rule.

Summary:
The Referral Score is a results-based metric. It is updated to reflect success when an Opportunity linked to the referral is Closed Won, thereby measuring the referring user's contribution to revenue.

Explanation:

Why These Are Correct:

B. Dynamic Actions:
Dynamic Actions allow admins to show or hide actions on a Lightning page based on record criteria, user profile, or context.
This ensures users only see the relevant actions for their stage in the process, reducing clutter and guiding them through the right steps.

C. In-App Guidance:
In-App Guidance provides walkthroughs, prompts, and tips directly inside Salesforce.
Perfect for complex processes where users need step-by-step help or reminders.
Helps with adoption and compliance by nudging users at the right time.

E. Dynamic Lightning Pages:
Dynamic Lightning Pages allow components to be displayed conditionally based on record data or user context.
This means users see only the fields, sections, or components relevant to their current process stage.
Great for tailoring the UI to complex, variable workflows.

Why the Other Options Are Incorrect:

A. Build custom Lightning pages for each stage:
Incorrect: This would create unnecessary complexity and maintenance overhead. Dynamic Lightning Pages are the better solution because they adapt conditionally instead of requiring multiple separate pages.

D. Use flows to remove the need for complex Lightning pages:
Incorrect: Flows are excellent for automating processes, but they don’t replace the need for guided UI experiences. Flows handle logic, while Dynamic Pages + In-App Guidance handle user-facing guidance.

References:
Salesforce Help: Dynamic Actions
Salesforce Help: In-App Guidance
Salesforce Help: Dynamic Lightning Pages