Advanced-Administrator Practice Exam Questions with Answers Salesforce Certified Platform Administrators II (Plat-Admn-301) Certification

Contacts to Multiple Accounts is a feature that allows administrators to relate a contact to multiple accounts without creating duplicate contacts for each account. This feature is useful for scenarios where a contact has business relationships with more than one account, such as consultants, brokers, or loan advisors. By setting up Contacts to Multiple Accounts for loan advisors at DreamHouse Realty, administrators can track which loan advisors work with which customers and which accounts without creating duplicate contacts for each account. References: https://help.salesforce.com/s/articleView?id=sf.contacts_multiple_accounts_overview.htm &type=5

Data Classification is the feature that the administrator should use to flag where sensitive information is stored in Salesforce. Data Classification is a feature that allows administrators to flag where sensitive information is stored in Salesforce by assigning sensitivity and classification levels to fields. Data Classification can help administrators comply with data privacy regulations and best practices by identifying and managing sensitive data in their orgs.

A price book is a list of products and their prices that can be added to an opportunity. A product can have different prices for different markets or segments, and these prices are stored in different price books. In this case, the administrator should create a new price book for the new retail pricing and add the products that are sold to retail locations for resale. This way, the users can select the appropriate price book and products for their opportunities based on the type of customer they are selling to. References: https://help.salesforce.com/s/articleView?id=sf.products_pricebooks.htm &type=5 https://help.salesforce.com/s/articleView?id=sf.products_define.htm &type=5

Use Field-Level Security to control data access is how the administrator should deliver this solution. Field-Level Security is a way to restrict users’ access to view or edit specific fields on an object based on their profile or permission set. Field-Level Security can be used to make fields visible or hidden, and editable or read-only for different users. By using Field-Level Security, the administrator can ensure that only Marketing users can see all data on the Membership Details object, while Support users can only see the Support preference fields.

The change can be made through the desktop site by using the Edit All button on the related list of products on the opportunity page. This button allows you to edit multiple products at once and change their price book entries. You cannot use this button on the mobile app, as it is not supported. You also cannot change the price book on the opportunity once it has products added to it, unless you remove all the products first. References: https://help.salesforce.com/s/articleView?id=sf.opportunity_products_edit.htm &type=5 https://help.salesforce.com/s/articleView?id=sf.opportunity_products_change_pricebook.htm &type=5

An object-specific quick action is a type of action that allows users to do something in the context of a specific object, such as creating or updating a record, logging a call, sending an email, or launching a custom action. In this case, the administrator can create an object-specific quick action on the opportunity object that pre-populates certain fields with predefined values and allows users to quickly close an opportunity from the Salesforce mobile app. References: https://help.salesforce.com/s/articleView?id=sf.actions_overview.htm &type=5 https://help.salesforce.com/s/articleView?id=sf.actions_objectspecific_actions.htm &type=5

To use outbound change sets, a user needs to have the Create and Upload Change Sets permission on their profile or permission set. This permission allows users to create change sets in a sandbox or Developer Edition organization and upload them to another organization. References: https://help.salesforce.com/s/articleView?id=sf.changesets_create_upload_perm.htm &type=5

The Delete permission is missing on the user for Accounts is what is preventing the user from completing the merge. Merging accounts is a way to combine up to three duplicate accounts into one master record and update the related records accordingly. Merging accounts requires the Delete permission on accounts because merging accounts involves deleting the duplicate records and keeping only the master record.

An entitlement process is a feature that allows you to define and enforce service-level agreements (SLAs) for your customers based on certain criteria and timelines. An entitlement process consists of milestones and actions that represent required steps and time limits for resolving customer issues. You can use entitlement processes to track if your support team is meeting your SLAs and provide consistent service quality to your customers. In this case, you can set up and configure entitlement processes for different types of cases and assign them to accounts or contacts based on their service contracts or warranties. References: https://help.salesforce.com/s/articleView?id=sf.entitlements_overview.htm &type=5 https://help.salesforce.com/s/articleView?id=sf.entitlements_process.htm &type=5

Flows deployed with change sets are inactive by default and need to be manually activated in the destination org before they can run. Deploying or redeploying a flow with change sets creates a new version of the flow in the destination org, which preserves the previous versions and allows for rollback if needed. All flow dependencies, such as custom fields, objects, or variables, are automatically added to the change set when a flow is added

To access a junction object record, a user needs to have at least read permission on one of its master records and on the junction object itself. If the user does not have access to either master record, they cannot access the junction object record. If the user has access to both master records, they can access the junction object record with the most permissive access level of either master record. References: https://help.salesforce.com/s/articleView?id=sf.security_sharing_rules_types.htm &type=5 https://help.salesforce.com/s/articleView?id=sf.relationships_manytomany.htm &type=5

Two options that the administrator should use to meet these criteria are:

Share with roles and subordinates of the finance director role. This option allows you to grant access to records based on the role hierarchy of your org. You can share records with users who are in a specific role or in roles below that role in the hierarchy. In this case, you can share records with roles and subordinates of the finance director role, which includes all the members of the finance team.

Create a criteria-based sharing rule where the won field = true. This option allows you to grant access to records based on certain field values or formulas. You can create a criteria-based sharing rule on opportunities that grants access to records where the won field is true, which means that the opportunity stage is closed won.

The other two options are incorrect because:

Make an owner-based sharing rule where the won field = true is not an option because owner-based sharing rules do not allow you to specify field values or formulas as criteria. Owner-based sharing rules only allow you to share records based on who owns them or what role or group they belong to.

Select all opportunities owned by the sales manager role is not an option because it does not meet the criteria of sharing all closed won opportunities. It only shares opportunities that are owned by users who are in the sales manager role, regardless of their stage.

Delegated Administration allows administrators to delegate certain user management tasks to non-administrators. For example, a delegated administrator can assign permissions sets to users in specified roles or public groups without having full access to modify permission sets. References: https://help.salesforce.com/s/articleView?id=sf.admin_usermgt_delegated.htm &type=5

A before save flow trigger is a type of flow that runs before a record is saved and can update the record without any additional actions or database operations. This can expedite the time required to update the records and improve performance. A before save flow trigger can be used as an alternative to a process builder that updates the same record that triggered it. References: https://help.salesforce.com/s/articleView?id=sf.flow_concepts_trigger.htm &type=5 https://help.salesforce.com/s/articleView?id=sf.flow_ref_elements_triggers.htm &type=5

A validation rule is a formula that validates the data entered by a user and prevents the record from being saved if the data does not meet certain criteria. In this case, the administrator can create a validation rule to ensure that the custom encrypted field for credit card numbers has exactly 16 digits. The other options are not applicable for encrypted fields. References: https://help.salesforce.com/s/articleView?id=sf.fields_about_encrypted_fields.htm &type=5 https://help.salesforce.com/s/articleView?id=sf.validation_rules.htm &type=5

A lookup relationship is a type of field that links one object to another object. It allows you to access related data from another object and display it on a record page. A lookup relationship can be used to link the custom object that stores financial information to the Account object, so that only finance team members can see the related financial information about the account. References: https://help.salesforce.com/s/articleView?id=sf.relationships_lookup.htm &type=5

A delegated administrator is a user who has been granted limited administrative privileges by an administrator through delegated administration groups. Delegated administrators can perform some administrative tasks without having full access to Setup.

Some functions that delegated administrators can perform are:

B) Build automation and validation rules using screen flows

Screen flows are types of flows that guide users through screens with elements such as text boxes, picklists, radio buttons, etc. Screen flows can also perform actions such as creating records, updating fields, sending emails, etc. Delegated administrators can build automation and validation rules using screen flows if they have been granted access to create and edit flows by an administrator. References: https://help.salesforce.com/s/articleView?id=sf.flow_concepts_design_overview.htm &type=5 https://help.salesforce.com/s/articleView?id=sf.flow_distribute_delegated_admins.htm &type=5

D) Make updates to permission set configurations

Permission sets are collections of settings and permissions that can extend users’ functional access without changing their profiles. Delegated administrators can make updates to permission set configurations if they have been granted access to manage users by an administrator. References: https://help.salesforce.com/s/articleView?id=sf.users_permissionsets.htm &type=5 https://help.salesforce.com/s/articleView?id=sf.admin_useradmin_delegated.htm &type=5

Changing the record type of a record does not affect the record access of a user. Record access is determined by the organization-wide default, role hierarchy, sharing rules, manual sharing, teams, and ownership. Record type only affects the page layout and picklist values that are available for the record. Therefore, if a user has access to a record before changing its record type, they will still have the same access after changing its record type. References: https://help.salesforce.com/s/articleView?id=sf.customize_recordtype.htm &type=5 https://help.salesforce.com/s/articleView?id=sf.security_sharing_overview.htm &type=5

Implement Service Console is what the administrator should recommend to support staff at Cloud Kicks for a better agent experience. Service Console is a Salesforce app that provides a unified interface for agents to manage multiple customer interactions and records at once. Service Console can help agents work more efficiently and productively by providing features such as tabs, subtabs, list views, related lists, highlights panel, interaction log, macros, keyboard shortcuts, and more

To review the performance of a Lightning record page, administrators can utilize two key tools:

Lightning Usage App:

The Lightning Usage App provides insights into user engagement and performance metrics for Lightning Experience.

Within this app, administrators can view specific metrics related to page load times and other performance factors.

This is a helpful resource for tracking usage and identifying potential issues with page speed or performance across the org.

Analyze Button:

The Analyze button is available within the Lightning App Builder when editing a Lightning record page.

By clicking this button, administrators can run a performance analysis on the page layout, which provides specific recommendations for optimizing page load times and improving overall user experience.

The tool evaluates components, their configuration, and potential sources of delay, giving direct feedback on areas to improve.

These two options directly provide performance analysis capabilities for Lightning record pages. The other options listed do not offer direct access to page performance metrics:

Activation Button is used for setting page visibility rules and activating a page, not for performance analysis.

Pages Menu helps in navigating and managing pages but does not provide performance metrics.

Using both the Lightning Usage App and the Analyze button allows administrators to comprehensively review and optimize Lightning page performance for improved user experience.

Formula field and Dynamic Forms should be created to meet the requirements because a formula field can be used to count the number of open opportunities over US$10,000 related to an account using a roll-up summary filter condition, and Dynamic Forms can be used to display or hide a component on an account page based on a visibility filter using the formula field value. References: https://help.salesforce.com/s/articleView?id=sf.customize_functions_i_z.htm

Two options that the administrator should check to ensure the product is available are:

Confirm the correct price book is selected on the opportunity. A price book is a list of products and their prices that can be added to an opportunity. An opportunity can have only one price book at a time, and the products that are available for selection depend on the price book that is chosen. Therefore, the administrator should check if the opportunity has the right price book that contains the new keyboard product.

Ensure the product is associated with the correct price book. A product is a good or service that can be sold in Salesforce. A product can be associated with one or more price books, depending on how it is priced for different markets or segments. Therefore, the administrator should check if the new keyboard product is added to the appropriate price book that is used by the opportunity.

The other two options are incorrect because:

Making custom fields does not affect the availability of products on an opportunity. Custom fields are used to store additional information or calculations on an object, but they do not determine which products can be selected from a price book.

Turning on field tracking does not affect the availability of products on an opportunity. Field tracking is used to monitor changes to certain fields on an object and display them in a history related list, but it does not determine which products can be selected from a price book.

A record-triggered flow lets you automate actions when a record is created or updated. You can use scheduled paths to schedule actions relative to a date field on the record, such as close date. You should configure the trigger to flow after the record is saved so that you can access the updated field values. References: https://help.salesforce.com/s/articleView?id=sf.flow_concepts_trigger_types_record.htm &type=5

Data Loader is a tool that allows administrators to import or export large amounts of data (more than 50,000 records) from or to Salesforce using CSV files. Data Loader can be used for inserting, updating, deleting, upserting, exporting, or extracting data. Bulk API is an API that allows administrators to process large batches of records asynchronously in the background. Bulk API can handle millions of records with high performance and minimal system resources. By using Data Loader with Bulk API enabled, an administrator can import a large amount of historical data (more than 100,000 records) from another system efficiently and securely. References: https://help.salesforce.com/s/articleView?id=sf.data_loader.htm &type=5 https://help.salesforce.com/s/articleView?id=sf.loader_api.htm &type=5 https://help.salesforce.com/s/articleView?id=sf.bulk_api_intro.htm &type=5

Two practices that the administrator should adhere to in order to ensure a successful deployment to production are:

Add permissions and access settings to outbound change sets in addition to the dependent component list. This can help avoid deployment errors or access issues caused by missing permissions or settings for the components in the change set. For example, if the change set includes a new custom object, the administrator should also include the object permissions, field-level security, page layouts, and record types for that object.

Run deployment validations on the change set in the sandbox prior to uploading to production. This can help test the change set for any errors or conflicts before deploying it to production. Deployment validations simulate the deployment without actually making any changes and report any issues or warnings.

The other two options are incorrect because:

Cloning a change set does not add forgotten dependent components to an uploaded change set. It only creates a copy of the existing change set that can be modified before uploading.

When deploying a new record type, it is not necessary to have it as the only component in the change set. It can be deployed along with other components as long as they are compatible and have the required dependencies.

A phone field that provides the full phone number of the seller, a number field that designates the square footage of the listing, and a picklist field that designates the county of the listing should be used as filter criteria because they are fields that can be used to narrow down the report results based on specific values or ranges. A multi-select picklist field that designates features of the listing and a formula field that calculates a price for the listing should not be used as filter criteria because they are fields that cannot be filtered on in reports. References: https://help.salesforce.com/s/articleView?id=sf.reports_filtering.htm &type=5 https://help.salesforce.com/s/articleView?id=sf.reports_fields_unavailable.htm &type=5

Sharing rules are automatic exceptions to organization-wide sharing settings that grant additional access to records based on record ownership or criteria. By creating a sharing rule on the Account object for all members of the account services role to have Read/Write access, the administrator can allow users in that role to edit and change ownership of Accounts owned by any of their team members, regardless of the organization-wide sharing setting for Account. References: https://help.salesforce.com/s/articleView?id=sf.security_sharing_rules.htm &type=5

VisualStudio Code is a recommended tool to make the change in the displayed text in one of the Lightning web components. VisualStudio Code is an integrated development environment (IDE) that supports Salesforce development tools such as Salesforce Extensions for Visual Studio Code, Salesforce CLI, and Lightning Web Components. You can use VisualStudio Code to create, edit, debug, and deploy Lightning web components and other Salesforce metadata. To make the change in the displayed text, you need to open the HTML file of the Lightning web component in VisualStudio Code and modify the text element accordingly. References: https://developer.salesforce.com/tools/vscode https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.create_components

To resolve the issue with the Process Builder, the administrator should do the following steps:

Review the Error Email for the Process Builder and rectify the issues. The error email contains information about what caused the error and how to fix it.

Deactivate the Process Builder in production. This will prevent further errors from occurring while the administrator fixes the Process Builder.

Fix the Process Builder in a sandbox and migrate the change to production. This will ensure that the Process Builder is tested and validated before deploying it to production. References: https://help.salesforce.com/s/articleView?id=sf.flow_troubleshoot_error_email.htm &type=5 https://help.salesforce.com/s/articleView?id=sf.flow_deploy.htm &type=5

Product schedules are features that allow administrators to track revenue or quantity over time for products in opportunities or orders. Product schedules can be either revenue schedules or quantity schedules, depending on whether the product is sold by amount or by quantity. Product schedules can be either standard or customizable, depending on whether they use predefined settings or custom settings.

Line item schedules are records that represent each installment of revenue or quantity for a product over time. Line item schedules are created automatically when a product with a product schedule is added to an opportunity line item or an order product.

One limitation of product schedules is that line item schedules are unavailable in Process Builder and Workflow. This means that administrators cannot use these tools to automate actions based on line item schedules, such as sending email alerts, creating tasks, updating fields, or invoking flows. References: https://help.salesforce.com/s/articleView?id=sf.forecasts3_product_schedules.htm &type=5 https://help.salesforce.com/s/articleView?id=sf.orders_line_item_schedules.htm &type=5 https://help.salesforce.com/s/articleView?id=sf.product_schedule_considerations.htm &type=5

To add a user to an opportunity team, you need Edit access on the account associated with the opportunity and either own the opportunity or be above the owner in the role hierarchy. References: https://help.salesforce.com/s/articleView?id=sf.teams_adding.htm &type=5

Data Categories are a way to organize and classify knowledge articles into a hierarchical structure based on topics or criteria. Data Categories can help service reps quickly narrow down the number of articles by filtering or browsing by category. Data Categories can also be used to control the visibility and access of articles for different users or roles.

To show forecast numbers by territory regardless of who owns the record, CK should enable Territory Forecast. To forecast based on role hierarchy, CK should enable Role Hierarchy Forecast. To match the Territory Forecast to the Hierarchy Forecast model, CK should modify the Territory Forecast accordingly. References: https://help.salesforce.com/s/articleView?id=sf.forecasts3_territory_forecasts.htm &type=5 https://help.salesforce.com/s/articleView?id=sf.forecasts3_enable.htm &type=5

Configuring one app per department and activating record pages for each app will ensure that users view records in a way that makes sense for each department. An app is a collection of items that work together to serve a particular function. An app can have different record pages for different objects and profiles. By activating record pages for each app, the administrator can customize what users see based on their app context. References: https://help.salesforce.com/s/articleView?id=sf.app_manager_overview.htm &type=5 https://help.salesforce.com/s/articleView?id=sf.app_builder_customize_lex_pages_assign.htm &type=5

One possible cause of unexpected changes to record values is having multiple automation tools that update the same field on the same object. This can create conflicts and overwrite each other’s values. To resolve this issue, the administrator should consolidate automation tools and use only one tool per object and field combination. This can help avoid confusion and ensure consistent results. References: https://help.salesforce.com/s/articleView?id=sf.process_which_tool.htm &type=5 https://trailhead.salesforce.com/en/content/learn/modules/business_process_automation/automation_considerations

To ensure that multiple field updates occur in a specific order on a custom object, the administrator should create a process with one criteria node and three field updates arranged in the correct order. This approach allows the updates to execute sequentially within a single automation framework, ensuring that they happen in the intended order.

Using Process Builder with a Single Criteria Node:

In Process Builder, the administrator can define a single criteria node that triggers the field updates. By adding multiple field updates within this single node and arranging them in the desired sequence, Salesforce will execute them in that specific order.

This setup provides better control over the sequence of updates compared to multiple workflow rules, as Process Builder will execute each field update step by step as configured within the node.

Advantages Over Workflow Rules:

Unlike workflow rules, where the order of execution can be less predictable due to separate triggers, Process Builder enables precise control over the execution sequence within the same process.

Using multiple workflow rules or multiple criteria nodes with stop actions would complicate the setup without guaranteeing the specific order. Process Builder’s structure ensures that updates proceed in the exact order defined.

Incorrect options:

Option A (Three workflow rules): Creating separate workflow rules for each update does not ensure a specific order of execution, as workflow rules are not guaranteed to run sequentially.

Option C (Three criteria nodes with stop actions): This approach would execute each node separately, and the stop action after each node adds unnecessary complexity, without ensuring the sequential order required.

Option D (One workflow rule with three field updates): Workflow rules do not guarantee the order of field updates within a single rule. Using Process Builder with a single node is more reliable for sequential execution.

In conclusion, Process Builder with one criteria node and ordered field updates is the most effective approach to ensure a specific execution sequence for multiple field updates on the Shipment object.

Email logs are files that provide information about email delivery and activity in your Salesforce org. Email logs contain details such as sender, recipient, subject, date, status, error code, and more for each email sent or received within a specified time range. You can use email logs to investigate issues with email delivery or performance in your org. In this case, you can use email logs to check if the status update emails were sent successfully or if there were any errors or failures. References: https://help.salesforce.com/s/articleView?id=sf.email_logs.htm &type=5 https://help.salesforce.com/s/articleView?id=sf.email_logs_format.htm &type=5

Check the Reevaluate Workflow Rules After Field Change box on the Approval Process Field Update Action is what the administrator should do to troubleshoot the issue. This option allows the approval process field update to trigger any workflow rules or processes that are based on the updated field value. If this option is not checked, the approval process field update will not trigger any workflow rules or processes, and the Process Builder will not fire

Opening the flow in Debug mode and running it as another user allows simulating how the flow behaves for different users with different permissions and settings. This can help identify any issues related to user

Time-based workflows are a type of workflow that execute actions based on a specific time trigger, such as a certain number of days before or after a date field on a record. Time-based workflows can cause delays in processing because they are added to a queue and processed in one-hour batches. If the queue is large or the system is busy, the actions may not execute at the exact time they are scheduled. Therefore, time-based workflows can contribute to reaching the hourly limit for processing workflow time triggers. References: https://help.salesforce.com/s/articleView? id=sf.workflow_time_action_considerations.htm&type=5 https://help.salesforce.com/s/articleView?id=sf.workflow_limits.htm &type=5

Dynamic actions are a way to conditionally display actions on a record page based on criteria such as field values, user profile, device type, or record type. Dynamic actions can help streamline the user interface and guide users to take the right actions at the right time. Dynamic actions can be used to show or hide the Create Contract button based on the opportunity stage value

A rich text component allows administrators to add custom text or images to a Lightning page. Conditional visibility allows administrators to control when a component is visible based on criteria such as field values or device type. By using these features, administrators can highlight Canadian customers as a potential challenge for fulfillment without modifying the page layout or creating a new record type. References: https://help.salesforce.com/articleView?id=sf.app_builder_components_rich_text.htm &type=5 https://help.salesforce.com/articleView?id=sf.app_builder_component_visibility.htm &type=5

Flow is the automation tool that should be configured to utilize the major listing service endpoint. Flow is a tool that allows administrators to automate complex business processes by building flows that can collect, update, or delete data, invoke Apex code, call external services, and more. Flow can use an Apex action or an HTTP request action to send messages to an external endpoint using REST API

The resume event is recalculated and the email goes out to the account owner immediately because the flow uses a scheduled path that evaluates the expiration date field every time it changes. When the expiration date is changed to yesterday, the flow resumes immediately and executes the action of sending the email

A summary report with a cross-filter is a type of report that allows you to summarize data by grouping rows and columns and applying filters based on related objects and fields. A cross-filter is a filter that lets you include or exclude records in your report based on related objects and their fields. In this case, you can create a summary report that includes a cross-filter to the Account object with a sub-filter for credit card number equal to null. This will show you all B2C accounts that are missing the credit card number, regardless of whether it is encrypted or not. References: https://help.salesforce.com/s/articleView?id=sf.reports_summary_charts.htm &type=5 https://help.salesforce.com/s/articleView?id=sf.reports_cross_filters.htm &type=5

To help the finance team use Opportunity data to keep an eye on their pipeline without manually calculating anticipated income for the quarter, the administrator should set up collaborative forecasting. Collaborative forecasting allows users to view quota against open pipeline and make adjustments based on changing business conditions. References: https://help.salesforce.com/s/articleView?id=sf.forecasts3_overview.htm &type=5

A sandbox is a copy of a production org that can be used for development, testing, or training purposes. Sandboxes allow administrators to make changes and test them without affecting the live production org. A shared sandbox is a type of sandbox that can be used by multiple users or teams to collaborate on development or testing projects. By testing changes in a shared sandbox, the AW Computing administrator team can avoid conflicts and errors when deploying changes to production. References: https://help.salesforce.com/s/articleView?id=sf.data_sandbox.htm &type=5 https://help.salesforce.com/s/articleView?id=sf.data_sandbox_environments.htm &type=5

Dynamic actions are actions that appear on Lightning record pages based on criteria such as field values or user profiles. Dynamic actions allow administrators to customize which actions are available for users on different record types or page layouts without creating multiple page layouts for each scenario. By using dynamic actions and conditional visibility for accounts at AW Computing, administrators can show only relevant actions for customer service and sales users based on their situation. References: https://help.salesforce.com/s/articleView?id=sf.dynamic_actions_overview.htm &type=5

Giving the account owner Read access to both the Account and the Quota objects will give access to all Item records. Since Item is a junction object between Account and Quota, users need to have at least Read access to both parent objects to see Item records. If users have access to only one parent object, they will not be able to see Item records related to the other parent object. References: https://help.salesforce.com/s/articleView?id=sf.relationships_manytomany.htm &type=5

Another quote is already synced with the opportunity will prevent a user from syncing a quote with an opportunity. Only one quote can be synced with an opportunity at a time. If a user tries to sync another quote, they will get an error message saying that the opportunity already has a synced quote. References: https://help.salesforce.com/s/articleView?id=sf.quotes_syncing.htm &type=5

Run the standard Data Classification report is what the administrator should recommend to the compliance team. Data Classification is a feature that allows administrators to flag where sensitive information is stored in Salesforce by assigning sensitivity and classification levels to fields. Data Classification also provides a standard report that shows field level sensitivity and classification for all fields in an org. The administrator can run this report and share it with the compliance team to meet their requirement. 

Confirm the object is marked as deployed and not in development is what the administrator should do to resolve the issue. A custom object can be marked as deployed or in development depending on its readiness for use. A custom object that is marked as in development is not visible to users or available for data import or export. A custom object that is marked as deployed is visible to users and available for data import or export. Therefore, the administrator should make sure that the new custom object is marked as deployed before using Data Loader to upload records to it

A lookup relationship with Read/Write sharing setting is the recommended option to use when adding a field to Case Outcome custom object. A lookup relationship is a type of relationship that links two objects together and allows users to associate one record with another. A lookup relationship does not affect the security or deletion of either record and can be optional or required. In this case, you can create a lookup relationship field on Case Outcome object that references Case object and allows users to link multiple Case records to multiple Case Outcome records. You can also set the sharing setting for the lookup field to Read/Write, which means that users who have access to the parent record can also access and edit the child record. References: https://help.salesforce.com/s/articleView?id=sf.relationships_lookup.htm &type=5 https://help.salesforce.com/s/articleView?id=sf.relationships_considerations_lookup.htm &type=5

Bucket field is a feature that allows administrators to group report values into categories without changing the data in Salesforce. Bucket field can help simplify reports and charts by reducing the number of values displayed and summarizing data based on criteria such as ranges or groups. Bucket field can be used to group specific picklist values together into one of two lists

While the Schema Builder is a powerful tool in Salesforce for visually creating and managing custom objects and fields, there are certain configurations that must be done in Object Manager rather than Schema Builder. One of these configurations is enabling field history tracking.

Field History Tracking:

Field history tracking cannot be configured directly within Schema Builder. This setting must be enabled from within the Object Manager, where administrators can specify which fields on an object should have their changes tracked.

Enabling field history tracking involves navigating to the object in Object Manager, accessing the field history tracking settings, and selecting specific fields to track.

Limitations of Schema Builder:

Schema Builder is useful for quickly creating custom objects, relationships, and fields, but it does not support all configurations, such as enabling field history tracking, defining object-level permissions, or setting advanced object configurations.

For these types of configurations, administrators need to return to Object Manager where these settings are available.

Incorrect options:

Add custom fields to the page layout: This task is typically done within Object Manager, but Schema Builder does allow customization of page layouts to a certain extent through drag-and-drop.

Make available for Customer Portal: Schema Builder does not control portal availability; however, this is managed through Object Manager settings related to record visibility for portal users.

Allow Reports and Activities: This setting can be configured in Schema Builder when initially creating an object, but further refinements and permission settings must often be done in Object Manager.

In conclusion, enabling field history tracking requires access to the Object Manager, as it cannot be configured through Schema Builder.

Move any Potential Name records with blank lookup fields to the recycle bin or assign any Potential Name records with blank lookup fields to an existing record from Product Development are two options available for altering the existing Potential Name records for the deployment of this change to be successful. Changing a lookup relationship to a master-detail relationship requires that all child records have a parent record. Therefore, any Potential Name records that have blank lookup fields to Product Development need to be either deleted or assigned to a valid Product Development record before changing the relationship type

Entitlement templates are a way to automatically create and associate entitlements with products or service contracts. They can help simplify the management of entitlements and ensure that customers receive the correct level of service. Entitlement templates can also be used to define service levels, milestones, and entitlement processes for different types of products or service contracts.

The Setup Audit Trail is a tool that allows you to view and download a log of changes made in your org’s Setup area. The log shows up to 20 fields of information for each change, such as who made it, when it was made, what type of change it was, and what values were changed. You can use the Setup Audit Trail to track configuration changes directly in production and identify any unauthorized or problematic changes. One of the changes that the Setup Audit Trail tracks is when a user grants login access to another user. This means that you can use the Setup Audit Trail to see if any other administrators or delegated administrators are using the Log In As a User feature. References: https://help.salesforce.com/s/articleView?id=sf.monitorsetup.htm &type=5 https://help.salesforce.com/s/articleView?id=sf.remoteaccess_granting_login_access.htm &type=5

As explained in question 3, a price book is a list of products and their prices for a specific segment of customers or market. By creating a new price book for the U.K product pricing, Northern Trail Outfitters (NTO) can offer different prices for their products in the U.K market due to shipping and raw material cost differences. The price book can also specify which currency is used for the prices, such as pounds or euros. References: https://help.salesforce.com/s/articleView?id=sf.products_pricebooks_def.htm &type=5

Change sets are tools that allow administrators to move customizations such as fields, page layouts, profiles, permission sets, etc. from one Salesforce org to another. To use change sets, administrators need to establish a deployment connection between a source org (such as a sandbox) and a target org (such as production). Then, administrators can create an outbound change set in the source org that contains the components they want to deploy, and upload it to the target org. In the target org, administrators can view and validate the inbound change set before deploying it to their org. References: https://help.salesforce.com/s/articleView?id=sf.changesets.htm &type=5