A.   

Create a validation rule that displays an error if Account revenue is below 0 or greater than 100 billion.

Summary:
The requirement is to enforce a specific data quality rule (a value between 0 and 100 billion) at the moment a user tries to save an invalid record. A validation rule is the standard and correct tool for this purpose. It uses a formula to evaluate the data and, if the formula returns "true," it blocks the save operation and displays a custom error message to the user, preventing the invalid data from being entered.

Correct Option:

A. Create a validation rule that displays an error if Account revenue is below 0 or greater than 100 billion.
A validation rule allows you to define the exact logic using a formula. The formula would be: OR( AnnualRevenue < 0, AnnualRevenue > 100000000000 ). If this condition is true, the save is prevented and the user sees an error message, ensuring data integrity in real-time.

Incorrect Option:

B. Build a scheduled report displaying Account with Account revenue that is negative or greater than 100 billion.
A report is a reactive, diagnostic tool. It can identify records that already have invalid data, but it cannot prevent users from entering the invalid data in the first place. This does not fulfill the requirement to "prevent" the update.

C. Make the Account Revenue field required on the page layout.
Making a field required only ensures it is not left blank. It does nothing to validate the specific value entered. A user could still enter -500 or 200 billion, and the record would save.

D. Enable the Account Revenue limits in setup, with 0 as minimum and 100 billion as maximum.
There is no native feature in Salesforce Setup to define minimum and maximum value limits for a standard currency field like Annual Revenue. This functionality is achieved by creating a validation rule.

Reference:
Salesforce Help: "Validation Rules" - https://help.salesforce.com/

B.   

Create a formula field to display l year from the warranty purchased.

Summary:
The requirement is to automatically calculate a warranty expiration date that is typically one year from the installation date, but can be manually extended by an administrator for customer satisfaction. A formula field is the ideal solution because it automatically calculates and displays a value (1 year from the installation date) without storing it. This allows the calculated date to be the default, while still permitting an administrator to manually override it with a longer date in a separate, standard date field if needed.

Correct Option:

B. Create a formula field to display 1 year from the warranty purchased.
A formula field, specifically a Date formula, can be configured with a formula like Installation_Date__c + 365. This would automatically display the correct 1-year expiration date on the record. Crucially, because it's a formula, it's read-only and does not prevent an administrator from using a separate, standard date field to track a manually extended warranty date for exceptional cases.

Incorrect Option:

A. Use a formula as the default value of the warranty Expiration Date field.
While this would pre-populate the field with a 1-year date, a default value is still a standard field that the installer could accidentally change in the mobile app. More importantly, it doesn't as clearly facilitate the business process of having an auto-calculated date that can be manually overridden by an admin, as the field would be editable for all users with edit access.

C. Add a validation rule to ensure the Expiration Date field is populated.
A validation rule would force the field to be filled, but it would not automatically calculate the correct 1-year value. This would place the burden on the installer to manually calculate and enter the date, which is inefficient and prone to error.

D. Include the warranty Expiration Date field on the mobile page layout.
Simply placing a field on a layout does nothing to automatically populate its value. The field would remain blank unless another method (like a default value or a formula) is used to calculate it.

Reference:
Salesforce Help: "Formula Fields" - https://help.salesforce.com/

D.   

Tab Settings

Explanation:
To make atab hidden in the All App Launcher or visible in any app, but still allow a user to view records that would normally be found under this tab, the administrator should use Tab Settings on a profile. Tab Settings control the visibility and default behavior
of tabs for each app in an org. The administrator can set a tab to Hidden, which means it will not appear in any app or in the All App Launcher, but users can still access records via other means such as search or reports. Object Permissions, App Permissions, and Org-
Wide Defaults are not related to tab visibility.

Summary:
The requirement describes a scenario where users should not have a dedicated tab for an object in their navigation, but must still be able to view the individual records if they access them via a related list, search, or a link. This behavior is controlled by the Tab Settings within a user's profile, which provide different levels of visibility and access to an object's tab.

Correct Option:

D. Tab Settings:
The Tab Settings on a profile directly control the visibility of an object's tab in the Salesforce navigation and the app launcher. The "Tab Hidden" setting achieves exactly what is described: it removes the tab from the interface but still allows users with "Read" object permissions to view individual records through other means, such as related lists or direct links.

Incorrect Option:

A. Object Permissions:
Object permissions (like "Read," "Create," "Edit," "Delete") control what actions a user can perform on the records of an object. They do not control the visibility of the tab itself in the user interface. A user can have "Read" permission but still have the tab hidden via the Tab Settings.

B. App Permissions:
This is not a standard Salesforce setting. App permissions typically refer to connected app or mobile app access policies, not the visibility of individual object tabs within the Salesforce application.

C. Org-Wide Defaults:
Org-Wide Defaults (OWD) control the baseline level of sharing access for records (Private, Public Read/Write, etc.). They determine what records a user can see based on ownership and sharing rules, but they have no control over whether the object's tab is visible in the navigation.

Reference:
Salesforce Help: "Hide Custom Object Tabs" - https://help.salesforce.com/

D.   

External ID

Summary:
When integrating with an external system, you cannot rely on Salesforce's native 18-character Record ID because the external system is unaware of it. You need a common, unique identifier that both systems understand. An External ID is a custom field in Salesforce that is designated to store this foreign key from the external system, enabling reliable matching for updates during data import operations like an "upsert."

Correct Option:

D. External ID:
An External ID field is specifically designed for this purpose. It holds the unique identifier from the external system (e.g., a product SKU or a legacy database ID). During an import using tools like Data Loader, you can perform an "Upsert" operation using this External ID as the match key. This will update existing Salesforce records that have a matching External ID and insert new ones if no match is found.

Incorrect Option:

A. Rich Text field:
A Rich Text field is for formatted text and is not a reliable identifier. It is not indexed for high-performance matching and cannot be designated as a unique key for upsert operations, making it inefficient and prone to errors for data imports.

B. Record ID:
The Salesforce Record ID is generated internally and is unknown to the external system. Since the separate system does not have this value, it cannot be provided in the import file to match and update existing records.

C. Auto-Number field:
While Auto-Number fields are unique, they are typically read-only and generated by Salesforce. The external system cannot assign these values, so it cannot provide them in the import file to correctly match records for updates.

Reference:
Salesforce Help: "What Are External IDs?" - https://help.salesforce.com/

A.   

Use a muting permission set with a permission set group to mute selected permissions.

Summary:
When a permission set group is part of an installed managed package, its components cannot be directly modified. To remove specific permissions granted by the group, you must use a Muting Permission Set. This is a special type of permission set designed explicitly to "mute" or revoke specific permissions that are being granted by a permission set group, without altering the original, immutable package components.

Correct Option:

A. Use a muting permission set with a permission set group to mute selected permissions.
A Muting Permission Set is the standard and intended tool for this scenario. The administrator can create one, associate it with the installed permission set group, and then deselect the "Delete" permission for the relevant objects. This will effectively revoke the delete access for all users assigned to that group, overriding the permission granted by the package.

Incorrect Option:

B. Create a new permission set that has Delete access deselected for the objects.
A standard permission set cannot revoke permissions; it can only grant them. Creating a new permission set that lacks delete access would have no effect on the delete access already granted by the permission set group. Permissions are cumulative, and you cannot use a "negative" permission set.

C. Create a new role that prevents Delete permissions from rolling up to the users.
Roles control record-level visibility through the sharing model (i.e., which records a user can see). They do not control object-level permissions (like Create, Read, Edit, Delete), which are governed by Profiles and Permission Sets. A role cannot revoke delete access.

D. Edit the profile for the users to remove Delete access from the objects.
This is ineffective because permissions from permission sets and permission set groups override the more restrictive settings in a user's profile. Even if the profile has delete access removed, the permission set group is explicitly granting it, so the user will retain the delete permission.

Reference:
Salesforce Help: "Mute Permissions in Permission Set Groups" - https://help.salesforce.com/

B.   

An autolaunched flow on the account page that updates all open orders shipping addresses whenever the account shipping addresses changes.

Summary:
The requirement has two key parts: 1) The action should be triggered when the Account's shipping address changes, and 2) It should provide a streamlined solution for reps, implying automation rather than a manual, multi-step process. An autolaunched flow triggered by an Account update that automatically propagates the new address to all related open orders fulfills both requirements efficiently.

Correct Option:

B. An autolaunched flow on the account page that updates all open orders shipping addresses whenever the account shipping addresses changes.
This solution is fully automated and triggered by the relevant event (updating the Account). The flow would be built to trigger when the Account's Shipping Address fields are changed, then find all open Orders related to that Account, and update their shipping addresses in bulk. This is the most streamlined approach, requiring no manual intervention from the sales reps.

Incorrect Option:

A. An autolaunched flow on the order page that updates all open orders shipping addresses whenever the account shipping addresses changes.
This is illogical. A flow on the Order object would be triggered by an update to an Order, not an Account. It would not automatically run when the Account's address changes, failing the core trigger requirement.

C. A screen flow on the order page that lets the reps choose the updated account shipping address in all open associated orders.
This is a manual, multi-step process. The rep would have to navigate to an Order, launch the flow, and make a selection for each account. This is the opposite of "streamlined" and is inefficient for updating multiple accounts.

D. A screen flow on the account page that lets the reps choose the updated account shipping address in all open associated orders.
While triggered from the correct object (Account), this still requires manual rep intervention for every single Account update. The requirement implies the update should happen automatically when the address changes, not that a rep should be prompted to run a flow and make a choice each time.

Reference:
Salesforce Help: "Flow Triggering Options" - https://help.salesforce.com/

D.   

Review the Login history

Summary:
When a user cannot log in, the most direct and effective first step is to check the Login History. This report provides a real-time log of all login attempts, including their timestamp, source IP, and—most importantly—the specific reason for any failure (e.g., "Invalid Password," "Wrong IP," "Login Hours Restriction"). This gives the administrator immediate, actionable data to diagnose the root cause.

Correct Option:

D. Review the Login history.
The Login History report is the primary diagnostic tool for login issues. It shows every attempt the user has made and will explicitly state the failure reason, such as an incorrect password, login outside of permitted hours, or an attempt from a blocked IP address. This allows the administrator to provide a targeted solution.

Incorrect Option:

A. Review the Security token.
A security token is only required for API logins (e.g., from Data Loader), not for standard UI logins via a browser. Reviewing it would not help diagnose a standard web browser login problem.

B. Review the password history.
While password issues are a common cause, an administrator cannot see a user's current or previous passwords for security reasons. The Login History will simply state "Invalid Password" if that is the issue, making a direct password history check both impossible and unnecessary.

C. Review the Password policies.
Reviewing the organization's password policy (e.g., minimum length, complexity) might provide context, but it does not identify the specific reason this user cannot log in now. The Login History provides the specific, real-time error.

Reference:
Salesforce Help: "Monitor Login Activity" - https://help.salesforce.com/

B.   

The field is universally required to save a record on that object.

D.   

The field is optional when saving records via web-to-lead and web-to-case

Summary:
Marking a field as "Required" in Object Manager applies a system-level validation that the field must contain a value for the record to be saved. This rule is enforced universally across most of the Salesforce platform, but there are specific, well-known exceptions for certain web-based data entry points that operate outside of standard UI and API validation rules.

Correct Option:

B. The field is universally required to save a record on that object.
Setting a field to required in Object Manager makes it mandatory for almost all methods of saving a record. This includes the standard UI, Lightning Experience, the mobile app, and most API-based saves. It is the highest level of data enforcement.

D. The field is optional when saving records via web-to-lead and web-to-case.
This is a critical exception. Web-to-Lead and Web-to-Case forms are designed for external users and bypass standard required field rules to prevent submission failures. If a required field is not included on the public form, the submission will succeed and the field will be left blank.

Incorrect Option:

A. The field is not required to save records via the API on that object.
This is incorrect. A field required in Object Manager is enforced for most API operations. For example, if you try to insert a record via the API without a value for a required field, the operation will fail.

C. The field is added to every page layout on that object.
This is false. Making a field required in Object Manager does not automatically add it to any page layout. An administrator must still manually add the required field to the relevant page layouts; otherwise, users will be unable to save the record because the required field is missing from the UI.

Reference:
Salesforce Help: "Make Fields Required" - https://help.salesforce.com/

Salesforce Help: "Considerations for Web-to-Lead" - https://help.salesforce.com/

B.   

Auto-response rules, Queues, Macros

D.   

Create a separate PriceBook for reseller partners.

Explanation: A PriceBook is a feature that allows administrators to define different prices for the same products based on different criteria such as customer segment, region, channel, etc. For example, a PriceBook can provide reseller partners with discounted prices on the products they purchase compared to regular customers. A PriceBook consists of one or more PriceBook entries that specify the product ID, pricebook ID, list price, currency, and active status for each product-pricebook combination.

A.   

Field Update

D.   

Email Alert

Explanation: Field update and email alert are two types of automated actions that can be added as part of the approval process. Field update allows you to change the value of a field on a record when it is submitted, approved, rejected, or recalled. Email alert allows you to send an email to one or more recipients when a record is submitted, approved, rejected, or recalled.

C.   

Create three sales processes. Create three record types and three page layouts.