Explanation:
The requirement is to categorize donors (Contacts) into recognition levels (Gold, Silver, Bronze) based on their year-to-date giving. This is a classic use case for donor recognition and stewardship. NPSP has a built-in, no-code feature specifically designed for this purpose: Levels. Levels automatically calculate a Contact's cumulative giving (with options for date ranges like "This Year") and assign a corresponding recognition level, which is then displayed on the Contact record.

Correct Option:

C. Set up NPSP Levels for the categories based on Total Gifts This Year.
NPSP Levels are a dedicated feature in Recurring Donations & Levels Settings.

You define Level names (Gold, Silver, Bronze) and the minimum amount for each (e.g., Gold = $1,000+).

You specify the source field for the calculation, such as "Total Gifts This Year" from the Contact's Soft Credit Rollups.

NPSP automatically evaluates each Contact's giving and assigns/updates their Level accordingly, with no custom automation needed.

Incorrect Option:

A. Create a picklist field that will display the categories based on the Total Gifts This Year field.
A simple picklist field is static; it cannot automatically calculate and update its value based on another field's changing total. It would require manual updating, defeating the purpose of automated donor recognition.

B. Create a custom field on the Opportunity that will display the categories and a process in Process Builder to populate the value based on the Total Gifts This Year field.
This is misplaced logic. Donor Levels are an attribute of the Contact (the donor), not of individual Opportunities (gifts). Building automation on the Opportunity to try to set a Contact-level category is unnecessarily complex and would require aggregating gifts, which is what the NPSP Levels feature already does efficiently.

D. Create a custom field on the Opportunity that will display the categories and a custom trigger to populate the value based on the Total Gifts This Year field.
Similar to Option B, this places the logic on the wrong object (Opportunity instead of Contact). More importantly, writing a custom trigger is unnecessary "re-inventing the wheel" when a robust, configurable, and supported standard NPSP feature (Levels) exists for this exact purpose.

Reference:
NPSP Documentation on Levels. This feature is explicitly described as a way to "recognize donors by creating donor levels" that are "automatically assigned to contacts based on their total giving within a specific date range," using fields like "Total Gifts Last Year" or "Total Gifts This Year."

Explanation:
Merging Contacts in NPSP requires specific permissions and compatible data conditions. If a user tries to merge two Contacts and one of them contains a unique external ID that would be lost, Salesforce prevents the merge to preserve data integrity. Additionally, Contact Merge requires delete access because the non-master record is deleted after merging. Without this permission, the merge fails. These issues are among the most common causes of merge errors in NPSP.

Correct Option:

A. A unique external ID was kept from the non-master contact.
External IDs must be unique across records. When merging, Salesforce attempts to delete the non-master record. If that Contact contains a unique External ID that is not transferred to the master record, the merge cannot proceed because deleting a record with a unique External ID could break integrations or downstream systems. Therefore, this condition commonly triggers merge failures in NPSP.

C. The user needs to have delete access to the contacts being merged.
Merging Contacts effectively deletes the non-master Contact after combining the data. Users must have Delete permission on the Contact object for NPSP Contact Merge to work. Without delete access, Salesforce blocks the operation, generating an error. This is one of the most frequent permission-related issues encountered during Contact Merge procedures.

Incorrect Option:

B. The contacts must be in the same household to merge.
NPSP does not require Contacts to be in the same Household Account to merge. Users may merge Contacts across different households, though doing so may update the household assignment. This condition does not cause merge failures, so it is not a likely reason for the reported issue.

D. The NPSP Duplicate Rule was set to Warn instead of auto-merge.
Duplicate rules set to Warn simply alert the user about a potential duplicate but do not block merging. NPSP Contact Merge does not auto-merge contacts based on duplicate rules—it requires a manual merge process. Therefore, a “Warn” rule does not prevent merging and is not a cause of the error.

Reference:
Salesforce Help: Merge Contacts Considerations

NPSP Documentation: Using Contact Merge in NPSP

Salesforce Security & Access: Object Permissions and Delete Requirements

Explanation:
This question focuses on troubleshooting Customizable Rollups (CRLP) in NPSP, a core feature for roll-up summary operations. A runtime error during record update typically points to a data validation or permission issue on the target record itself, not a configuration error in the rollup definition. The CRLP engine successfully calculates the value but fails when saving it.

Correct Option:

C. If the Target Field has a validation rule.
A validation rule on the target object can block the rollup's update even if the calculated value is correct. The CRLP process runs in the system context but must still obey all defined validation rules. This is the most common cause for "update failed" errors after calculation, as the rule's logic may conflict with the automated update's context or data state.

Incorrect Options:

A. If the Target Field exists.
This would cause a deployment or configuration error when setting up the rollup definition, not a runtime update error. The system validates the field's existence when the Customizable Rollup is created or saved, not during execution.

B. If the Target Field is an NPSP field.
Customizable Rollups can update both standard fields and custom fields (NPSP or otherwise). The field's origin does not cause a runtime update failure. The critical factors are field permissions, data type, and any constraints like validation rules.

D. If the Target Object is a custom object.
Customizable Rollups are designed to work with both standard and custom objects. The object type is not a source of runtime update errors. The error is specific to the record update, which depends on field-level and object-level permissions and validations, not the object's classification.

Reference:
Salesforce Help: "Customizable Rollups Troubleshooting" and "Considerations for Customizable Rollups" specifically mention validation rules as a common cause for update failures.

Explanation:

The Opportunities report type is ideal for donation data in NPSP. A cross filter (Opportunities with Contacts where Board Member = TRUE) includes only board members’ donations. Summarizing Total Gifts this Year (direct gifts) and Soft Credits this Year (influenced gifts) shows fiscal year totals per board member, leveraging NPSP rollup fields.

Why others are incorrect:
B: Contacts & Accounts report type is less suited for donation data; misses Soft Credits detail.
C: Field filter can’t directly apply Contact’s Board_Member__c to Opportunities; grouping is less effective than summarizing.
D: Contacts & Accounts report type is donation-focused; “Giving Totals” is unclear; cross filter is vague.

Reference:
NPSP Documentation, Salesforce Cross Filters.

Explanation:
Salesforce's standard functionality imposes a technical limit on the depth of the Campaign Hierarchy. A Campaign Hierarchy can only be nested a maximum of five levels deep (Parent to Child, five campaigns total in the path). The organization has requested a hierarchy of six nested campaigns (Friends of the Organization > FY19 > Capital Campaign > Annual Fund > Digital Donations > Mobile). Since six levels exceed the five-level limit, the consultant must advise the organization to consolidate or restructure the hierarchy to fit within the supported depth.

Correct Option:

B. Suggest consolidating at least one of the Campaigns so that it is within the Campaign Hierarchy limit.
The requested hierarchy depth is 6: (1) Friends > (2) FY19 > (3) Capital > (4) Annual > (5) Digital > (6) Mobile.

Salesforce's technical limit for Campaign Hierarchy depth is five levels.

The consultant's primary duty is to identify and resolve this technical constraint, which requires consolidating or re-architecting two of the campaigns (e.g., merging "Digital Donations" and "Mobile" into one campaign or removing "FY19" if it's implicitly captured by a Date field).

Incorrect Option:

A. Create a custom lookup field, "Related Campaign" on the Campaign object.
While a custom lookup could link campaigns, it would bypass the standard Campaign Hierarchy roll-up fields (e.g., Total Opportunities in Hierarchy), which is the entire reason for using the hierarchy feature. This solution breaks standard reporting functionality and creates technical debt.

C. Create a Campaign Hierarchy with the parent Campaign record as, "Friends of the Organization"
This is the correct starting action for creating the hierarchy, but it does not solve the core problem that the total depth of the requested hierarchy is 6, which still violates the 5-level technical limit.

D. Suggest changing the order of the hierarchy.
Changing the order (e.g., putting "Mobile" under "Friends") does not change the total number of levels required, which is still six. The problem is the depth, not the sequence. The six distinct campaigns still need to be represented, which is impossible in a five-level structure.

Reference:
Salesforce Help: Campaign Hierarchy documentation, which states the maximum depth is five levels.