Free ADM-201 Practice Test

The Geolocation custom field type is the appropriate choice for capturing coordinates in Salesforce. This compound field stores location data using latitude and longitude values, which can be represented in decimal degrees. It is specifically designed for use cases like tracking assets or shipments, as it enables distance calculations and integration with mapping functionalities. This directly fulfills the requirement for Cloud Kicks to capture coordinates for its product shipments.

B. Geofence: Geofence is a concept or feature related to virtual boundaries, not a standard Salesforce field type for data storage.
C. Custom address: The standard Address field type stores street, city, and state information but does not natively store raw latitude and longitude coordinates.
D. External lookup: This field type is used to create a relationship with an object in an external system and is not used for storing geographic data.

1. Salesforce Help

Custom Field Types: "Geolocation: Allows users to define locations with latitude and longitude. Distance calculations can be performed in SOQL queries

Apex

and formulas." (Salesforce Documentation

Custom Field Types

Geolocation section).

2. Salesforce Object Reference for Salesforce and Lightning Platform

Field Types: "Geolocation: A compound field that consists of a location’s latitude and longitude. You can add this field type to custom objects and some standard objects." (Salesforce Documentation

Field Types

Geolocation).

3. Salesforce Developer Documentation

Geolocation Fields: "The Geolocation custom field allows you to identify locations by their latitude and longitude and to calculate the distance between locations." (Salesforce Developer Guide

Compound Fields

Geolocation Fields section).

The most effective and direct solution is to use a combination of a predefined case team and a case assignment rule. An administrator can first create a predefined case team that includes the two lead engineers and grants them read/write access. Then, a case assignment rule can be configured to trigger when a new case is created with criteria matching the new product. A key action of this assignment rule is to automatically add the predefined case team to the case, thus granting the required access to the engineers in an automated fashion.

A. Create a queue and a criteria-based sharing rule. A queue is for record ownership, not for granting access to specific users who don't own the record. While a sharing rule could grant access, Case Teams are the more appropriate feature for collaborative case resolution.
C. Create a user-based sharing rule and an ad-hoc case team. Ad-hoc case teams are added manually to individual cases, which does not meet the requirement for an automated solution. User-based sharing rules are based on record ownership, not the case's criteria.
D. Create an auto-response rule and a public group. Auto-response rules are used to send automated email responses to customers who submit a case. They do not control internal user access to records.

1. Salesforce Help Documentation, "Set Up Case Teams": "You can set up case assignment rules to automatically add a predefined team to a case that meets specific criteria, such as the origin or record type of the case." This directly supports using an assignment rule to add a predefined team.

2. Salesforce Help Documentation, "Set Up Assignment Rules": Under the "Create Case Assignment Rules" section, the documentation lists available actions for rule entries, which includes the ability to "Add a predefined case team to a case." This confirms the mechanism for automation.

3. Trailhead by Salesforce, "Service Cloud for Lightning Experience" module, "Automate Case Management" unit: This unit explains that "Case assignment rules automate your organization’s support processes... You can also configure assignment rules to add a predefined case team to cases that match the criteria." This reinforces that the combination in option B is the standard, intended functionality.

Standard fields are included with Salesforce and have certain customization restrictions. However, administrators can modify several key aspects to align with business processes. They can customize the available values in standard picklist fields (e.g., Account Industry, Opportunity Stage) by adding, editing, or deactivating options. Administrators can also define or edit the field-level help text, which appears as an info icon next to the field, to provide guidance for users. Furthermore, field history tracking can be enabled for most standard fields to log changes, which is crucial for auditing and data governance.

D. Decimal Places: The data type and its properties, such as length or the number of decimal places for standard number or currency fields, are fixed and cannot be modified by an administrator.
E. Field name: The API name (the unique name used by the system and integrations) of a standard field cannot be changed. While the display label can be renamed, the fundamental "Field Name" is immutable.

1. Salesforce Help

Standard Fields: "For most standard fields

you can edit the field label and help text." This directly supports option B (Help Text) and clarifies the distinction for option E (Field name vs. Field label).

2. Salesforce Help

Add or Edit Picklist Values: "You can add or edit values in a picklist field from the fields area of an object. If the field is a standard picklist field... you can customize the available values." This directly supports option A.

3. Salesforce Help

Track Field History for Standard Objects: "From the management settings for an object

you can select certain standard and custom fields to track... Salesforce starts tracking the history of changes to the fields you select." This directly supports option C.

4. Salesforce Help

Notes on Standard Fields: This documentation implicitly supports the incorrectness of D and E by outlining the unchangeable nature of standard field properties. It states

"You can’t change the data type of a standard field

" which includes properties like decimal places and the underlying field name.

The Get Records element in Flow Builder is specifically designed to query the Salesforce database. It allows an administrator to define filter conditions to find one or more records that match the specified criteria. The element then automatically stores the field values from the found record(s) into a record variable or a record collection variable. These variables can then be referenced and used by other elements later in the flow, fulfilling the exact requirements of the scenario.

A. Assignment: This element is used to set or change the values of variables that are already in the flow; it does not retrieve record data from the database.
C. Create Records: This element is used to insert new records into the Salesforce database, not to search for and read existing ones.
D. Update Records: This element modifies existing records. While it finds records to update, its primary purpose is to change data, not retrieve it for later use.

1. Salesforce Help Documentation: "Flow Element: Get Records". This document states, "Find Salesforce records that meet filter conditions, and store values from the records in variables." This directly confirms the function described in the question.

2. Trailhead Module: "Flow Builder". In the "Flow Building Blocks" unit, the Data elements section describes Get Records as the element used to "Find Salesforce records."

3. Salesforce Help Documentation: "Which Flow Data Element Is Right for Me?". This guide explicitly differentiates the data elements, noting that Get Records is used when "You need to get values from a Salesforce record that started the flow or from another Salesforce record."

The requirement is for a fiscal year that follows the standard 12-month Gregorian calendar structure but begins in a month other than January. Salesforce's "Standard Fiscal Year" setting is specifically designed for this purpose. It allows an administrator to define the start month of the fiscal year, which then automatically structures the year into 12 standard months. Using a "Custom Fiscal Year" is unnecessary and incorrect, as those are reserved for complex structures that do not follow the Gregorian calendar, such as 13-period or 4-4-5 quarter systems.

A. Set the Fiscal Year to Custom and the starting month as February. Custom Fiscal Years are for non-standard calendar structures (e.g., 13-week quarters), which is overly complex and not required for a standard 12-month period.
B. Set the Fiscal Year to Custom and the duration to 4 quarters. This is incorrect because a Custom Fiscal Year is not needed, and its structure is defined by templates, not a simple duration setting.
D. Set the Fiscal Year to Standard and the duration to 12 months. While a Standard Fiscal Year has 12 months, the key setting to change is the starting month to meet the requirement, not the duration, which is fixed.

1. Salesforce Help Documentation, "Define Your Fiscal Year": "If your fiscal year follows the Gregorian calendar but starts on the first day of a month other than January, you can use a standard fiscal year. Select a starting month for your fiscal year." This directly supports setting the type to Standard and choosing the starting month.

2. Salesforce Help Documentation, "Considerations for Customizing Fiscal Years": This document clarifies when to use Custom Fiscal Years, stating they are for structures that "don’t follow the Gregorian calendar," such as "13-week fiscal quarters." This confirms that the scenario in the question does not require a Custom Fiscal Year.

3. Trailhead, Salesforce Administrator Trail, "Company-Wide Org Settings" Module, "Update Your Company's Fiscal Year" Unit: This unit demonstrates the configuration process, showing that for a Standard Fiscal Year, the primary option to configure is the "Fiscal Year Start Month".

To provide daily insights and boost productivity for a sales team, the administrator should use components designed to surface relevant, actionable sales information on the homepage.
1. Assistant (C): This component proactively displays personalized updates, such as new leads and opportunities requiring attention, helping users prioritize their day.
2. Key Deals (D): This component highlights top opportunities, ensuring sales reps focus on their most critical deals.
3. Performance Chart (E): This component visually tracks a user's sales performance against their goals (quota), providing immediate insight into their progress and motivating them. These three components are standard, sales-specific, and designed to provide the requested daily insights directly on the Lightning homepage.

A. Activities: While the 'Today's Tasks' and 'Today's Events' components are useful for productivity, they are more of a to-do list than a source of sales-specific insights like the Assistant or Performance Chart.
B. Path: Path is a component used on a record page (e.g., an Opportunity or Lead) to guide a user through the stages of a business process. It cannot be placed on the homepage.

1. Salesforce Help Documentation - Standard Lightning Page Components:

Assistant: "The Assistant shows users important things they need to address

including new leads and opportunities that need attention." (Found under "Standard Component: Assistant").

Key Deals: "Help your sales reps keep their most important opportunities top of mind with the Key Deals component." (Found under "Standard Component: Key Deals").

Performance: "The Performance component shows sales performance against a goal for a specific period... Add it to a home page..." (Found under "Standard Component: Performance").

Path: "Use the Path component on object record pages..." This confirms Path is for record pages

not the homepage. (Found under "Standard Component: Path").

Multi-Factor Authentication (MFA) is a core security feature that significantly strengthens access control. It requires users to provide two or more pieces of evidence (or "factors") to prove their identity before being granted access to the Salesforce org. This typically combines something the user knows (password) with something they have (a code from an authenticator app or a physical security key). By implementing MFA, an organization ensures that even if a user's password is compromised, an unauthorized individual cannot log in without the second verification factor, directly preventing unauthorized access.

A. Disabling TLS (Transport Layer Security) requirements would remove encryption for data in transit, severely weakening security and increasing the risk of unauthorized access.
C. Customizing organization-wide defaults controls the baseline visibility of records after a user has successfully logged in; it does not prevent the initial unauthorized login.
D. Enabling caching and autocomplete on the login page is a security risk, as it can expose credentials on shared or public computers, making unauthorized access easier. ---

1. Salesforce Help & Training, "Multi-Factor Authentication": This document outlines the purpose of MFA. It states, "Multi-factor authentication (MFA) is one of the easiest, most effective tools for enhancing login security and safeguarding your business and your data against security threats like phishing attacks, credential stuffing, and account takeovers." (See the "What Is Multi-Factor Authentication?" section).

2. Salesforce Help & Training, "How Multi-Factor Authentication Works to Secure Account Access": This resource details the mechanism of MFA. It explains that MFA "adds another layer of security to your login process by requiring users to enter two or more pieces of evidence... to prove they are who they say they are." This directly supports its role in preventing unauthorized access.

3. Salesforce Help & Training, "Configure Session Security Settings": This documentation covers session settings, including TLS. It recommends requiring TLS 1.2 or higher for HTTPS connections to provide a "higher standard of security." Disabling this requirement would be contrary to best practices for preventing unauthorized access. (See the "Session Settings" section).

4. Salesforce Help & Training, "Organization-Wide Sharing Defaults": This official guide defines OWDs. It specifies, "Organization-wide sharing settings specify the default level of access that users have to each other’s records." This confirms that OWDs manage post-authentication data access, not the authentication process itself. (See the "Organization-Wide Sharing Defaults Overview" section).

A user's baseline permissions are determined by their assigned profile. To meet the requirement of allowing Read, Create, and Edit access while explicitly denying Delete access, the most appropriate and secure method is to create a custom profile. This profile can be configured with the precise object-level permissions needed (Read, Create, Edit checked; Delete unchecked). Assigning this custom profile to the user ensures they have exactly the permissions required for their role, adhering to the principle of least privilege.

A. The standard System Administrator profile grants "Modify All Data," which includes the ability to delete all records, directly violating the core requirement of restricting deletion.
B. The role hierarchy and "View All" access control record-level visibility, not the fundamental object-level permissions (like Create, Edit, or Delete) that a user can perform.
D. Permission sets are used to grant additional permissions to users, not to restrict them. A permission set cannot remove the Delete permission if it is already granted by the user's base profile.

1. Salesforce Help - Control Access to Objects: "Object permissions determine the kinds of records (such as contacts or accounts) users can view, create, edit, or delete. You set object permissions in profiles and permission sets." This establishes that profiles are the primary tool for setting these baseline permissions.

2. Salesforce Help - Profiles: "Profiles define how users access objects and data, and what they can do within the application... For example, you can use profiles to grant a user Create and Edit permissions on an object but not Delete permission." (Found under User Management > Profiles).

3. Salesforce Help - Permission Sets: "Permission sets extend users’ functional access without changing their profiles... Use a permission set to grant additional permissions and access settings to a user." This highlights that permission sets are for additive permissions, not for creating baseline access or restrictions.

An Approval Process (C) is the standard Salesforce tool for automating a structured review sequence, which directly addresses the requirement for review by managers and directors. It allows for defining entry criteria, approval steps, and assigned approvers. To send the approved expense report data "to the external HR system," an Outbound Message (B) is the appropriate declarative tool. Outbound Messages send specified record data via a SOAP API message to a designated external endpoint. This action can be configured to trigger automatically upon the final approval step within the Approval Process, thus completing the required workflow.

A. Quick Action: A Quick Action is primarily for user interface efficiency, such as creating records or logging calls. It does not manage a multi-step review or natively integrate with external systems.
D. Email Alert Action: An Email Alert sends a notification to specified recipients. It is not a robust or secure method for system-to-system data integration as required for an HR system.

1. Salesforce Help

Approval Process Overview: "An approval process automates how records are approved in Salesforce. An approval process specifies each step of approval

including from whom to request approval and what to do at each point of the process."

2. Salesforce Help

Approval Actions: "Final approval actions...occur when all required approvals are given for a record...Possible actions include...Outbound Message." This document explicitly links the two correct answers.

3. Salesforce Help

Outbound Messaging: "Outbound messaging allows you to specify that changes to fields within Salesforce can trigger new messages

with field values as part of the message

to be sent to designated external servers." This confirms its use for sending data to external systems.

To make a Lightning record page dynamic and tailored to a user's role, an administrator should use component visibility filters. This feature, available in the Lightning App Builder, allows components to be displayed or hidden based on specific criteria. These criteria can be defined using the user's role, profile, or permissions, as well as field values on the record itself. This directly addresses the requirement to show users information that is most relevant and useful for their specific job function, thereby making the page dynamic and easier to use by reducing clutter.

B. Remove fields from the record details component: This is a static change applied via the page layout and affects all users assigned to it, failing to make the page dynamic for different roles.
C. Delete the extra component from the page: This simplifies the page for all users but does not provide a dynamic, role-specific experience as requested.
D. Include more tab components with filters: Adding more tabs can increase complexity. While tabs can contain filtered components, the core feature enabling the dynamic behavior is the component visibility filter itself, making option A more precise.

1. Salesforce Help Documentation: Dynamic Lightning Pages. This document states

"You can make your Lightning record pages more dynamic by configuring component visibility filters on them... For example

you can create a rule for a component to appear for users in a certain role..." This directly supports using component visibility filters to tailor pages by user role.

2. Trailhead Module: Lightning App Builder

Unit: Create Dynamic Pages with Component Visibility Rules. This unit details the process: "With component visibility rules

you can make your Lightning record pages more dynamic by choosing when a component appears... You can add visibility rule filters to a component based on the user’s profile

role

or permissions."

3. Salesforce Developer Documentation: Lightning App Builder Guide

Section: Configure Component Visibility. This guide explains that visibility filters can be based on "User fields

such as Profile or Role

" which is the exact requirement of the scenario.