Explanation:
The requirement involves bulk-creating over 100 new Contacts and a related Case record for each Contact from a single spreadsheet after field work. The fastest, no-cost, out-of-the-box solution is the Salesforce Data Import Wizard (Setup → Data Import Wizard), which natively supports importing Contacts and creating one related Case per Contact in a single import operation using one CSV file. This is explicitly designed for case management scenarios and works in both NPSP and Nonprofit Cloud environments.

Correct Option:

A – Use Data Import Wizard to insert Contacts and related Cases.
Data Import Wizard allows mapping spreadsheet columns to Contact fields and Case fields simultaneously.

It automatically creates a Case for each successfully imported Contact and links them via the standard Contact lookup on Case.

Supports 50,000+ records, duplicate checking, and field mapping—no app install or extra licensing required.

Incorrect Option:

B – Configure NPSP Data Importer to upsert Contacts with related Cases.
NPSP Data Importer is designed for donations (Opportunities + Payments), not for Cases.

It does not support creating or relating Case records.

C – Install Case Management to upsert Contacts and relate them to Cases.
Nonprofit Cloud Case Management does not include a bulk import tool for Contacts + Cases.

The Data Import Wizard works the same with or without Case Management installed.

D – Create a web-to-case form that case managers will use to record the contact details.
Web-to-Case is for external users submitting cases via a public website, not for internal staff bulk-entry from a spreadsheet after field work.

Reference:
Salesforce Help → Data Import Wizard → “Import Contacts and Cases”

Explanation:
A government-issued ID number is highly sensitive Personal Identifiable Information (PII). The core requirement is to protect the data at rest in the database, not just control who sees it on a page. Removing it from a layout or using record ownership does not prevent someone with data export tools (like the API or Data Loader) from accessing the raw stored data. Field-level encryption ensures the data is stored in an unreadable format unless the user has explicit decryption rights.

Correct Option:

B. Encrypt the government ID field with Classic Encryption for Custom Fields and grant View Encrypted Data permission only to those users who have to interact with the data.
This provides data-at-rest encryption. The data is stored in the database in an encrypted (scrambled) format.

Access is controlled by the "View Encrypted Data" permission, which is granular and separate from object/field-level read permissions. Even users who can see the Contact record and the field will see only ciphertext without this permission.

This is the only option that addresses the fundamental need to protect the stored data value itself from unauthorized access via any means.

Incorrect Option:

A. Restrict visibility by removing it from the page layout and utilizing role hierarchy...
This only provides UI-level security. It does not protect the underlying data. A user with "Read" access on the Contact object and the field could still expose the sensitive ID number via a report, list view, API query, or data export tool. Role hierarchy does not prevent field-level data access.

C. Turn on two-factor authentication for the staff members...
Two-factor authentication (2FA) is a critical login security measure to verify user identity at sign-in. However, it does nothing to protect or encrypt sensitive data once the user is logged into the application. It is an important general security practice but is not a solution for securing a specific data field.

D. Set the org wide default on Contacts to Private so only the user who owns the Contact records can access it.
This is a record-level security measure. While it restricts which Contact records a user can see, it does not protect the sensitive field's data. Any user who does have access to the record (e.g., the owner, or users above them in the role hierarchy with "View All" on Contacts) would be able to see the unencrypted ID number in the field. It also breaks standard NPSP collaboration models.

Reference:
Salesforce Help on "Encrypt Custom Fields". The documentation states: "Use encrypted custom fields to protect sensitive information... The data is encrypted when it's stored and is only decrypted when displayed to a user who has the View Encrypted Data permission." This is the prescribed method for securing government IDs, social security numbers, and other regulated data.

Explanation:
The requirement is to grant specific users (case managers) the ability to create and edit records of a particular object (service delivery records, likely Program Engagements or Service Deliveries within PMM). This is a granular permission issue: granting Create, Read, Edit, Delete (CRED) access to an object and its fields. In Salesforce, this level of access is controlled by Profiles and Permission Sets, not by sharing or roles alone.

Correct Option:

A. Permission Sets
Permission Sets are the correct tool to grant additional object and field permissions to specific users without modifying their base profile. The consultant can create a Permission Set that grants Create and Edit access to the relevant Program Management objects and assign it to case managers.

Incorrect Options:

B. Sharing Rules
Sharing Rules control record-level visibility (which records a user can see), not object-level permissions (whether they can create or edit records of that type at all). A user must first have CRED permissions via their Profile or Permission Set; sharing rules then determine which specific records they can access.

C. License Type
The License Type determines which features and objects are available in the org (e.g., Nonprofit Cloud licenses include PMM). However, it does not grant granular permissions to individual users. All case managers likely already have an appropriate license; the issue is configuring their permissions within that license.

D. Role Hierarchy
The Role Hierarchy controls record-level visibility based on a user's role (users in higher roles can see records owned by users below them). Like sharing rules, it does not grant object-level create/edit permissions. It also does not help if case managers need to edit records owned by others at the same role level.

Reference:
Salesforce Help: "Permission Sets." Object-level permissions (CRED) are managed via Profiles (base permissions) and Permission Sets (additional permissions). For granting specific user groups like case managers access to PMM objects, Permission Sets are the standard, flexible tool.

Explanation:
This scenario involves sharing specific custom object records (Assessments, Notes, Alerts) with a defined set of staff who are not necessarily the record owners. In Salesforce, sharing records requires both object-level permissions (to see the object type) and record-level permissions (to see specific records). A two-part approach is needed: 1) grant object access, and 2) share the records.

Correct Options:

B. Create a Public Group of staff that need access to this information.
A Public Group is a collection of users (and potentially other groups) used as a recipient in Sharing Rules. Creating this group is the first step to identify who should get access. The group can then be referenced in the sharing rules to grant access to the records.

C. Create a permission set that grants Read/Write access to Assessments, Client Notes, and Client Alerts objects.
Object-level permissions (CRED) are required for users to see any records of that object type. A Permission Set is the appropriate tool to grant these permissions to the relevant staff without modifying their profiles. This ensures they can see the object tabs and lists.

Incorrect Options:

A. Create Sharing Rules for Assessments, Client Notes, and Client Alerts that share these with the public group.
While Sharing Rules are necessary for record-level access, they cannot be created for custom objects in all orgs unless the custom object's Sharing Setting is set to Controlled by Parent or Public Read/Write. For standalone custom objects, sharing is often managed via Manual Sharing, Apex, or Criteria-Based Sharing if available. A blanket sharing rule to a public group may not be configurable without specific org settings. However, this could be valid if the objects are set to "Private" and criteria-based sharing is used, but it's less straightforward than the standard approach using Permission Sets and Groups.

D. Create a Private Group of staff that need access to this information.
Private Groups are used within Chatter for collaboration and do not function as recipients for Sharing Rules. Sharing rules require Public Groups, Roles, or Roles and Subordinates. A Private Group cannot be used to share records system-wide.
Reference:
Salesforce Help: "Grant Access Using Hierarchies, Sharing Rules, and Manual Sharing" and "Create a Public Group." The standard pattern for sharing custom object data is:
Use Permission Sets to grant object-level CRED access.
Use Public Groups to define the user set.
Use Sharing Rules (if the object supports it) or Apex Managed Sharing to grant record-level access to that group.

Explanation:
When working on data mapping or integration, knowing when a field was introduced into NPSP helps ensure compatibility across systems. NPSP provides an official Data Dictionary, which documents fields, objects, descriptions, dependencies, and the exact package version in which each field was added. This makes it the most reliable resource for confirming field history. Other tools like Schema Builder or package details do not provide version-level metadata for individual fields

Correct Option Explanation

D. NPSP Data Dictionary
The NPSP Data Dictionary is the authoritative resource detailing every NPSP field, object, and related metadata. It includes information such as the field purpose, API name, and importantly, the NPSP package version in which the field was added. This level of detail is essential for consultants validating data mapping between systems or checking backward compatibility during integrations or upgrades.

Incorrect Option Explanations

A. Schema Builder
Schema Builder visually displays objects, relationships, and fields but does not include version information about when the field was added to NPSP. It is helpful for conceptual design but lacks any historical metadata or package-level details, making it insufficient for this requirement.

B. NPSP package details
Package details show overall NPSP version information but do not break down individual fields or indicate when each field was introduced. This view provides high-level package metadata only, not field-level versioning.

C. Custom field definition detail
The field detail page shows settings such as data type, help text, API name, and security but does not include NPSP package versioning. It also does not display when the field was added to the package. Therefore, it cannot answer the question of the field’s historical introduction into NPSP.

Reference:
Salesforce.org Documentation: NPSP Data Dictionary

NPSP Admin Resources: Understanding NPSP Metadata