Free Salesforce AP-208 Practice Exam with Questions & Answers | Set: 2

Action Plans and Action Plan Templates are designed for repeatable, controlled business processes that contain tasks and supporting-document requirements. An Action Plan Template defines the standard sequence once, including task ownership, due dates, dependencies, and document checklist items. Each onboarding engagement can then instantiate an Action Plan from that approved template.

Salesforce positions Action Plans as a mechanism for capturing repeatable tasks and automating task sequences so that teams execute processes consistently. Action Plans can automatically assign owners and deadlines and provide reporting for monitoring progress and compliance.

The feature also supports Document Checklist Items, which is directly relevant to the KYC requirement. Action Plans and templates manage repeatable manual work, while Document Checklist Items enable reviewers to track required documentation and its approval status.

Chatter reminders provide communication but do not establish a controlled repeatable process. A custom trigger would unnecessarily duplicate declarative Financial Services capabilities and increase maintenance. Generic flow templates may automate individual operations but do not provide the same reusable combination of predefined tasks, owners, dates, document requirements, tracking, and reporting. An Action Plan Template therefore provides the appropriate standardized control for ensuring onboarding tasks are consistently performed.

Financial Services data migration must respect object dependencies and relationship references. Salesforce recommends loading customer identities before relationship groups and then loading financial-account information only after the required customer and household structures exist.

The sequence starts with Accounts and Contacts because these records represent the customers or individuals to whom subsequent Financial Services records will relate. Household or relationship-group records are then created so those individuals can be organized into the appropriate household structure. Financial Accounts follow after these foundational customer and group records exist.

The reason is referential integrity. Household records depend on identifiable customers and their relationship structures. Financial Accounts, in turn, must connect to owners and other participants through Financial Account relationships and therefore require existing customer records.

The broader migration sequence can continue after Financial Accounts with Financial Account Roles, transactions, cards, holdings, statements, and other dependent records. Loading child or transactional data before the referenced parent records would create lookup failures or incomplete relationships.

Therefore, among the supplied choices, the correct high-level migration order is Accounts and Contacts, then Households, then Financial Accounts.

In a multi-currency Salesforce organization, currencies must first be configured as active currencies. Salesforce administrators maintain active currencies through Manage Currencies, and only active currencies can be used for record currency amount fields. Therefore, if GBP has not been activated in the org, users cannot properly create or work with GBP-denominated records.

When multiple currencies are enabled, Salesforce uses the standard CurrencyIsoCode field to identify the record ' s currency. Appropriate user-interface configuration must expose this currency identification where testers need to inspect and work with the record ' s currency.

Advanced Currency Management does not determine whether GBP is available. Its purpose is to maintain dated conversion rates, especially for opportunity-based currency conversion. Likewise, an administrator ' s personal default currency being CAD does not deactivate GBP or prevent other users from working with active currencies. Each Salesforce user can have a personal currency while records retain their individual CurrencyIsoCode values.

Therefore, the configuration should ensure that GBP is active and that the relevant record currency information is exposed to users.

The relationship structure in option C reflects the essential Agentforce Financial Services household-modeling rules. Rachel ' s own household is her Primary Group, and Rachel is its Primary Member. Her spouse, Nigel, is another household member related through the spouse relationship. The Addams Charitable Trust is represented as a related business account, while the attorney is represented as a related professional contact.

Salesforce household modeling uses this same conceptual structure. A customer such as Rachel is represented by a Person Account and can be marked as both the household ' s Primary Member and as having that household as the Primary Group. A spouse is added as another group member and is connected through an explicit spouse relationship. A trust is represented by a Business Account and related to the household through an account relationship.

A person can participate in multiple groups but can have only one Primary Group because that designation determines the household to which eligible financial information and activities roll up. Rachel can therefore belong to the Symonds household as a beneficiary while retaining the Addams household as her Primary Group.

This structure provides the advisor with a complete view of Rachel ' s immediate household, family affiliations, trust relationship, and professional connections.

Actionable Relationship Center is designed specifically to help Agentforce Financial Services users understand complex relationships among customers, households, businesses, trusts, contacts, and other related entities.

ARC presents these connections through an interactive relationship graph rather than requiring the wealth manager to interpret separate related lists manually. It can connect business accounts, Person Accounts, and Contacts and display relevant relationship information in the graph.

The Addams scenario is an ideal use case. The wealth manager needs to understand the wife ' s membership in the Addams Household, her spouse relationship, their shared connection to the Addams Charitable Trust, and her separate connection to the Symonds Household. ARC can visualize these multi-party relationships through Account Contact Relationship, Account Account Relationship, and Contact Contact Relationship junction objects.

ARC also supports configurable custom relationship graphs, record actions, node display fields, details panels, highlights panels, and preconfigured Financial Services templates.

Tableau and Marketing Cloud Intelligence provide analytics and visualization capabilities but are not designed to present the operational Financial Services relationship graph directly within the advisor workflow. ARC provides the relationship context needed to understand spheres of influence, recognize connections, and identify potential service or business opportunities.

Record Alert Categories are optional, but Salesforce recommends them because they provide a structured mechanism for organizing alerts by priority, severity, type, or another business classification. For example, an administrator can define a High Priority category and associate relevant client alerts with that category so advisors can quickly distinguish urgent information from routine notifications.

A category can have a configured severity value. When an advisor selects that category while creating a Record Alert, the category ' s severity becomes the default, but the user can change that value. This makes the statement that the severity cannot be changed incorrect.

Record Alerts are available on all custom objects and on a defined list of supported standard objects rather than indiscriminately on every standard object. Financial Services also provides specialized alert experiences for person accounts, financial accounts, and financial account transactions through its Record Alerts framework.

The relevant configuration principle is therefore that categories improve organization and usability while remaining optional. Administrators can design a category structure that reflects the institution ' s servicing and risk priorities, but a Record Alert can still be created without assigning a category when the business process permits it.

Compliant Data Sharing has specific behavior when an Opportunity is changed to Private. A private Opportunity cannot be shared through Compliant Data Sharing, so Salesforce removes the sharing entries that previously granted participant-based record access.

Salesforce documents that when an Opportunity contains Opportunity Participants with associated share-table records and the Opportunity is made Private, the share-table records are deleted. However, the Opportunity Participant records themselves remain in Salesforce.

This distinction is important because the participant record represents the business relationship or participation assignment, while the share-table record represents the actual access grant generated by Compliant Data Sharing. Setting the Opportunity to Private removes the access mechanism without automatically destroying the participant data.

Salesforce recommends removing participants before making an Opportunity private when appropriate. If an Opportunity is subsequently made shareable again, the participant may need to be recreated or toggled inactive and then active so that the required sharing entry is regenerated.

Therefore, manual deletion of the share-table entries is unnecessary. Salesforce performs that cleanup automatically, while preserving the underlying participant records.

Organization-Wide Defaults establish the baseline record visibility for users who otherwise have the required object-level permissions. To make Person Account records broadly visible, the Account or Person Account sharing model should provide Public Read Only access. Public Read Only allows all applicable users to view and report on records while reserving editing rights for users who receive additional access.

Financial Accounts contain sensitive financial information, so their baseline sharing should instead be Private. With Private sharing, users do not automatically gain access merely because they can access the Financial Account object. Access can subsequently be expanded only to authorized users through record ownership, role hierarchy where appropriate, sharing rules, manual sharing, Compliant Data Sharing, or another approved mechanism.

Setting Financial Accounts to Public Read Only would expose them broadly and directly contradict the stated privacy requirement. Likewise, removing a Financial Accounts tab or component from a Lightning page is not a security mechanism. A user who retains record access could still potentially retrieve the information through reports, search, APIs, related lists, or another Salesforce interface.

Therefore, the appropriate record-level model is Public Read Only for Person Accounts and Private for Financial Accounts, followed by selective access grants for authorized Financial Account users.

An Action Plan is the appropriate Agentforce Financial Services capability when an organization has a standardized sequence of activities that must occur at defined intervals and needs those activities to remain visible and reportable in Salesforce. Action Plan Templates define repeatable tasks, task ownership, sequencing, and date offsets. When an Action Plan is instantiated, those template items become operational tasks that relationship managers can complete and track.

In this scenario, the meaningful business event is the customer ' s transition to an established Customer state after opening the first banking relationship. That event should initiate an Action Plan containing follow-up tasks scheduled at the required 2-day, 2-week, and 2-month offsets. This accurately aligns the operational workflow with the point at which the individual becomes a customer.

Simple email notifications do not provide the same task lifecycle, completion status, ownership, reporting, and dashboard capabilities. Similarly, triggering the plan at initial Account creation or lead conversion could occur before the required customer milestone. Salesforce specifically positions Action Plans for repeatable engagements such as account openings and allows task deadlines and ownership to be standardized while supporting reports and dashboards for progress monitoring and compliance.

Interest Tags enable Financial Services users to categorize customer interests and associate those interests with supported records, including Interaction Summaries. Access is controlled through specific Financial Services permissions rather than being universally included in every Financial Services permission set.

Salesforce identifies Financial Services Cloud Extension and Financial Services Cloud Foundations as permission sets that provide the relevant Interest Tags capabilities. Current Salesforce documentation lists these permission sets among those used in Financial Services for access to Interest Tags functionality.

Salesforce also states that users who add Interest Tags to Interaction Summaries require appropriate Financial Services access, including Financial Services Cloud Extension or Financial Services Cloud Foundations, depending on the product configuration. Before users can work with the feature, administrators must also enable Topics and Interest Tags and configure the relevant object for Topics.

Cloning one of these permission sets provides an appropriate baseline when an organization needs a specialized permission set while retaining the required Interest Tags permission. The Financial Services Cloud Standard and Basic permission sets serve other user-access patterns and do not constitute the specified source permission sets for this capability. Therefore, Extension and Foundations are the appropriate permission-set templates.