Explanation:

When a custom object is created in Salesforce, it can be saved in either Deployed or In Development status. If the object is still marked as In Development, it will not appear in tools like Data Loader, even if the user has the correct permissions.

🔹 Why Option D Is Correct:
Only deployed objects are available for data operations like import/export.
To resolve the issue:
Go to Object Manager
Open the custom object
Click Edit
Ensure the Deployment Status is set to Deployed
Once deployed, the object will appear in Data Loader’s object list.

❌ Why the Other Options Are Incorrect:

A. Assign a permission set to give them access to the new object
While object permissions are necessary, they don’t affect visibility in Data Loader if the object is still In Development.

B. Check the Field-Level Security of the new custom object’s Name field
Field-level security affects visibility of fields, not whether the object appears in Data Loader.

C. Ensure Allow Sharing is checked on the custom object
“Allow Sharing” controls record-level access, not object availability in import tools.

🔗 Reference:
Custom Object Deployment Status
Data Loader Setup Guide

Explanation:

Since categories are already set up, the next logical steps are to refine how the search engine interprets user queries and prioritizes results. The two best tools for this are:

B. Create synonyms for specific search terms:
Users often search for the same concept using different words (e.g., "internet," "wi-fi," "broadband"). By creating synonyms, you can ensure that a search for any of these terms will return relevant articles, even if the article itself only uses one of the words. This dramatically improves the recall and user-friendliness of the search.

D. Promote specific search terms for specific articles:
This feature, often called "Promoted Results" in the context of Knowledge or Einstein Search, allows an administrator to manually curate search results. When a user enters a specific promoted term, a designated, highly relevant article is forced to the top of the search results. This is perfect for ensuring users find critical articles for common queries.

Let's examine why the other options are incorrect:

A. Configure Global Search for specific search terms:
Global Search is configured by selecting which objects and fields are searched. It is not a tool for fine-tuning the semantics or result ranking for a specific domain like Knowledge. Its configuration is too broad for this specific use case.

C. Configure Einstein Search for specific search terms:
Einstein Search is a powerful, AI-driven tool, but it is largely automated. Administrators enable and configure its overall behavior (like result ranking or field weighting), but they do not "configure it for specific search terms" in the same direct, manual way as creating synonyms or promoted terms. The configuration is more about tuning the algorithm, not defining specific term-to-article relationships.

Reference:

Salesforce Help: "Define Search Synonyms" - Details how to create synonyms to make search more flexible.
Salesforce Help: "Promote Search Terms in Knowledge" - Explains how to boost specific articles to the top of the results for key queries. (Note: The exact terminology may be "Promoted Results" in your Salesforce edition).

Explanation:

Universal Containers uses a Private sharing model for both Accounts and Opportunities, which means users can only see records they own or that are explicitly shared with them. The new renewals team needs access to all Closed Won Opportunities, but Accounts must remain private.

Here’s how Option D meets the requirements:
Create a public group for the renewals team to manage access collectively.
Use a criteria-based sharing rule on the Opportunity object to share Closed Won records with this group.
This ensures the renewals team can see all Closed Won Opportunities, regardless of ownership.
Because Opportunities are being shared directly, the related Accounts remain private, satisfying the confidentiality requirement.

❌ Why the Other Options Are Incorrect
A. Update the organization-wide default on Opportunities to Public Read Only and add them to the opportunities team
This would expose all Opportunities to everyone, not just Closed Won ones. It violates the requirement to keep access limited and controlled.
B. Create a permission set with View All enabled on Accounts and assign it to the new users
This would give users access to all Accounts, which contradicts the requirement to keep Accounts private.
C. Create a new profile for the renewals team with View All permission enabled on Accounts and Opportunities
Similar to Option B, this grants unrestricted access, including to Accounts, which is not acceptable under the stated privacy model.

Reference:
📘 Salesforce Help: Sharing Rules

Explanation:

Why this is correct
In Salesforce, merging records (Accounts, Contacts, or Leads) requires the user to have Delete permission on that object. Even if the user is the owner of both Accounts and has Read/Write access, the merge action won’t proceed without Delete on Account. That’s because the merge process effectively deletes the losing record(s) and consolidates data into the master record—hence the need for Delete.

Why the others are wrong?

A. Only administrators have permission to merge records.
Not true. Non-admin users can merge records as long as they have the right object permissions (including Delete) and appropriate access to the records being merged.

B. The user is assigned to the wrong territory.
Territory assignment affects record access/visibility, not the ability to merge once the user already owns and can edit the records. Territory is irrelevant here.

C. The Account matching rules are not set.
Matching/duplicate rules help identify potential duplicates and control whether to allow/block saving duplicates. They are not required to perform a manual merge of two records the user already selected; lacking a matching rule doesn’t cause a merge error.

Key takeaway
To merge Accounts, the user must:
Have Read and Edit on Account (met),
Be able to access both records (met; user is owner), and
Have Delete on Account (missing → causes the error).
Grant the user Delete permission on Accounts (via profile or permission set), and the merge will work.

Explanation:

In a many-to-many relationship using a junction object, a user's access to a junction record is controlled by their access to both associated master records.

Here's a breakdown of how it works:

Junction Object Inheritance:
The junction object (in this case, the one connecting Docs and Solar Panels) inherits its sharing settings and security from its two master parent records (Doc and Solar Panel).
Dual Master Records:
To view a junction record and subsequently see the related Solar Panel records, the user must have at least Read access to both master objects involved in the relationship.
Access Requirements:
The question specifies that the users already have access to the Doc object and the junction object, but not the Solar Panel object. Therefore, to see the related Solar Panel records, they must be granted Read permission on the Solar Panel object.

Why other options are incorrect
B. Access permission is not required on either master record:
This is incorrect. Access to a junction record is dependent on access to both master records. Without access to both master records, a user cannot view the junction record or its related master records.
C. Create permission is required on both master records:
Create access is not necessary to simply view records. The request is only for users to be able to view the related Solar Panel records, which only requires Read access. Create access would only be necessary if they needed to create new junction records.
D. Read permission is required on at least one master record:
This is incorrect. In a many-to-many relationship, to view a junction record, a user must have at least read access to both master records. The security follows the more restrictive of the two parent objects' sharing settings.

References
Inherited Sharing for Junction Objects (Salesforce Help): Explains that junction objects inherit sharing settings from both master records. To view a junction record, a user must have at least Read access to both master records.
Object Permissions (Salesforce Security Guide): Provides details on how permissions like "Read" and "Create" work and how object-level access is determined.
Trailhead: Data Modeling: The Trailhead module on data modeling covers master-detail relationships and many-to-many relationships, explaining how security is handled in these scenarios.