Explanation:

When an app builder creates a new field using Schema Builder in Salesforce, the field is added to the object and, by default, is accessible to all profiles unless specific field-level security (FLS) settings are configured afterward. This means that the field is visible and editable by all users, regardless of their profile, unless the app builder explicitly modifies the field’s visibility through Field-Level Security settings in the Profiles or Permission Sets. This default behavior ensures that new fields are immediately available across the organization, allowing for quick deployment, with the ability to restrict access later as needed.

Why not the other options?
A. Standard profiles:
Standard profiles (e.g., System Administrator, Standard User) do not receive exclusive default access. All profiles, including both standard and custom ones, inherit access to the new field unless restricted.
B. No profiles:
This is incorrect because new fields are not hidden by default; they are accessible to all users unless security settings are applied to limit access.
C. Internal profiles:
The term "internal profiles" is not a standard Salesforce classification, and access is not limited to internal users (e.g., employees) versus external users (e.g., partners or customers) by default. All profiles, including those for internal and external users, get access unless restricted.

Additional Notes:
After creating the field, the app builder should review and adjust Field-Level Security in the Profile or Permission Set settings to enforce the desired access levels (e.g., Read-Only, Hidden) based on organizational requirements.
This behavior applies to custom fields on custom or standard objects created via Schema Builder or the Object Manager.

References:
Salesforce Help: Field-Level Security (Explains that new fields are accessible to all profiles by default until FLS is configured).
Salesforce Trailhead: Customize a Salesforce Object (Covers field creation and default accessibility in Schema Builder).
Salesforce Help: Schema Builder Overview (Details the process of adding fields and their initial accessibility).

Explanation:

Why:
A junction object typically uses two master-detail relationships (here: Account Interest → Account and Interest). Access to a detail record is controlled by its master(s). To see a junction record, a user must have Read access to both parent objects. If the user lacks Read on Interest, they can still open the Account record, but the Account Interest related list items won’t be visible, nor will the Interest records themselves.

Why not the others:
A. Wrong—no Read on Interest means they can’t see Interest, and thus can’t see the junction records either.
B. Wrong—lack of Interest access doesn’t block visibility to the Account record.
D. Wrong—you can’t see the junction record at all without Read to both masters.

Explanation:

The import wizard only allows values to be imported into a dependent picklist if they match the appropriate controlling field. This ensures data integrity and prevents invalid values from being imported.
Custom picklist fields can be either controlling or dependent fields. This allows the app builder to create custom dependencies between custom picklists.
Checkbox fields can be controlling fields but not dependent fields. This allows the app builder to create dependencies based on checkbox values, such as true or false. Multi-select picklist fields can be dependent picklist fields but not controlling fields.
This allows the app builder to create dependencies based on multiple values selected in a multi-select picklist field. Standard and custom picklist fields can be dependent fields, but not all standard picklist fields can be controlling fields.
Some standard picklist fields, such as Lead Status or Opportunity Stage, cannot be controlling fields because they are used in other processes, such as lead conversion or sales path.

Explanation:

Why:
A record-triggered Flow on Account (run after save, on Update) can check if Type changed to “Past-Customer” and then update related Contact records to set Status = “Re-Market.” You can do this with Update Related Records (no loops needed).

Why not the others
A. Screen flow — requires user interaction; not automatic on field change.
B. Lightning component — UI component, not the right tool for background automation.
C. Validation rule — prevents bad data; it can’t update related records.

Explanation:

The app builder should provision a Partial Data sandbox to the developer. A Partial Data sandbox can have up to 5 GB of data, which meets the requirement of having at least half a gigabyte of data. A Partial Data sandbox can also be refreshed every 5 days, which meets the requirement of refreshing after each three-day sprint.

Option A is incorrect because a Developer sandbox can only have up to 200 MB of data, which does not meet the requirement.
Option B is incorrect because a Full Copy sandbox can only be refreshed every 29 days, which does not meet the requirement.
Option C is incorrect because a Developer Pro sandbox can only have up to 1 GB of data, which may not be enough for the requirement.

Explanation:

Universal Containers has a Lightning record page that supports both the mobile app and desktop, and a custom Lightning component downloaded from AppExchange is not visible on mobile devices. The most likely issue is that the component has been developed for Desktop Pages only. Many AppExchange components are designed and optimized for desktop use, and their documentation or metadata may indicate they are not compatible with the Salesforce mobile app (e.g., Salesforce Mobile App or Lightning Experience on mobile browsers). To be mobile-compatible, a Lightning component must explicitly support the Salesforce mobile framework, which requires the developer to ensure responsiveness and compatibility with the mobile runtime.

Why not the other options?
A. The record page needs to be activated:
If the record page were not activated, it would not be visible on either desktop or mobile, and the issue specifies that users can see the page on desktop but not mobile. Activation applies to the entire page, not selective components, so this is not the cause.
C. The component needs to be activated:
Lightning components from AppExchange are typically installed and available for use once deployed, unless explicitly deactivated by an administrator. Deactivation would affect visibility on both desktop and mobile, not just mobile, making this unlikely.
D. The record page template is unable to support mobile devices:
The problem states that the record page supports both the mobile app and desktop, implying the template (e.g., a standard or custom Lightning page template) is mobile-compatible. The issue is specific to the component, not the template, so this is not the root cause.

Additional Notes:
To confirm, the app builder should check the component's documentation on AppExchange or contact the publisher to verify its mobile compatibility.
If the component is desktop-only, the builder could explore alternatives (e.g., a mobile-compatible version) or customize the page to hide the component on mobile using the Lightning App Builder's "Component Visibility" filter (e.g., based on device type).

References:
Salesforce Help: Lightning Components for Mobile (Details mobile compatibility requirements for components).
Salesforce Trailhead: Build UI with Lightning Components (Covers component development and deployment considerations).
AppExchange: Component Listings (Often includes mobile compatibility notes in component descriptions).

Explanation:

The requirement is to use a field to store a legacy system ID for the purpose of linking records during future data loads (upserts). This is a classic use case for an External ID field.

Why C (External ID) is Correct:
This is the primary attribute needed. Marking a field as an External ID allows it to be used as a unique identifier for upsert operations in the Data Import Wizard, Data Loader, or other APIs. When you upsert records, you can specify this External ID field to match records from your source file to existing records in Salesforce, updating them if they exist or creating them if they don't.

Why A (Unique) is Correct:
For an External ID to work reliably for upserts, it must be unique. If the legacy ID values are not unique, the upsert operation will fail because Salesforce won't be able to determine which single record to update. Therefore, selecting the Unique attribute is mandatory to ensure data integrity and the success of the upsert process.

Why B (Required) is Incorrect:
While you might want this field to be populated, making it Required is not necessary for the upsert operation to work. The upsert process only uses the External ID to find a match. If the field is blank in your source file for a new record, the upsert will simply create a new record with a blank value in that field. Making it required could unnecessarily complicate your data load if the legacy system has any missing IDs.

Why D (Text (encrypted)) is Incorrect:
An encrypted text field cannot be used as an External ID or have a unique index. The encryption prevents Salesforce from indexing the values, which is a prerequisite for both the External ID and Unique attributes. Therefore, this field type is incompatible with the stated requirement.

Reference:
Salesforce Help Article: "Upserting Records" and "External ID Fields." The documentation clearly states that an external ID is a field that can store a record identifier from a system outside of Salesforce and that you can use upsert to match against this field. It also notes that the field must have the "External ID" attribute selected and typically should be unique.

Explanation:

Salesforce provides several standard Opportunity fields that can be configured directly through the UI (Setup → Object Manager → Opportunity → Fields & Relationships). These fields can be customized in terms of:
Picklist values
Field-level security
Page layout visibility
Here’s how each correct option qualifies:
🔹 B. Stage
✅ Fully configurable picklist
You can define custom stages, assign probability percentages, and map them to forecast categories
🔹 C. Lead Source
✅ Standard picklist field
You can customize the values to reflect your organization’s lead generation channels
🔹 D. Type
✅ Standard picklist field
Often used to categorize Opportunities (e.g., New Business, Existing Customer)

❌ Why A. Forecast Category is incorrect:
Forecast Category
❌ Not directly configurable — it’s mapped to Stage values via the Sales Process setup. You can’t edit it independently.

🔗 Reference:
Customize Opportunity Fields – Salesforce Help
Sales Process and Stage Mapping – Trailhead

Explanation:

To upgrade an unmanaged package that is currently installed in a production org, the recommended process is to use the Installed Packages page in Salesforce Setup. An unmanaged package is a collection of components (e.g., custom objects, fields, workflows) that, once installed, cannot be upgraded in the traditional sense like managed packages because the source code and metadata remain editable by the installing org. However, if the package publisher releases an updated version, users can upgrade by navigating to Setup > Installed Packages, locating the package, and clicking the Update link (if available). This initiates the upgrade process, installing the new version over the existing one while preserving customizations made in the org.

Why not the other options?
A. Uninstall the current version and install the new version:
Uninstalling an unmanaged package removes all associated components and any customizations, which is not a viable upgrade path as it would require rebuilding custom work. This approach is disruptive and incorrect for upgrading.
B. Use the Install Wizard to install the upgrade to production:
The Install Wizard is used for initial installation of a package, not for upgrading an existing one. For an upgrade, the Installed Packages page provides the specific update mechanism, making this option inaccurate.
C. Install the new version to a Developer org then deploy to production:
This process applies to custom development or managed packages with change sets or deployment tools (e.g., Salesforce DX), not unmanaged packages. Unmanaged packages do not support deployment from a Developer org to production as a standard upgrade method, and this would overwrite the production org's customizations incorrectly.

Additional Notes:
The availability of an update link depends on the package publisher releasing a new version and the org having internet access to check for updates.
After clicking the update link, follow the prompts to review and confirm the changes, ensuring no conflicts with existing customizations.
Test the upgrade in a sandbox (if available) before applying it to production to mitigate risks, though this is a best practice rather than a required step.

References:
Salesforce Help: Install and Upgrade Packages (Explains the update process for installed packages).
Salesforce Trailhead: Package Basics (Covers unmanaged package behavior and upgrade options).
Salesforce Help: Unmanaged Packages (Details limitations and upgrade process).

Explanation:

Why this is correct:
Your custom report type’s primary object is Opportunities. Because Opportunity looks up to Account, you can edit the report type layout and use Add fields related via lookup to pull in fields from the parent Account—such as Account → Rating—so they’re selectable in reports built from that type.

Why the others are wrong:
A. Change the primary object to Account — You can’t change a report type’s primary object after creation, and switching to Account wouldn’t match the “Opportunities with or without Shipments” use case.
B. Add the Account Rating field to the opportunity record page — Page layouts don’t control reportable fields. Reporting availability comes from the report type layout, not the record page.
D. Change the account/opportunity relationship to master/detail — The standard Account–Opportunity relationship is a lookup and can’t be made master-detail. It’s also unnecessary; related lookup fields are reportable via the custom report type layout.

Reference:
Custom Report Types → Edit Layout → Add fields related via lookup (lets you include parent-object fields like Account fields on an Opportunity-based report type).

Explanation:

Ursa Major Solar (UMS) currently uses a public sharing model for accounts (likely Public Read/Write or Public Read Only), and they want to move to a more restrictive sharing model (e.g., Private) while ensuring the Sales team retains access to all accounts with the Sales record type. This requires adjusting the organization-wide defaults (OWD) and using a sharing rule to grant specific access. Here’s how:
B. Update the organization-wide defaults:
Changing the OWD for the Account object to a more restrictive setting (e.g., Private) is the first step to enforce a tighter sharing model. This limits access to account records to the record owner and users with higher access (e.g., via roles or sharing rules), replacing the public access model. This aligns with the goal of moving to a restrictive sharing model.
C. Create a criteria-based sharing rule:
A criteria-based sharing rule can grant access to all accounts with the Sales record type to the Sales team. The rule can be configured with a criterion like RecordType.Name = 'Sales' and share those records with a public group, role, or role hierarchy containing the Sales team members, setting access to Read Only or Read/Write as needed. This ensures the Sales team retains access to the specified records post-OWD change.

Why not the other options?
A. Update the Sales profile:
Updating the Sales profile (e.g., modifying object or field permissions) does not directly address record-level access based on record type. Profiles control permissions (e.g., Create, Read, Edit) but not sharing rules or record visibility, which are managed by OWD and sharing rules. This is insufficient for the requirement.
D. Create an owner-based sharing rule:
An owner-based sharing rule grants access based on the record owner’s role or public group (e.g., sharing records owned by Sales reps with managers). However, this does not guarantee access to all accounts with the Sales record type, especially if ownership varies across teams. A criteria-based rule is more precise for targeting record type, making this less suitable.

Implementation Notes:
Change the Account OWD to Private via Setup > Security > Sharing Settings.
Create a criteria-based sharing rule under Sharing Settings > Account Sharing Rules, setting the criterion to RecordType.Name = 'Sales' and assigning access to the Sales team’s role or public group.
Test the change in a sandbox to ensure no unintended access restrictions occur.

References:
Salesforce Help: Set Organization-Wide Sharing Defaults (Explains OWD configuration).
Salesforce Help: Create Criteria-Based Sharing Rules (Details how to use record type in sharing rules).
Salesforce Trailhead: Data Security (Covers OWD and sharing rule concepts).

Explanation:

The two considerations that an app builder should keep in mind during the deployment process using change sets are:
Change sets do not include all components and may have to perform some changes manually. Change sets are a way to deploy metadata changes from one Salesforce org to another, but they do not support all types of components, such as reports, dashboards, email templates, etc.
The app builder may have to use other methods, such as unmanaged packages or manual configuration, to deploy these components.

Users should be logged out of production when receiving inbound change sets. This is a best practice to avoid any errors or conflicts that may occur when deploying changes to production.
Users may be working on records or components that are being updated by the change set, which may cause data loss or inconsistency. Salesforce Connect does not automatically establish a link between environments. Salesforce Connect is a feature that allows users to access data from external sources without storing it in Salesforce. It does not have anything to do with deploying changes between Salesforce orgs. Transactions will not revert if the deployment errors.

Transactions are units of work that are either completed entirely or not at all. If a deployment error occurs during a transaction, the transaction will be rolled back and no changes will be made to the target org. However, this does not mean that the source org will revert to its previous state before the deployment.