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

Explanation

In Financial Services Cloud (FSC), the relationship tree allows advisors to visualize and manage client relationships. When using the Add Contact option, the system relies on reciprocal roles, such as Client ↔ Attorney or Parent ↔ Child.

A. Sharing rules not set up: If sharing rules for reciprocal roles are missing, the lookup will not display them. Proper configuration is required to ensure reciprocal roles are available for selection.
C. Reciprocal roles not created: If the org has not defined reciprocal roles, such as “Attorney” ↔ “Client,” they simply won’t appear in the lookup. Reciprocal roles must be explicitly created in Setup.

Why not the other options?

B. Member Relationship button under Actionable Relationship Center: This is a different feature used for actionable relationships, not for reciprocal role setup in the relationship tree.
D. Edit Group button: This is used for editing group memberships, not reciprocal role definitions.

Reference
Salesforce Help: Reciprocal Roles in Financial Services Cloud
Trailhead: Financial Services Cloud – Relationship Groups and Trees

Explanation

When an external system will push data into Salesforce via API, the Salesforce org must be prepared so the data can be received, authenticated, and stored correctly.

A is required: Create a dedicated Integration User, ideally using the Salesforce Integration User license, and assign it a restricted profile such as Minimum Access – API Only Integrations or a custom Integration Profile. This follows the principle of least privilege, provides clean audit trails, and allows the external system to authenticate through a Connected App, OAuth, Named Credentials, or similar mechanism without using a regular user's credentials.

D is required: You must have the appropriate objects and fields, such as standard FSC objects including Financial Account, Financial Account Role, Assets & Liabilities, and/or custom objects and fields, ready to receive and store the incoming data. Without a target data model, the API calls have nowhere to store the records.

Why the other options are incorrect

B — A Lightning Web Component: A Lightning Web Component is a UI element used to display or interact with data. It is not needed to prepare Salesforce for inbound API data.
C — A Flow: A Flow is not required for inbound API integration. The external system can create or update records directly through the Salesforce REST, SOAP, or Bulk APIs. Flows are useful for orchestration or outbound callouts, but they are not a prerequisite for receiving data.

Key preparation steps

Define or extend the data model (objects and fields).
Create and permission a dedicated Integration User and profile/permission sets with the minimum object and field access needed.
Configure authentication, such as a Connected App and OAuth.
Optionally, set up Named Credentials, remote site settings, or integration definitions as needed.

Key Takeaway
The two foundational configurations required before an external system can successfully send data are the Integration User/Profile and the target objects/fields.

Explanation

I verified this against current Salesforce documentation. The key point is that Interest Tags are a virtual object built on the Topics object, but the custom report type must use Tag Categories as the Primary Object.

A. The user must build a report using the Topics object to view Interest Tags in the report. — Correct ✅
Interest Tags don't function as a standalone physical object for reporting. Salesforce states that the Interest Tags object is a virtual object on the Topics object.
Therefore, when creating the custom report type, Topics must be added as the related object so the report can expose Interest Tag information such as:

Topic: Name
Description
Topic Assignment: Name

B. When the user defines the custom report type, Tag Categories should be selected as the Primary Object. — Correct ✅
This is the important configuration step.
Salesforce's documented procedure is:
Setup → Report Types → New Custom Report Type → Primary Object = Tag Categories
Then add Topics as the related object.

The report can subsequently group the Interest Tags by Category Name. Salesforce Trailhead demonstrates the same configuration: Tag Categories as the primary object and Topics as the related object.

Why C is incorrect

C. Topics should be selected as the Primary Object. — Incorrect ❌
Although Interest Tags are built on the Topics object, Salesforce's documented report configuration requires Tag Categories as the Primary Object.
Topics is the related object, not the primary object.

Why D is incorrect

D. Add a filter and select the object name. — Incorrect ❌
To show Interest Tags applied to a particular type of Salesforce record, Salesforce instructs administrators to use the Record Key Prefix as the filter, rather than simply selecting an object name.
For example, the administrator can add a filter for Record Key Prefix and enter the first three characters of the relevant record ID.

Exam Tip
Remember the reporting structure:
Tag Categories = Primary Object
↓
Topics = Related Object
↓
Topics represents the virtual Interest Tags object

Answer:
✅ A + B

References: Salesforce Help, Build an Interest Tags Report and Considerations and Limitations for Interest Tags.

Explanation

Salesforce Financial Services Cloud (FSC) offers robust visual components designed to map complex networks involving accounts, contacts, and households:

Actionable Relationship Center (ARC) (Option A): A powerful, configurable Lightning component that displays multi-directional account and contact relationships in a convenient interface. Users can view, create, edit, and delete relationships directly from the component tree.

Relationship Map (Option C): A graphical, node-based component that provides a visual representation of all connections for a client or group. It helps advisors quickly navigate complex relationship networks and hierarchies at a glance.

Group Members Component (Option D): Specifically tracks and displays the members associated with a group or household, leveraging Account-Group relationships, and enables users to view, add, and remove group participants seamlessly.

Why the Other Options Are Incorrect

Option B (Family Members Component): This is a more specific subset component usually centered on household rollups, but the generalized architectural components built to handle the broad scope of Account-Account, Account-Contact, and Contact-Contact relationship updates across FSC are ARC, Relationship Map, and Group Members.

Option E (Life Events Component): This is used exclusively for tracking chronological milestones and life events, such as purchasing a home, marriage, or retirement, rather than structural relationship mapping between accounts and contacts.

Explanation

Why these are true

B: Setting OWD on Account, which includes Person Accounts, to Public Read Only lets all users, including call center agents, see every person account. OWD sets the baseline of access, so this is how you make person accounts broadly visible.

D: Setting OWD on Financial Account to Private means users can only see financial accounts they own or that are shared with them through roles, sharing rules, or financial account sharing. Only the specific users who need access are granted it, which protects client privacy.

Why the others are wrong

A: Public Read Only on Financial Accounts would let every user, including call center agents, see all financial accounts. That is the opposite of what the bank wants.

C: Removing a tab or editing a Lightning page only hides navigation. It doesn't control record access. Agents could still reach financial accounts through related lists, search, reports, or direct links. Record-level security has to be enforced with sharing settings, not UI changes.

Exam tip: Visibility questions are answered with OWD and sharing rules, not page layouts or tabs. Open up the object everyone needs, Account: Public Read Only, and lock down the sensitive one, Financial Account: Private.

Reference: Salesforce Help, "Organization-Wide Sharing Defaults" and "Financial Account Sharing in Financial Services Cloud" (FSC admin guide). If Financial Services Cloud's "Compact Financial Account Sharing" or sharing-rule options come up in other questions, those are the tools used to then grant access to specific users.

Explanation

When integrating Salesforce with external systems, such as a risk control system in an insurance implementation, security best practices dictate following the principle of least privilege.

Create a dedicated Integration User (Option B): You should never share user credentials or use a human user's account for backend system-to-system communications. A dedicated integration user isolates the connection and makes auditing API requests straightforward.

Create a new custom profile with "API Only" selected (Option A): Salesforce provides an API Only User permission or profile-level setting that ensures the integration user can connect only through APIs and is blocked from logging into the standard Salesforce user interface (UI). Combining this with a custom profile allows the consultant to restrict object and field access strictly to what the risk control system requires.

Why the Other Options Are Incorrect

Options C and D: These are incorrect because assigning an integration user to the System Administrator profile violates security best practices. Giving an external API full administrator rights exposes the entire Salesforce organization to severe security vulnerabilities if the API credentials were ever compromised.

Explanation

Why D is correct
In the Actionable Relationship Center, the relationship graph is built from nodes, such as a person, a business, or a financial account. Each node's appearance is defined in the ARC configuration, where the node has its own Display tab.
To customize how a node looks, the developer builds a FlexCard and then, on that node's Display tab, selects the option to use the FlexCard. ARC then renders the node's details with that card.

Why the others are wrong

A: The node Actions tab controls what a user can do from a node, such as launching an OmniScript to start a process. It doesn't control how the node is displayed, so it fits the wrong purpose.
B: Customization isn't done by referencing a Lightning Web Component in graph-level Display properties. ARC node display is built on FlexCards, not custom LWCs referenced this way.
C: The FlexCard is attached per node on the node's Display tab, not by referencing it in graph-level Display properties.

Exam tip: Display tab = how the node looks (FlexCard). Actions tab = what the node does (OmniScript, flows, and similar). If a question is about appearance, think FlexCard.

Reference: Salesforce Help, "Actionable Relationship Center" and "Configure ARC Nodes" in the FSC admin and developer guides. I'm answering from memory on the exact tab and option labels, so confirm them in the ARC configuration page in your org or in the documentation if you want to be certain.

Explanation

Option B: Bankers in Japan have been accessing FSC in Japanese, but the new bankers in China will be accessing FSC in Chinese.
This is the most plausible expectation. Salesforce allows each user to have their own display language set on their User record. If the org has enabled both Japanese and Chinese as supported languages, users in each region can work in their native language. This is a core multi-language capability.

Option C: In Seoul, South Korea, the branch managers will be reviewing their FSC dashboards every morning in Korean, while their colleagues in Shanghai, China, will be doing so in Chinese.
This is also a valid expectation. Dashboards and reports can display translated labels, such as field names, based on the user's language setting. If the org has configured translations for Korean and Chinese, each group can view their dashboard in their preferred language.

Option A: Referrals in Singapore and Hong Kong will be shared in English, but in Macau, referrals will be shared in Portuguese.
This is less likely. While the Salesforce interface can be displayed in different languages, record data, such as the text in a referral record, is entered in whatever language the user types. Salesforce does not automatically translate record data between users. For referrals to be "shared" in Portuguese, the data itself would need to be entered in Portuguese.

Option D: In Tokyo branches, the names of the Account, Prospect, and Contact are in Japanese, but the package Advisor, Personal Banker, Relationship Manager, and Client Associate profiles are in English.
This is a misunderstanding of how multi-language works. Profile names are metadata, not data. You can translate custom labels and some metadata through the Translation Workbench, but standard profile names are typically not user-translatable. Record names, such as Account names, are data and remain in the language in which they were entered, regardless of the viewer's language setting.

Recommendation
The two most likely correct answers are B and C. They both describe the core multi-language capability: different users can see the Salesforce interface and standard labels in their own preferred language.

Explanation

In Salesforce Financial Services Cloud (FSC), permission set licenses (PSLs) dictate the level of underlying features and objects a user can access.

FSC Standard Permission Set License: This license is designed for standard core banking, wealth management, and retail banking roles, such as personal bankers, wealth advisors, and financial representatives, who require full out-of-the-box access to core FSC objects like Financial Accounts, client goals, life events, and relationship maps.

Why the Other Options Are Incorrect

Option A (FSC Foundations): FSC Foundations serves as a modular or supplemental licensing layer used to grant specialized or base extension features rather than comprehensive core functionality for general banking roles.
Option C (FSC Extension): FSC Extension is used as a supplemental licensing layer to provide additional or specialized FSC capabilities rather than the comprehensive core functionality required by general banking roles.
Option B (FSC Basic): FSC Basic is typically aligned with lightweight or limited-access use cases, such as restricted views or specific community/partner scenarios, rather than the rich daily workflows managed by personal bankers.

Explanation

Why these are true

C: Setting OWD on Account, which includes Person Accounts, to Public Read Only lets all users see every person account. OWD sets the baseline access, so this is how you make person accounts broadly visible.

D: Setting OWD on Financial Account to Private means users can only see financial accounts they own or that are shared with them through roles, sharing rules, or financial account sharing. Only the specific users who need access are granted it.

Why the others are wrong

A: Public Read Only on Financial Accounts would let every user see all financial accounts, which is the opposite of the goal.

B: Removing a tab or editing a Lightning page only hides navigation. It doesn't control record access, since users could still reach financial accounts through related lists, search, reports, or direct links. Record-level security has to be enforced with sharing settings.

Exam tip: Visibility questions are answered with OWD and sharing rules, not page layouts or tabs. Open up the object everyone needs (Account: Public Read Only) and lock down the sensitive one (Financial Account: Private).

Reference: Salesforce Help, "Organization-Wide Sharing Defaults" and "Financial Account Sharing in Financial Services Cloud."