Free Salesforce-Accredited-Agentforce-Financial-Services-Professional Practice Test Questions (2026)

Explanation

For Agentforce Financial Services Action Plans, the administrator configures nonwork days through the organization's default Business Hours record.

To indicate that a day is a nonworking day, the administrator should leave that day's Start Time and End Time fields blank. Action Plans then treats that day as a nonwork day when the user selects Skip Nonwork Days while calculating task completion dates.

For example:
Monday–Friday: 8:00 AM–5:00 PM
Saturday: Start and End blank
Sunday: Start and End blank

Action Plans will therefore skip Saturday and Sunday when calculating task completion dates with Skip Nonwork Days enabled.

Why B is correct

B. Omit the day's start and end time fields when the administrator wants to indicate a non-working day. — Correct ✅
< Salesforce explicitly states that to indicate a nonworking day, the administrator should leave the day's start and end time fields blank in the default Business Hours record.

Why A is incorrect

A. Add non-work days to the date offset... — Incorrect ❌
Nonwork days aren't manually added to the date offset. Instead, Action Plans determines nonwork days from the default Business Hours record and applicable holidays. The Skip Nonwork Days option tells Action Plans to account for those days when calculating the task's completion date.

Why C is incorrect

C. Configure the day without business hours... even if the day is a recurring holiday. — Incorrect ❌
The first part is correct: a day with no business hours is considered a nonwork day. However, the statement is incorrect because recurring holidays are not considered nonwork days by Action Plans for task completion-date calculations.

Why D is incorrect

D. Select Recurring Holidays as Action Plans... — Incorrect ❌
This is the opposite of Salesforce's documented behavior. Do not select Recurring Holiday for company-wide holidays that need to be skipped by Action Plans. Salesforce explicitly states that recurring holidays aren't identified as nonwork days when calculating task completion dates.

Exam Tip
Remember these three rules:
Business Hours
→ Blank Start/End Time = Nonwork Day

Action Plan
→ Select Skip Nonwork Days
Company Holiday
→ Use a non-recurring holiday if it must be skipped by Action Plans.

Answer:
✅ B — Omit the day's start and end time fields.

Reference: Salesforce Help, Set Up Nonwork Days for Action Plans.

Explanation

Why Options B and E are correct:

Document Generation: This OmniStudio feature allows organizations to build dynamic templates (Word or PowerPoint) and generate prefilled client documents or PDFs (like address update confirmations or disclosures).

DataRaptor: OmniStudio DataRaptor is used to retrieve, transform, and map data from Salesforce objects (such as the updated contact and address information gathered in the OmniScript) into the document template placeholders.

Why other options are incorrect:

Calculation Procedure (A): Used for complex calculations, pricing, or financial modeling (e.g., insurance quotes or interest calculations), not for document generation layout or template rendering.

Integration Procedure (C): While Integration Procedures can orchestrate data calls and can be used behind the scenes in complex architectures, DataRaptor is the fundamental data extraction/mapping tool paired directly with Document Generation templates.

OmniStudio Action (D): This is a component used inside an OmniScript to trigger server-side actions (like invoking an Integration Procedure or DataRaptor), rather than being a standalone tool for structuring/generating the prefilled PDF itself.

References
Salesforce Help: OmniStudio Document Generation Overview
Salesforce Help: OmniStudio DataRaptors

Explanation

In Agentforce Financial Services (formerly Financial Services Cloud), access to mortgage functionality is gated by the Mortgage permission set, which grants the user the mortgage license. Salesforce's own Trailhead training for this feature states that admins "use the mortgage permission set to assign users... licenses to the mortgage feature" — this is the very first step in setting up mortgage user access, before any object-level permissions are configured.

The Mortgage permission set is required to access the Residential Loan Application object and its related objects (Loan Applicant, Loan Application Financials, Loan Application Properties, etc.). Without it, the user cannot create, edit, or even view residential loan application records.

Once the Mortgage permission set (license) is assigned, an admin then builds enhanced permission sets (e.g., Loan Officer, Underwriter) that include the system permission "User license to access mortgage in Financial Services Cloud" and CRUD access on Residential Loan Applications — but that license prerequisite comes from the Mortgage permission set first.

Why the other options are wrong

A. "Mortgage User" checked on the user record: There is no standard "Mortgage User" checkbox on the Salesforce User object. Mortgage access is granted via permission sets, not a user-record flag. This is a distractor.

C. The Residential Loan Application flow was not enabled: No such Setup toggle gates record creation. Flows like Borrower Information or Lender Loan Information exist for guided data capture, but they are deployed via Actions & Recommendations on record pages — they don't control whether records can be created.

D. "Allow Mortgage Access" in Setup: This setting doesn't exist in Setup. It sounds plausible (there is a real Mortgage Settings page in Setup), but org-level enablement alone doesn't grant a user access — the Mortgage permission set assignment is what unlocks the object for that user.

Reference
Salesforce Help — Assign the Mortgage Permission Set (cited in Trailhead: "Setup User Access for Mortgage Features")
Salesforce Help — Create Enhanced Mortgage User Permission Sets

Explanation

The key to this question is understanding the distinction between object-level permissions (the ability to see the Financial Deal tab and create records) and record-level access (the ability to see a specific Financial Deal record).

Why D is correct: Financial Deal records use Compliant Data Sharing (CDS) as their primary access mechanism. Once an object is enabled for CDS, access to individual records is granted by adding users (or groups) as participants on that specific record. The Financial Deal Participants related list is the standard interface for doing this. When you add a group and assign a Participant Role, all members of that group inherit the access level defined for that role (e.g., Read Only or Read/Write) for that specific deal record only.

Why A is incorrect: Changing the Organization-Wide Default (OWD) to Public Read/Write is actually counterproductive for compliant sharing. CDS is specifically designed to work when the OWD is set to Private or Public Read-Only. If the OWD is Public Read/Write, everyone already has access to all records, and CDS has no effect. Furthermore, this would defeat the purpose of restricting access to confidential deal information like MNPI.

Why B is incorrect: A permission set grants object-level permissions (allowing users to see the tab, create records, or edit fields), but it does not grant access to specific records. Without being added as a participant on a particular Financial Deal record, a user with the permission set still cannot see that record if the OWD is Private.

Why C is incorrect: "Industries Settings" is not a valid configuration path for granting Financial Deal access. The correct setup involves enabling Deal Management Settings and then configuring Compliant Data Sharing for the Financial Deal object.

Reference
According to Salesforce Trailhead, after setting the OWD for Financial Deals to Private and enabling Compliant Data Sharing, access is managed by adding participants: "On the Financial Deal Participants related list, click New... The user now has read-only access to the record as specified in the Corporate Investment Banking Analyst role". The same module confirms that participant groups allow you to "share records with the group instead of individual members".

Explanation

The Policy Administration component in Salesforce Insurance solutions manages key policy lifecycle activities, including:

Endorsements: Changes made to an existing policy, such as modifying coverage, adding insured parties, or updating policy terms.

Payments: Billing and premium payment processing are part of the policy lifecycle managed by Policy Administration. Salesforce's Policy Administration module includes billing capabilities.

Commissions: Calculation and management of agent/broker commissions are supported within the Policy Administration solution.

Why the Other Options Are Incorrect

A. Approvals: Approvals can be used within workflows, but they are not considered one of the primary insurance processes managed by the Policy Administration component itself. They support processes rather than represent a core policy administration function.

C. Underwriting: Underwriting is typically a separate insurance function. Policy Administration may interact with underwriting processes, but underwriting is generally not categorized as a Policy Administration process.

Exam Tip
For AP-208, remember that Policy Administration focuses on the policy lifecycle after and around policy issuance, including billing/payments, endorsements, renewals, and commissions. Underwriting is usually treated as a distinct business capability.

Explanation

This is a deliberate trap question: the stem says "Once-in-a-Lifetime," but that phrase describes the use case, not the name of the configuration. The actual Salesforce feature is called Unique event types. Salesforce's own Help documentation is titled "Capture Once-in-a-Lifetime Events with Unique Event Types" and explains that some events occur only once in a lifetime, such as a birth. To prevent users from accidentally creating more than one event of such an event type, the event type can be marked as unique.

The configuration is done in the Events and Milestones settings (Setup → Financial Services Cloud → Events and Milestones → Event Types). When you create or edit an event type, you mark it as unique. Configuring an event type as unique enforces once-in-a-lifetime semantics by preventing more than one event of that type from being created for the same customer.

So, to give advisors the Events and Milestones component on the Lightning record page, you add the component (and the related list to page layouts), and to control cardinality, you mark specific event types as Unique.

Why the other options are wrong

A. Once-in-a-Lifetime event types: There is no configuration by this name. It's the scenario description Salesforce uses in documentation, planted as bait because it appears verbatim in the question stem.
B. Special event types: Doesn't exist in the Events and Milestones settings. Pure distractor.
D. Single event types: Also doesn't exist. Don't confuse this with Entitlement Management milestones, which have a "No Recurrence" recurrence type — that's a Service Cloud concept and unrelated to FSC life events.

Practical tip for the exam: Whenever an FSC question's stem uses a phrase that matches one answer option word-for-word, be suspicious — Salesforce often names the real setting something slightly different. Here, "Once-in-a-Lifetime" appears in the stem and as option A, but the correct configuration is the Unique event type.

Reference
Salesforce Help — Capture Once-in-a-Lifetime Events with Unique Event Types (ind.fsc_admin_unique_event_type.htm).

Explanation

For the Financial Account Summary component in Financial Services Cloud, Salesforce specifies that the user's Locale setting and user's Currency setting must match for commas, decimal separators, and currency symbols to display correctly.

For example, the Locale determines formatting such as:

Number separators
Decimal separators
Currency formatting
Date and time formats

Salesforce documentation specifically states that, for the Financial Account Summary component, the user's locale in Locale Settings and the user's currency must match.

Why the other options are incorrect

A. User's locale and language must match user's currency — Incorrect
The requirement is about the Locale and Currency settings. The user's language does not need to match the currency.

B. User currency must match org default currency — Incorrect
This is not the requirement for displaying commas and currency symbols correctly. Salesforce does have other currency-related requirements in Financial Services Cloud, but this specific display requirement concerns the user's locale and currency.

C. User's locale must match user's currency — Correct
This directly matches Salesforce's documented requirement.

D. Account currency must match org default currency — Incorrect Account currency matching the organization's default currency is related to certain currency calculations and rollup behavior, not the specific formatting of commas and symbols on the Financial Account Summary component.

Exam Tip
Remember this distinction:
Financial Account Summary formatting → User Locale + User Currency
So the answer is:
C. User's locale must match user's currency.

Explanation

Stages (B): A stage is a container that groups related steps into a phase of the orchestration, such as "Collect documents" or "Underwrite." Stages run in sequence, and steps within a stage can run in sequence or in parallel.

Steps (A): A step is a unit of work within a stage. A background step runs automated work with no user input, such as an autolaunched flow. An interactive step involves a person and uses a screen flow.

Work Items (D): An interactive step creates a work item, which is the task assigned to a user, group, or queue. It appears in the assignee's work items list, usually through the Orchestration Work Guide component, and links to the flow they must complete.

Why the others are wrong:

C. Processes: Process Builder is a separate, legacy automation tool and is not part of Flow Orchestration.

E. Blocks: This is not a Flow Orchestration concept.

References:

Trailhead: Flow Orchestration Basics, which covers stages, steps, and work items.
Salesforce Help: Flow Orchestrator and Orchestration Building Blocks.

Confidence Note: Stages and Steps are correct, and Work Items is the best fit for the third option. C and E are clearly distractors, making A, B, and D the workable combination.

Explanation

The key to this question is understanding that Actionable Relationship Center (ARC) access is not granted through the core Financial Services Cloud licenses (Standard or Basic). It requires a specific permission set license that extends the base FSC functionality.

Why D is correct: According to Salesforce Trailhead guidance for Agentforce Financial Services administrators, the recommended approach to give users ARC access is to clone the Financial Services Cloud Extension permission set and then confirm the "Access Actionable Relationship Center" system permission is enabled. This indicates that the Financial Services Cloud Extension permission set license is the foundational license needed to build upon for ARC access.

Why A and B are incorrect: Financial Services Cloud Standard and Financial Services Cloud Basic are the core FSC user licenses that provide access to fundamental objects like Households, Financial Accounts, and Financial Goals. However, ARC is an extended feature that is not included in these base licenses. Users with only Standard or Basic would not have the "Access Actionable Relationship Center" permission available to them.

Why C is incorrect: OmniStudio is a separate licensing and permission set framework used for building interactive UI components (OmniScripts, FlexCards). While some FSC features may use OmniStudio components, ARC access is not controlled through the OmniStudio permission set. It is an FSC-specific feature governed by FSC permission set licenses.

Exam Tip: When you see a question asking about "extended" FSC features like ARC, always look for Financial Services Cloud Extension as the answer. The base Standard and Basic licenses grant foundational access, but Extension is required for the advanced relationship visualization tools.

Explanation

Record Rollups in Financial Services Cloud aggregate information from related records at the client or group level. The mechanics work like this:

Client level: Client-level aggregation happens by default with no setup required — the supported objects (Financial Accounts, Opportunities, Cases, Tasks, Events, Claims, Insurance Policies, etc.) roll up to the client's related lists automatically.

Group level: Group-level rollups must be enabled, and for certain objects you must also add the object as a picklist value to the Rollup__c field on the Account Contact Relationship object to control which record types roll up to the group.

This is a managed-package feature, so the steps live in Setup → Financial Services Cloud settings (see Salesforce Help: Enable Group Record Rollups (Managed Package)).

Why the other options are wrong

B. This is the trap — it describes a real mechanism but names the wrong field. When group rollups are enabled, qualifying records are stamped with the Primary Group, but in the Household__c lookup field on those records (which drives the group-level components), not in a "Rollup__c lookup field." The Rollup__c field on Account Contact Relationship is a picklist, not a lookup.

C. Client-level records are aggregated by default — no configuration is needed. And rollups only go to the client's Primary Group (one group per record), not "to all primary group members" or all groups.

D. Wrong field name. Opportunities do require a picklist value — but it's added to Rollup__c on Account Contact Relationship, not to Household__c. Household__c is the lookup field used to stamp records with their primary group, not a field you add picklist values to.

Exam Tip: FSC loves pairing a correct mechanism with a subtly wrong field name. Remember: Rollup__c (picklist, on Account Contact Relationship) = what rolls up; Household__c (lookup, on the records themselves) = where it rolls up to.

Reference:
Salesforce Help — Enable Group Record Rollups (Managed Package)
Salesforce Architects Blog — FSC Rollup Engines Compared