PLAT-ADMN-202 Practice Questions

This validation rule is designed to fire only when a new Lead record is created (ISNEW()) and its owner is a Queue. The function ISBLANK(Owner:User.Id) is a standard method to determine if the polymorphic Owner field points to a Queue. If the owner were a User, Owner:User.Id would contain a value and ISBLANK would be false. By combining these conditions with AND, the rule prevents a new Lead from being assigned directly to a queue. This enforces a business process where a Lead must first be assigned to a specific user, who can then be added to a campaign, before it is potentially reassigned to a qualification queue.

A. The OwnerId field on a Lead is a required system field and can never be blank. Therefore, this validation rule would never be triggered.

B. This rule would fire for all existing records (NOT(ISNEW()) is true for them), preventing users from making any updates, which is incorrect functionality.

D. This rule, NOT(ISBLANK(Lead.Owner:Queue.Id)), evaluates to true whenever the owner is a queue. It would prevent any Lead, new or existing, from being queue-owned, which contradicts the stated business process.

---

1. Trailhead, Salesforce Platform Basics, "Validation Rules" Module: This module explains that validation rules verify that the data a user enters in a record meets the standards you specify before the user can save the record. The formula must evaluate to "True" for the error message to display. This supports the basic structure of the chosen answer.

2. Salesforce Help, Formula Operators and Functions, "ISNEW()": "Checks if the formula is running during the creation of a new record and returns TRUE if it is. If an existing record is being updated, this function returns FALSE." This confirms the function of the ISNEW() part of the formula.

3. Salesforce Help, Formula Operators and Functions, "ISBLANK()": "Determines if an expression has a value and returns TRUE if it does not." When used with a polymorphic relationship field like Owner, ISBLANK(Owner:User.Id) correctly returns TRUE if the Owner is a Queue, as the specific path to a User record is blank.

4. Salesforce Help, Formula Operators and Functions, "CASE()": The documentation for the CASE() function provides an official example of accessing fields on the polymorphic Owner relationship: CASE(Owner:Queue.Type, 'Regular', 1, 'Territory', 2, 'Group', 3, 0). This officially documents the Owner:[ObjectType].[FieldName] syntax pattern used in the question's options.

To display the value of a parent object's picklist field in a child object's formula field, the picklist value must be converted to a text data type. The TEXT() function is specifically designed for this purpose; it returns the API name of a picklist value as a text string. Using TEXT(Galaxyr.Typec) correctly retrieves the value from the parent Galaxy record's Type field and allows it to be displayed on the child Star record, resolving the "Picklist values are only supported..." error.

A. ISPICKVAL(Galaxyr.Typec) is syntactically incomplete. This function checks if a picklist has a specific value and returns a boolean (true/false), not the text value itself.

B. VALUE(Galaxyr.Typec) converts a text string that represents a number into a number data type. It is not used for retrieving the text label of a picklist.

D. FIND(Galaxyr.Typec) is syntactically incomplete. This function finds the position of a string within another string and is not used for displaying a field's value.

---

1. Salesforce Help Documentation, "Formula Operators and Functions T–Z":

Section: TEXT(value)

Content: "Converts a percent, number, date, date/time, or currency type field into text. Also, converts a picklist value to a text value with the API name of the value, not the label." This directly confirms that TEXT() is the correct function for converting a picklist value to text for use in formulas.

2. Salesforce Help Documentation, "Tips for Working with Picklist and Multi-Select Picklist Formula Fields":

Section: "Using Picklists in Formulas"

Content: "To return the API name of a picklist value in a formula, use TEXT(). For example, TEXT(Status) returns the API name for the Status picklist, such as 'New'." This provides a clear example and reinforces the correct usage.

3. Salesforce Help Documentation, "Formula Field Data Types":

Section: "Text"

Content: This section explains the text data type in formulas. The error message "Picklist values are only supported in certain functions" arises because a picklist is not a standard text type. The TEXT() function is the bridge to convert it to a compatible type for display.

:

Salesforce provides multiple ways for users to access or launch a Flow. A Quick Action can be configured on an object's page layout to launch a screen flow, providing a direct, user-initiated way to start an automated process. Additionally, Apex can be used to programmatically launch a flow using the Flow.Interview class. This allows developers to embed flow execution within more complex business logic, such as from a custom Lightning Web Component controller or a trigger, which is then exposed to the user through a custom UI element.

B. Approval Process: An approval process cannot directly launch a flow. Its standard automated actions are limited to creating tasks, sending email alerts, updating fields, and sending outbound messages.

C. Flow Launcher: "Flow Launcher" is not a standard, officially named Salesforce feature for flow distribution. While flows can be launched from various UI elements like the "Flow" Lightning component or custom buttons, "Flow Launcher" is an ambiguous and imprecise term.

1. Salesforce Help - Distribute Flows: This official documentation outlines the various methods to make a flow available to users. It explicitly lists "Quick Actions" and "Apex" as valid distribution methods.

Reference: Salesforce Help > Docs > Salesforce Flow > Distribute Flows. The page details, "You can distribute flows in a few ways, depending on who the flow is for... For example, add a flow to a Lightning page, Experience Cloud site, or quick action." It also states, "A developer can invoke a flow from Apex."

2. Salesforce Help - Create a Flow Quick Action for a Specific Object: This document provides a step-by-step guide on how to configure a Quick Action to launch a flow.

Reference: Salesforce Help > Docs > Salesforce Flow > Distribute Flows > Launch a Flow from a Quick Action.

3. Apex Developer Guide - Flow.Interview Class: This guide details how to start, resume, and manage flow interviews using Apex code.

Reference: Apex Developer Guide > Apex Reference > System Classes > Flow Class. The documentation states, "The Flow.Interview class contains methods for executing a flow interview."

4. Salesforce Help - Approval Actions: This document lists the available actions within an approval process, confirming the absence of a "Launch Flow" action.

Reference: Salesforce Help > Docs > Process Automation > Approvals > Set Up an Approval Process > Approval Actions. The page lists the four available action types: Task, Email Alert, Field Update, and Outbound Message.

Adding a Path component (C) provides a visual guide for the sales process directly on the Opportunity record. It highlights key fields that need to be completed at each stage and offers "Guidance for Success," such as best practices or links to relevant information. This directly improves efficiency by guiding users and enhances collaboration by standardizing the process.

Marking stage-dependent fields as required (A), typically implemented using validation rules, ensures data integrity and completeness throughout the sales cycle. This improves efficiency by preventing users from advancing an Opportunity without critical information, reducing the need for future data cleanup and follow-up.

B: Using Tabs is a general layout organization tool. While it can declutter a page, Path is a more specific and impactful component for guiding a business process like an Opportunity sales cycle.

D: Requiring manager approval at each stage would introduce significant delays and bottlenecks, directly contradicting the goal of improving efficiency in the sales process.

1. Path Component (Answer C):

Salesforce Help, Guide Users with Path. "At each step of a path, you can highlight key fields and include guidance for success... Guidance can include tips, policy reminders, links, and even video." This directly supports the efficiency and collaboration requirements.

2. Stage-Dependent Required Fields (Answer A):

Salesforce Help, Validation Rule Examples. The documentation provides examples of validation rules, such as ISPICKVAL(StageName, "Closed Won") && ISBLANK(DeliveryInstallationStatusc), which makes a field required only when an Opportunity reaches a specific stage. This enforces data quality and process compliance, which are key to efficiency.

3. Tabs Component (Incorrect Option B):

Salesforce Help, Lightning App Builder Standard Components. The Tabs component is described as a way to "keep your page organized" by grouping components into tabs. This is a layout feature, not a process guidance tool.

4. Approval Process (Incorrect Option D):

Salesforce Help, Considerations for Creating an Approval Process. Approval processes are designed to "specify the steps necessary for a record to be approved and who must approve it at each step." This is a control mechanism that typically adds time to a process, rather than improving its efficiency.

A custom action, specifically an "Update a Record" quick action, is the designated tool for this requirement. Administrators can create an object-specific action that allows users to modify specific fields, such as 'Status' and a custom 'Due Date'. This action can then be added to the object's page layout. When accessed from the record's feed or the action bar in the Salesforce Mobile App, it presents a compact, focused interface for users to quickly make their edits without navigating to the full record edit page. This directly addresses the user's need for a quick way to edit specific fields from the feed.

B. Custom button: Custom buttons are generally used for linking to URLs, Visualforce pages, or executing JavaScript (in Classic), not for providing a streamlined field-editing interface in the mobile feed.

C. Custom quick access link: This is not a standard Salesforce feature. "Custom Links" exist on the Home Page or in list views but are not designed for record-specific editing from the feed.

D. Custom URL formula Field: A formula field generates a clickable link on the record detail page. It cannot create an interface to edit other fields on the same record directly from the feed.

1. Salesforce Help - Quick Actions: "Quick actions let users do more in Salesforce and in the Salesforce mobile app. With custom quick actions, you can make your users’ navigation and workflow as smooth as possible by giving them convenient access to information that’s most important... For example, you can let users create or update records..." This source confirms that Quick Actions are the intended feature for updating records efficiently.

2. Salesforce Help - Create Object-Specific Quick Actions: "Create object-specific actions to give users the ability to create or update records... in the context of a particular object... For example, add an action to the Account object that creates a contact. If a user creates a contact from the detail page for the Acme account, that new contact is automatically associated with Acme." This document details the creation process for actions like the one required.

3. Salesforce Help - Action Layouts: "For create a record, log a call, and custom actions, the action layout determines the fields that are displayed to users. For update a record actions, the action layout also lets you specify which fields can be edited." This confirms that an "Update a Record" action layout can be customized to show only the 'Status' and 'Due Date' fields.

4. Salesforce Help - Actions in the Salesforce Mobile App: "Actions appear in the action bar, its action menu, and as list-item actions. They can also appear on a record’s related information page... The actions that are available depend on the page the user is viewing." This source verifies that custom actions are a primary component of the mobile user interface.

The requirements are to track changes to the Opportunity Close Date on the record and to automatically notify Sales Managers.

1. Feed Tracking (A): Enabling Feed Tracking on the Opportunity object for the Close Date field will automatically create a Chatter post on the record's feed whenever the date is changed. If Sales Managers follow the Opportunity records, they will receive a notification about this post, fulfilling both the tracking and notification requirements.

2. Record-Triggered Flow (C): A record-triggered flow can be configured to execute when an Opportunity's Close Date is changed. This flow can use the "Post to Chatter" action to create a customized post on the record's feed, potentially @mentioning the Sales Manager or a specific group for a direct notification. This also satisfies both requirements.

B. Create an Opportunity outbound message: An outbound message sends data to an external system. It does not create internal notifications or track changes on the Salesforce record itself.

D. Activate Historical Trending for Opportunities: Historical Trending is used for reporting and analyzing data changes over time. It does not provide real-time notifications or track changes in a user-visible feed on the record.

1. Feed Tracking:

Salesforce Help, "Feed Tracking". This document states, "When you enable feed tracking for an object, users see posts about changes to records of that object type in their What I Follow feed... For record field changes, the feed post shows the user who made the change and the old and new values."

2. Record-Triggered Flow with Chatter Post Action:

Salesforce Help, "Flow Core Action: Post to Chatter". This document details the "Post to Chatter" action, explaining its capability to "post a message to a feed, group, or user," which can be triggered by a record change in a flow. The Target Name or ID can be set to the record's ID to post directly to its feed.

3. Historical Trending:

Salesforce Help, "Track Field History with Historical Trend Reporting". This resource clarifies the feature's purpose: "Historical trend reporting uses a special custom report type to track changes... so you can analyze changes over time." This confirms it is a reporting tool, not a notification mechanism.

4. Outbound Messages:

Salesforce Help, "Configure an Outbound Message Action". The documentation defines this action: "An outbound message sends information to a designated endpoint, such as an external service." This confirms its use for integration, not internal user alerts.

The Account Interest object is a junction object, which by definition has two master-detail relationships—one to Account and one to Interest. In a master-detail relationship, a detail record (the junction record) inherits its security and sharing settings from its master records. For a user to view a junction object record, they must have at least read access to both associated master records.

In this scenario, the user lacks read access to the Interest object. Because access to one of the master records is denied, the user is consequently unable to view the Interest records and also the Account Interest junction records that link to them.

A. The user cannot have read-only access to Interest records because their profile or permission set explicitly denies read access to the entire object.

B. A user's access to a primary record, like an Account, is not revoked simply because they cannot see records in a related list.

D. This describes field-level security, not object-level security. The user is denied access to the entire Account Interest record, not just specific fields on it.

1. Salesforce Help Documentation, "Master-Detail Relationship": This document outlines the characteristics of master-detail relationships, stating, "The detail and subdetail records inherit the sharing and security settings of the master record." This principle is fundamental to understanding why access to the master (Interest) controls access to the detail (Account Interest).

2. Salesforce Help Documentation, "Control Access to Objects": This guide explains object-level security. It specifies that "Object permissions specify the base-level access users have to create, read, edit, and delete records for each object." Lacking the "Read" permission prevents a user from viewing any records of that object type.

3. Salesforce Help Documentation, "Object Relationships Overview": In the section on Many-to-Many relationships, it clarifies that junction objects are created using two master-detail relationships. The security behavior of both master-detail relationships applies, meaning access to the junction record is dependent on access to both master records.

The Component Visibility Filter feature in the Lightning App Builder allows administrators to define conditional rules for when a specific component is displayed on a Lightning record page. One of the available filter criteria is the user's device form factor. By setting a filter on the component to Form Factor = Phone, the app builder can ensure the component is visible only to users accessing the record page through the Salesforce mobile app, fulfilling the requirement.

A. Chatter feed: The Chatter feed is a standard component for collaboration and communication on records; it does not control the visibility of other components on the page.

B. Highlights panel: The Highlights panel is a component that displays key fields at the top of a record page. It does not have functionality to control the visibility of other components.

D. Related list quick links: This component provides navigational links to a record's related lists. It is a content component, not a feature for controlling the visibility of other page elements.

1. Salesforce Help, "Dynamic Lightning Pages": This document states, "Make your Lightning pages dynamic by configuring component visibility filters... You can also set visibility rules based on the device the page is viewed on." It provides an example of setting a filter based on "Form Factor," with options for "Desktop" and "Phone."

2. Salesforce Help, "Lightning Page Component Visibility": This guide details the process: "You can make a component on a record page appear only when it meets the criteria you specify... You can also control component visibility by device." This directly supports using visibility filters for device-specific component display.

In a private sharing model, the role hierarchy is the standard mechanism for granting managers or supervisors vertical access to records owned by their subordinates. Placing the Service Coordinator (SC) in a role above the technicians ensures the SC can view, edit, and report on all records owned by those technicians, including work orders and other related records. This solution directly addresses the need to modify data and access related records owned by the technicians without granting excessive, org-wide permissions, thus adhering to the principle of least privilege.

A. Give the SC a permission set with the Modify All Data system permission.

This permission grants access to all data in the entire organization, which is excessive and violates the principle of least privilege. The requirement is limited to a specific region's technicians.

C. Create a workflow rule that updates records owned by technicians in that region with the SC.

Workflow rules automate processes like field updates or sending emails; they are not a mechanism for granting record access or managing visibility in the sharing model.

D. Change work order access on the SC's profile to 'Modify All'.

This grants access to all work order records, not just those of the specific technicians. It also fails to provide access to "any other related records owned by the technician."

1. Salesforce Help, Control Access Using Hierarchies: "The role hierarchy enables users above another user in the hierarchy to have the same level of access to records owned by or shared with the users below them. ... For most objects, you can disable this access for a specific object in your organization’s sharing settings." This confirms that placing the SC above the technicians grants the required access.

2. Salesforce Security Guide, Page 11, "Access Control": "The role hierarchy gives managers access to their direct reports’ data. For example, a sales vice president can see the records of all the sales managers, and the sales managers can see the records of all their sales reps." This document explicitly states the primary function of the role hierarchy aligns with the scenario.

3. Salesforce Help, Object Permissions: "Modify All: View, edit, delete, transfer, and approve all records of a specific object type, regardless of sharing settings." This explains why option D is incorrect, as it grants access to all work orders, not just the subordinates', and doesn't cover other related objects.

4. Salesforce Help, System Permissions: "'Modify All Data' permission: Create, edit, and delete all organization data, regardless of sharing settings." This highlights why option A is overly permissive for the stated requirement.