Free Salesforce Accredited Agentforce Financial Services Professional Practice Test Questions

Explanation

A Business Milestone Type is configured as a value in the Milestone Type picklist on the Business Milestone object.

The Salesforce Administrator should:
Go to Setup → Object Manager.
Search for and select Business Milestone.
Select Fields & Relationships.
Open the Milestone Type field.
Under Milestone Type Picklist Values, click New.
Enter the new milestone type and save.

Salesforce's documentation specifically states that to create milestone types, the administrator selects Business Milestone, then Fields & Relationships → Milestone Type, and adds the new value under Milestone Type Picklist Values.

Why the other options are incorrect

A. Incorrect: You don't create a new field for every milestone type. The existing Milestone Type picklist is designed to hold the different milestone types.

B. Incorrect: Person Life Event is used for life events such as birth, graduation, or retirement. Its Event Type picklist is separate from the Business Milestone types.

C. Correct: Business Milestone → Fields & Relationships → Milestone Type → New is the documented configuration path.

Exam Tip:
Remember the distinction:
Person Life Event → Event Type
Business Milestone → Milestone Type

Reference: Salesforce Help, Create Event or Milestone Types.

Explanation

In Salesforce, standard and custom components related to Chatter, such as the Record Feed or publisher components, depend on underlying architectural configurations to appear in the Lightning App Builder.

For an object like Action Plan to support Chatter feeds and display the Chatter/Feed component on its Lightning record page, Feed Tracking must be explicitly enabled for that object in Setup. If feed tracking is turned off for an object, Salesforce hides or omits the corresponding feed components from the available components list in the Lightning App Builder for that specific record page context.

To resolve this:
Navigate to Setup → Feature Settings → Chatter → Feed Tracking, select the Action Plan object, check "Enable Feed," select the desired fields to track, and save.

Why the Other Options Are Incorrect

Option B: Incorrect because Chatter is already fully supported across standard objects and functional frameworks like Action Plans.

Option C: Incorrect because permission sets control user-level access to functionality and objects, whereas the inability to find a component in the Lightning App Builder panel itself is a metadata/object configuration issue, such as Feed Tracking, rather than a user permission issue.

Option D: Incorrect because Chatter settings globally enable or disable Chatter for the entire organization, but individual object availability on record pages requires object-level Feed Tracking to be enabled.

Explanation

Why B is correct

Data must be loaded in order of dependency, so that each record can reference the records it relates to.

Accounts and contacts first. Everything else in FSC hangs off these. Households are built from them, and financial accounts need an account or contact as the owner.

Households (account groups) second. A household is an account record with the Household record type, and its members are linked through account-contact relationships. Members must already exist before you can group them.

Financial accounts last. A financial account must reference a primary owner, which can be a person account or a household. If the financial accounts load before those owners exist, the load fails with lookup errors.

Why the others are wrong

A: It loads financial accounts before account groups and households. A financial account owned by a household would have no owner to point to. The option text is also garbled ("Accounts are contacts"), which suggests it is a deliberately wrong distractor.

C: It loads financial accounts first, before any owner record exists.

D: It loads households first. Households are made of accounts and contacts, so those must come first. It also lists person accounts last, even though they are basic account records.

Exam tip: Remember the order as people, then groups, then what they own: Accounts and contacts, then Households, then Financial accounts. Records on the "child" side of a lookup always load after the records they reference.

Reference: Salesforce Help, "Migrate Data to Financial Services Cloud" (FSC admin guide), which covers the recommended Data Loader load order. Since the question wording is partly garbled, I'd double-check this against that page if you want to be certain, but B is the only option consistent with the lookup dependencies.

Explanation

In Financial Services Cloud (Agentforce Financial Services), the Life Events card, which is part of the Events and Milestones Lightning component, displays key personal life events for a client (Person Account/Contact). When a Wealth Advisor hovers over or expands an event, contextual actions appear that let them act on the event without leaving the page. These actions automatically associate the new record with the life event.

Standard/supported actions relevant to this exam question:

Create Lead & Referral: Creates a lead (for a new prospect) or a referral record based on the life event details, such as a home purchase triggering a referral for mortgage or insurance products.

Request Record Approval: Initiates an approval process on the life event record itself, which can be useful for compliance or quality review.

Create Opportunity: Creates an opportunity linked to the life event to track potential revenue or product needs arising from it, such as a retirement planning opportunity after a job change.

Admins can configure additional contextual actions via Object Manager → Person Life Event → Buttons, Links, and Actions. Action Plans are also available by default if enabled. However, the options listed in the question that match the documented/exam-expected capabilities are B, D, and E.

Why the other options are incorrect

A. Create Case: Cases can be created as a configurable contextual action in some setups, but it is not one of the primary/standard actions highlighted for the Wealth Advisor Life Events card in the context of this exam question.

C. Open an Account: This is not a standard or supported action available from the Life Events card.

References
Salesforce Help: Create and Configure Contextual Actions for Events and Milestones. Agents can create records such as Opportunities that are automatically associated with the life event.

Explanation

The requirement is to limit access to sensitive interaction summary notes while keeping basic attendee and date information visible. The correct approach combines Compliant Data Sharing (to enable granular, role-based sharing) with disabling Role-Hierarchy-Based Sharing (to prevent automatic access roll-up to superiors). The Manage Participants component, referred to as "Interaction Summary Participants" in option B, is the mechanism for granting explicit access to specific individuals or groups.

B. Use Interaction Summary Participants to provide the right access to individuals or groups.
The Manage Participants component allows bankers and advisors to add specific users or groups as participants to an interaction summary, assigning roles to control access. This is the operational mechanism for sharing sensitive notes only with authorized stakeholders.

D. Enable Compliant Data Sharing for Interaction Summaries.
Compliant Data Sharing is specifically designed for scenarios where interaction summaries contain confidential information such as Material Non-Public Information (MNPI). Enabling CDS allows administrators to configure advanced sharing rules and explicitly control who can see sensitive note details.

E. Disable Role-Hierarchy-Based Sharing for Interaction Summaries.
By default, Role-Hierarchy-Based Sharing is enabled for Interaction and Interaction Summary objects, meaning users above an advisor in the role hierarchy automatically gain access to records owned by their subordinates. Disabling this setting prevents the automatic leakage of sensitive notes upward through the org chart, requiring explicit sharing instead.

Why the Other Options Are Incorrect

A. Enable Compliant Data Sharing for Interactions: The sensitive data in question is the detailed notes, which reside on the Interaction Summary object, not the Interaction object itself. Enabling CDS for Interactions addresses meeting-level data, not the summary notes.

C. Disable Role-Hierarchy-Based Sharing for Engagement Interactions: The question specifically concerns limiting access to detailed notes (Interaction Summaries). Disabling role hierarchy sharing for Interactions alone does not address the summary notes. Additionally, the object name in FSC is Interaction, not "Engagement Interaction."

Key Takeaway
For sensitive interaction notes in FSC, the recommended configuration is: Enable Compliant Data Sharing for Interaction Summaries, Disable Role-Hierarchy-Based Sharing for Interaction Summaries, and use the Manage Participants component to explicitly share notes with authorized individuals or groups. This ensures notes are shared deliberately rather than automatically through the org hierarchy.

Explanation

When Compliant Data Sharing (CDS) is enabled in Financial Services Cloud, Salesforce manages access to sensitive records, such as Opportunities, through share tables.

A. Share table records are deleted:
When the Opportunity is set to Private, the system automatically removes the associated share table entries.

This ensures that no unauthorized users retain access to the sensitive Opportunity data.

C. Opportunity participant records are not deleted:
The participant records, which contain metadata about who is linked to the Opportunity, remain intact.

This allows the bank to preserve the relationship context, such as who was involved, without exposing sensitive details.

Why not the other options?

B. All opportunity participant records are deleted: Incorrect. Participants remain; only the share table entries are removed.

D. Share table records need to be manually deleted: Incorrect. CDS automates this process, so manual deletion is not required.

Reference
Salesforce Help: Compliant Data Sharing in Financial Services Cloud
Salesforce FSC Documentation: Opportunity Participants and Share Tables
Trailhead: Financial Services Cloud – Compliant Data Sharing

Explanation

The company wants two different Person Account record types:

Individual Customer
Individual Independent Advisor

In Agentforce Financial Services, the administrator should configure the Individual Record Type Mapper to map the appropriate Person Account record types.

The documented process is:
Go to Setup → Object Manager → Account → Record Types.
Create the required custom Individual record types.
Go to Setup → Custom Metadata Types.
Select Individual Record Type Mapper.
Select Manage Individual Record Type Mappers.
Create/configure the mapping records and specify the appropriate Account Record Type.

Salesforce specifically states that the Account Record Type in the mapper must reference a valid Person Account record type.

Why the other options are incorrect

A. Create custom fields on the Person Account object: Incorrect. Custom fields are used to store additional information, but they don't create or configure different Person Account record types. Record types are configured separately.

B. Configure "Individual Record Type Mapper" custom metadata: Correct. This is the key configuration used to map custom Incorrect for this question. The Use Person Account setting is relevant when enabling/configuring the Person Account data model, but it does not create the two required custom record types. Salesforce's documented process separately identifies enabling Person Accounts and configuring the Individual/Person Account record types in Agentforce Financial Services. Salesforce's current documentation explicitly identifies Individual Record Type Mapper as the configuration mechanism.

C. Create a record type on the Contact object: Incorrect. Person Accounts don't use a separate Contact record type for this configuration. Salesforce explicitly instructs administrators to leave the Contact Record Type field blank in the Individual Record Type Mapper because Person Accounts don't use the Contact record type.

D. Enable "Use Person Account" custom setting: Incorrect for this question. The Use Person Account setting is relevant when enabling/configuring the Person Account data model, but it does not create the two required custom record types. Salesforce's documented process separately identifies enabling Person Accounts and configuring the Individual Record Type Mapper.

Exam Tip

Remember:
Person Accounts enabled → Use Person Account configuration
Custom Individual/Person Account record types → Individual Record Type Mapper

Therefore:
✅ Answer: B — Configure "Individual Record Type Mapper" custom metadata.

Reference: Salesforce Help, Create and Configure Custom Record Types for Individuals and Groups in Financial Services Cloud.

Explanation

In Salesforce Financial Services Cloud (FSC), Financial Accounts Management is the core capability designed specifically to allow financial advisors to track, view, and manage various client financial holdings, such as investment portfolios, bank accounts, loans, and insurance policies, in one unified place.

It utilizes specialized objects, such as the Financial Account and Financial Holding objects, to link a client's wealth assets directly to their profile, presenting balances, asset distributions, and historical transaction information natively within the CRM layout.

Why the Other Options Are Incorrect

Option A (Performance reporting): Performance reporting is used to evaluate investment returns and portfolio performance over time, but it is an analytical function rather than the foundational tracking and management system for accounts.

Option B (Client onboarding): Client onboarding handles the introductory lifecycle workflows for getting a new client set up and integrated into the institution, rather than managing active financial accounts on an ongoing basis.

Option D (Opportunity management): Opportunity management is a standard Sales Cloud feature focused on tracking prospective sales deals and pipelines rather than managing ongoing client financial accounts and holdings.

Explanation

Why these are true

A: An RBL rule summarizes financial account data, such as balances, so advisors can see totals on the client record without adding things up manually.

C: RBL configuration drives the summary values at both the client level (the "diem" in the option is a typo for "client") and the group level, such as the household. A household shows the combined totals of its members' financial accounts.

D: Salesforce provides standard RBL rules and does not recommend or support creating or customizing them. Custom rules are the customer's responsibility, partly because of the performance impact.

Why these are false

B: Person Accounts are not required. RBL works with both the Person Account model and the Account-Contact model, so you can use it either way.

E: The reverse is true. Rollups aggregate data across many financial accounts, relationships, and groups, so they can be processing-intensive. That is also why customization is discouraged (see D).

Exam tip: Remember RBL as "summaries for clients and groups, works with either data model, resource-intensive, standard rules only." Any option claiming Person Accounts are required, or that RBL is lightweight, is likely a distractor.

Reference: Salesforce Help, "Rollup by Lookup" and "Rollups and Summaries" in the FSC admin guide. I'm answering from memory on the support and recommendation wording in D, so confirm it on that page if you want to be certain. A, C, and D are the only combination consistent with the other options.

Explanation

The requirement specifies two critical constraints: (1) capture sensitive deal information such as pitch books and market analysis, and (2) share access only with a trusted analyst, explicitly preventing managers above the associate in the Role Hierarchy from gaining access. This is a classic "ethical wall" or information barrier scenario common in investment banking, where material non-public information (MNPI) must be compartmentalized.

Financial Deal object is purpose-built for this scenario. Salesforce Financial Services Cloud introduced the Financial Deal Management data model specifically for investment banking deal tracking. It captures deal stage, status, probability, notes, and counterparties—exactly the kind of sensitive deal data described.

Compliant Data Sharing (CDS) is the required sharing mechanism. CDS is designed for regulated financial services workflows where explicit, audited record sharing is necessary. It uses Participant Roles to grant access to specific users or groups beyond org-wide defaults, with a full audit trail. Critically, when CDS is enabled for the Financial Deal object, access is granted only through the Manage Participants component—not through role hierarchy inheritance.

Role Hierarchy access can be disabled for Financial Deal. Unlike the standard Opportunity object, where role hierarchy sharing is always on and cannot be disabled, the Financial Deal object allows administrators to turn off role hierarchy-based sharing via Deal Management Settings. This is the key capability that prevents managers up the chain from automatically seeing the deal data.

Why the Other Options Are Incorrect

B. Use the Opportunity object with Compliant Data Sharing: The Opportunity object's role hierarchy sharing cannot be disabled. Even with CDS enabled, implicit sharing and upward hierarchy access would still expose the deal to management. Additionally, Opportunity lacks deal-specific entities like Financial Deal Parties for modeling counterparties.

C. Use restriction rules to block hierarchy access: Restriction rules only take access away—they do not grant access. They also cannot override role hierarchy sharing in a way that grants the analyst access while blocking managers. More fundamentally, restriction rules are not the native FSC sharing model for deal data; CDS is.

Key Takeaway

For sensitive investment banking deal data requiring strict ethical walls, the Financial Deal object combined with Compliant Data Sharing is the correct solution. This combination provides:

Deal-specific data modeling (Financial Deal Parties, products, interactions)
Explicit, audited sharing via Participant Roles
Ability to disable role hierarchy sharing, ensuring data does not leak upward automatically

This aligns with the Principle of Least Privilege for MNPI handling in financial services.