Free Salesforce Accredited Agentforce Financial Services Professional Practice Test Questions

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.