AP-208 Exam Questions & Answers

Salesforce security should be implemented by separating object and field permissions from record-level access. Permission sets and the Financial Services-provided permission sets determine which objects, fields, applications, and Financial Services capabilities a user can access. This approach is preferable to attempting to manage every requirement exclusively through custom profiles because permission sets provide modular, additive access that can be assigned according to job function. For record visibility, Organization-Wide Defaults establish the baseline access level. Because the stated requirement is that records remain private, OWD must be configured restrictively for the relevant objects. Salesforce recommends establishing the most restrictive appropriate OWD first and then using the remaining sharing mechanisms to selectively broaden access. The Role Hierarchy then satisfies the managerial-access requirement. Users higher in the hierarchy can inherit access to records owned by, or shared with, users below them. Salesforce specifically identifies the role hierarchy as the mechanism for extending record visibility upward through the management structure. Explicitly sharing every subordinate's individual records with each manager would introduce unnecessary administration and duplicate functionality already provided by the hierarchy.

The appropriate Financial Services access level for Personal Banker users is the Financial Services Cloud Standard entitlement represented by option A. Salesforce's Personal Banker configuration guidance instructs administrators to create the user with the Personal Banker profile and then assign the Financial Services Cloud Standard and Personal Banker Access permission sets. This combination supplies the Financial Services capabilities required by the retail-banking persona together with the persona-specific permissions required for personal-banking functionality. The broader Agentforce Financial Services user-creation guidance follows the same access pattern. Personal Banker, Advisor, and Relationship Manager personas use Financial Services Cloud Standard together with their persona-specific permission sets. Salesforce distinguishes between permission sets and permission set licenses. A permission set license extends the underlying Salesforce user license so that features covered by the purchased Financial Services product can be used, while permission sets grant the associated permissions. Users therefore need the applicable license entitlement as well as required permission assignments. For the Personal Banker group described in the question, the Standard Financial Services entitlement is the appropriate baseline rather than the Basic, Foundations, or Extension alternatives.

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.

A system-to-system API integration should operate through a dedicated integration user whose access is limited to the permissions required by that integration. Salesforce recommends creating a distinct user for each integration because this improves traceability, isolates credentials, enforces least privilege, and limits the impact if an integration account is compromised. The integration identity should also be configured for API-only access. An API-only profile prevents interactive Salesforce UI access while allowing the external system to authenticate and perform permitted API operations. Current Salesforce architecture also provides the Minimum Access - API Only Integrations profile for the Salesforce Integration user license. The required object, field, and system permissions should then be granted through appropriately scoped permission sets or permission-set groups. This provides tighter control than assigning the System Administrator profile. Options C and D violate the principle of least privilege. A System Administrator profile provides substantially more capability than a risk-control integration should require, and changing that profile to API-only would also be inappropriate because it affects users assigned to that profile. The correct security pattern is therefore a dedicated Integration User with API-only profile access, plus narrowly tailored permission assignments for the objects and API operations required by the external risk-control system.

The Financial Account Summary component depends on the relationship between the user's Locale setting and the user's Currency setting when rendering monetary values. Therefore, the user's locale must correspond appropriately with the user's configured currency for currency symbols, grouping separators, and other localized formatting to display correctly. Salesforce identifies this requirement in the documented Agentforce Financial Services availability and limitations. To show commas and currency symbols correctly on the Financial Account Summary component, the user's locale in Locale Settings and the user's currency must match. Locale controls regional presentation conventions such as numeric grouping, decimal separators, date formats, and related localization behavior. Currency determines the monetary unit represented by Financial Services values. A mismatch can therefore cause the component's visual currency formatting to appear inconsistent with the expected regional conventions. This requirement is distinct from the rules governing financial-summary rollup calculations. When Multiple Currencies and Rollup By Lookup are enabled, accurate aggregation can require the user currency and account currency to correspond to the organization's default currency. That calculation requirement should not be confused with the display-formatting condition tested here. The question specifically asks about the correct presentation of commas and symbols, making the user's locale matching the user's currency the applicable configuration requirement.