Explanation:
The requirement is to track funds for reporting on restricted donations. This is a financial accounting need where donations (Opportunities) must be categorized and subtotaled according to the specific fund or purpose for which they are restricted (e.g., Annual Fund, Capital Campaign, Scholarship Fund). NPSP provides a specific feature designed to model this structure without requiring complex customizations.

Correct Option:

C. General Accounting Units
General Accounting Units (GAUs) are the core NPSP feature for tracking funds, designations, and other financial categories.

You can create a GAU for each fund (e.g., "Building Fund," "Endowment"). Then, using Default GAU Allocations or Campaign GAU Allocations, you can attribute all or a percentage of each donation (Opportunity) to the appropriate fund(s).

Standard and custom reports can then summarize revenue by GAU, providing the necessary reporting on restricted donations.

Incorrect Option:

A. Levels
Levels are used to recognize donors based on cumulative giving (e.g., Bronze, Silver, Gold). This is a recognition/acknowledgement tool, not a financial accounting tool for tracking restricted revenue by fund.

B. Engagement Plans
Engagement Plans are automated, templated series of tasks (like calls or emails) used for donor cultivation and stewardship. They manage actions, not the financial categorization of donations.

D. Customizable Rollups
Customizable Rollups (CRLPs) are used to calculate and display summaries of data (like total gifts) on a record (like a Contact or Account). While they could display a total for a fund if built, they are not the primary tracking and categorization mechanism. GAUs are designed for the categorization, and CRLPs can then roll up the totals.

Reference:
NPSP Documentation on General Accounting Units (GAUs). GAUs are explicitly designed to "track income for different funds, campaigns, or appeals" and "attribute revenue to specific accounting units," making them the standard solution for tracking restricted donations and reporting by fund.

Explanation:
Salesforce has a strict requirement for test code coverage when deploying or installing packages, especially in a Production environment. While a Sandbox environment often has less stringent checks, a Production organization requires a minimum of 75% overall Apex code coverage to allow the installation or successful upgrade of major managed packages like NPSP. If the custom code or triggers in the Production environment bring the organization's overall code coverage below the required threshold, the NPSP upgrade validation will fail.

Correct Option:

A. Not having adequate test code coverage
Salesforce mandates a minimum of 75% overall Apex test code coverage for a Production organization to accept any major package installation or upgrade.

If custom Apex code deployed in Production is missing corresponding unit tests, or if those tests fail, the organization's overall code coverage percentage can drop below this threshold, causing the NPSP upgrade to fail the validation check upon deployment to Production.

Incorrect Option:

B. Not having one or more of the packages in NPSP installed
The NPSP upgrade process is run after the initial installation of the base NPSP package. If a necessary component were missing, the upgrade wouldn't typically be attempted, or the initial installation would have failed. Missing packages are rarely the cause of a mid-upgrade failure in Production when it worked in a Sandbox.

C. Not running the NPSP Health Check before trying to upgrade in production
The NPSP Health Check is a tool that identifies configuration issues and data inconsistencies, which is a best practice. However, failing to run it doesn't cause the upgrade to fail; a missing prerequisite (like sufficient code coverage) is the true technical blocker.

D. Not changing the account model to the Household Account Model before trying to upgrade
The Household Account Model is the default and recommended model for NPSP. The upgrade itself does not typically require a model change (unless you were using an older legacy model), and forcing a change is usually a complex data migration task, not a prerequisite for the package installation process itself.

Reference:
Salesforce Help: Test Coverage Requirements for Deployments and Packages. The distinction between Sandbox and Production security and code coverage requirements is a fundamental aspect of Salesforce development and deployment best practices.

Explanation:
NPSP includes Membership Rollups, which summarize active memberships, expiration dates, and status at the Account or Contact level. For rollups to work properly, NPSP must know which record types represent memberships and how to treat expiration through grace periods. Without setting both of these, Salesforce cannot correctly identify, classify, or roll up membership data—resulting in inaccurate reporting for the nonprofit’s membership program.

Correct Option:

B. Check that the membership record type is selected for membership rollups.
Membership rollups only evaluate Opportunities that NPSP identifies as “membership.” Setting the correct Opportunity record type ensures the rollup engine processes those transactions. Without this selection, NPSP cannot differentiate membership payments from other revenue types, preventing accurate rollup calculations.

D. Check that the grace period is set up for memberships.
The grace period determines how long a membership remains active after expiration. Setting this ensures rollups correctly classify memberships as active, expired, or in grace. Proper configuration prevents inaccurate membership counts and ensures continuity for renewals and benefit eligibility.

Incorrect Options:

A. Ensure there is a custom field created for MembershipAmount and selected for membership rollups.
NPSP does not require a separate MembershipAmount custom field for rollups. Memberships rely on standard Opportunity fields such as Amount, Close Date, and Stage. Creating a custom field is unnecessary and does not influence NPSP membership rollup functionality.

C. Ensure there is an Opportunity record type set up for memberships.
While memberships may use a record type, simply creating one is not enough. The important requirement is selecting the record type in the NPSP rollup settings (Option B). Without selecting it, the rollup engine will not include these records in membership calculations.

Reference:
Salesforce NPSP Documentation – Memberships and Rollups
Salesforce NPSP Documentation – Memberships and Rollups

Explanation:
Migrating a large volume of records, particularly addresses, into NPSP requires careful planning due to system architecture and limits. NPSP's enhanced Address Management uses a custom Address__c object, which changes how address data is stored and related. The volume of historical address data directly consumes data storage, a key Salesforce commodity. Understanding these impacts is critical for a successful migration.

Correct Options:

B. Tracking addresses with the Address object may introduce more complexity.
NPSP's Address object creates a many-to-one relationship (many Contacts to one Address record) instead of storing addresses directly on Contact or Account fields. This requires data to be migrated into a different object structure, complicating the mapping, transformation, and validation logic in the migration process compared to a simpler field-to-field copy.

C. Migrating all historical address information impacts system data storage.
Each historical address record migrated into the NPSP Address__c object consumes data storage (records and file storage).

Migrating a "large volume" of historical addresses, including past/inactive ones, must be weighed against available storage limits and the ongoing need to retain that history, as it has a direct and permanent cost implication.

Incorrect Options:

A. Address verification only works with the one-to-one and individual ("Bucket") Account models.
False. NPSP's Address Verification feature (often via integrations like SmartyStreets or Google) works with the Household Account model, which is the recommended and most common model. It does not require the deprecated "Bucket" model.

D. There is a limit of three addresses per contact or organization that can be migrated into NPSP.
False. There is no hard-coded NPSP limit of three addresses per record. The system can store multiple current and historical address records per Household (Account) via the Address__c object. Practical limits are governed by data storage, not a fixed rule of three.

Reference:
NPSP Documentation on Data Importing and Data Storage Considerations. Best practices for data migration emphasize understanding the target NPSP data model (like the custom Address object) and the impact of data volume on system performance and storage limits.

Explanation:
The requirement is to automate adding donors of a specific fund (Capital Fund) to a specific campaign (Capital Campaign). NPSP provides a native, declarative (no-code) feature for this exact purpose. It works by linking the Opportunity (donation) to a Campaign, which then automatically manages the Campaign Membership for the donor (Contact).

Correct Options:

B. Enable the Automatic Campaign Member Management in NPSP settings.
This is the foundational NPSP setting that must be activated. When enabled, it automatically creates a Campaign Member record linking a Contact to a Campaign whenever that Contact is associated with an Opportunity where the Primary Campaign Source field is populated.

D. Populate the Primary Campaign Source field on the Opportunity record.
This is the triggering action. When a donation (Opportunity) to the "Capital Fund" (likely tracked via a GAU or Record Type) is created, the user or an automated process must populate the Primary Campaign Source field with the "Capital Campaign" Campaign. The enabled NPSP setting (Option B) then automatically creates the Campaign Member.

Incorrect Options:

A. Upload a list of all donors as Campaign Members using the Data Import Wizard.
This is a manual, one-time batch operation, not an automated, ongoing process. It would only add existing donors at the time of upload. It does not fulfill the requirement to automatically add any future donor who gives to the Capital Fund.

C. Create a trigger that automatically adds any donor as a Campaign Member.
While this could technically work, it is unnecessary custom code. NPSP already provides the declarative functionality through Options B and D. Using a trigger would be "re-inventing the wheel," adding complexity and maintenance overhead when a standard, supported feature exists.

Reference:
NPSP Documentation on Automatic Campaign Member Management. This feature is explicitly designed to "automatically add the donor (Contact) as a Campaign Member to the Campaign you specify in the Opportunity’s Primary Campaign Source field," making it the prescribed solution for this scenario.

Explanation:
The Nonprofit Success Pack (NPSP) provides a dedicated tool, the NPSP Contact Merge utility, specifically designed to handle duplicate Contact records within the NPSP data model. Unlike standard Salesforce merge tools, the NPSP Contact Merge correctly handles the complex relationships unique to NPSP, such as Household Accounts, Affiliations, and Relationships. Using this built-in utility is the recommended and safest method for bulk duplicate cleanup in an NPSP organization.

Correct Option:

B. NPSP Contact Merge
The NPSP Contact Merge tool is purpose-built to recognize and correctly reconcile duplicate Contact records while preserving NPSP-specific data.

It intelligently manages related records like Opportunities (Donations), Relationships, and Affiliations, ensuring that when two Contacts merge, all related NPSP records are correctly reparented to the master Contact.

This tool provides a guided, user-friendly interface for administrators to identify and merge duplicates in bulk, making it the most efficient and safest solution for NPSP.

Incorrect Option:

A. Salesforce Duplicate Management
While standard Salesforce Duplicate Management helps identify duplicates and provides a basic merge function, it is not NPSP-aware. Using the standard tool may cause errors or data loss with NPSP-specific objects (like Relationships or Household Accounts), requiring manual fixes.

C. Third party app from the AppExchange
AppExchange tools can be powerful, but they often require extra licensing and testing. The NPSP Contact Merge utility is a free, built-in feature that is guaranteed to be compatible with the NPSP data model, making it the preferred initial recommendation over an external application.

D. Salesforce Data Loader
The Data Loader is a tool for inserting, updating, or deleting data in bulk. It is a data migration tool, not a duplicate resolution tool. It has no functionality to automatically compare records, determine a master, or safely merge related records, making it entirely unsuitable for bulk duplicate cleanup.

Reference:
Salesforce Help: Find and Merge Duplicate Contacts with NPSP. This resource clearly outlines the use of the NPSP Contact Merge tool as the standard practice for managing duplicates in NPSP.

Explanation:
The issue is a discrepancy between the configured rule (Close Date = 15th) and the actual system behavior (some Close Dates are at month-end). The root cause could be an error in the automated process that creates the Opportunities. The first diagnostic step is to investigate system logs for any failures or exceptions during the Recurring Donations (RD) batch job execution, as these could explain why some records did not follow the rule.

Correct Option:

B. Check the Error Log.
The Recurring Donations batch job runs to create installment Opportunities. If it encounters an error (e.g., a validation rule, missing required field) for specific RD records, those installments may fail to be created or may default to an incorrect value.

The Error Log (or Apex Exception Email) will capture any errors thrown during this batch process, providing the exact reason why some Opportunities ended up with an unexpected month-end Close Date instead of the 15th.

Incorrect Option:

A. Check the Recurring Donation batch size.
Batch size affects processing performance but does not alter business logic like the Close Date calculation. An incorrectly sized batch would not selectively cause some Opportunities to have the wrong date; it would cause general slowness or timeout errors.

C. Check if the "Always use last day of the month" field is selected.
This is a red herring. This field is located on the Opportunity object level, not on the Recurring Donation settings. It is a legacy field that, if checked on an individual Opportunity, would force its Close Date to month-end, but it would not be the cause of a systematic issue for multiple new RD-generated Opportunities.

D. Check if the Custom Installment record was modified.
This is not a standard troubleshooting step. "Custom Installment" is not a standard NPSP object or common configuration. Modifications to underlying records would be an extreme edge case, whereas checking system logs for errors is the standard first step for automated process failures.

Reference:
NPSP Documentation on Troubleshooting Recurring Donations. Standard guidance for when RD behavior does not match expectations is to first review scheduled job status and error logs to identify processing failures that prevented the correct application of business rules.

Explanation:
When using NPSP Data Import for Contacts, the system can automatically create associated Household Accounts. If this fails despite correct mappings, the issue is typically that the system cannot create the required parent Account record. This failure is almost always due to missing data required by either the import process itself or by validation rules on the Account object that must be satisfied upon record creation.

Correct Options:

C. If the required fields are included in the import.
The Data Import object itself has required fields. For a Contact import, the Contact1_Firstname and Contact1_Lastname fields are mandatory. If these are missing for a given row, the entire import for that row will fail, preventing both the Contact and the automatic Account creation.

D. If there are required fields on the Account.
If the Account object has validation rules or system-required fields (beyond Name) that are not populated by the Data Import process, the automatic Account creation will fail.

The import process automatically sets the new Account's Name using the Household Naming convention, but if another field is required (e.g., a custom Region__c field), the process cannot provide a value and will fail to create the Account.
Incorrect Options:

A. If all the email addresses are properly formatted.
While important for data quality, an improperly formatted email address on a Contact is unlikely to prevent the Account from being created. The Account creation is a separate DML operation. Validation rules on the Contact might fail, but the core issue described is specifically about Account creation.

B. If all records have a phone number.
A phone number is not a system-required field for Contact or Account records in a standard NPSP configuration. Its absence should not block the automatic creation of an Account during a Data Import.

Reference:
NPSP Documentation on Using the Data Import Tool. It specifies that imports will fail if required fields on the target object are not mapped or populated, and highlights that validation rules on the target objects (like Account) are executed during the import process and can cause failures.

Explanation:
The goal is to have data entered once and automatically appear on both the related Opportunity and its Payment record. In NPSP, Payments are separate objects with a lookup to Opportunity. To synchronize custom data between them, you must use the NPSP Payment Mapping feature. This allows you to define which custom fields on the Opportunity should automatically copy to specific custom fields on the Payment when a Payment is created.

Correct Options:

A. Create Payment Mappings in NPSP Settings.
This is the essential configuration step. In NPSP Settings > Payments, you can define Payment Mappings. These mappings explicitly link a custom field on the Opportunity object to a custom field on the Payment object (e.g., Opportunity.Custom_Check_Number__c → npe01__Payment__c.Custom_Check_Number__c).

Once mapped, any value in the designated Opportunity field is automatically copied to its corresponding Payment field when the Payment is created.

B. Create custom fields on the Payment object.
This is a prerequisite. Before you can map anything, the target custom field must exist on the Payment object (npe01__OppPayment__c). You create this custom field to hold the data you want to synchronize from the Opportunity (e.g., Check_Number__c).

Incorrect Options:

C. Create lookup fields on the Payment object.
Lookup fields create relationships to other objects, they do not automatically copy data values from one field to another. The standard lookup from Payment to Opportunity already exists. An additional lookup would not solve the data duplication problem.

D. Create a workflow that will copy Payment information to the Opportunity record
This is backwards and inefficient. The requirement is to avoid entering data twice. A workflow copying from Payment to Opportunity would still require the user to enter the data on the Payment first. More importantly, the native Payment Mappings feature (Option A) is the designed, no-code solution for this exact purpose, making a custom workflow rule unnecessary.

Reference:
NPSP Documentation on Payment Mappings. This feature is specifically documented as the method to "automatically copy values from specified fields on an opportunity to the related payment record when the payment is created," eliminating manual data entry.

Explanation:
The dedicated feature in NPSP for tracking specific funds, programs, or restricted revenue that often maps to a non-profit's chart of accounts is the General Accounting Unit (GAU) and its related object, the GAU Allocation. This structure allows a single Opportunity (Gift) to be split by specific dollar amounts or percentages across multiple funds. The GAU Allocation records hold the amount for each fund, enabling accurate reporting on totals by fund for reconciliation with the finance system, which directly addresses the requirement.

Correct Option:

B. Create General Accounting Unit records for each of the funds, and associate them with the Opportunity by GAU Allocation record amounts representing the amounts towards each fund.
General Accounting Unit (GAU): This custom object is designed to represent the specific funds, programs, or accounting codes (like "Scholarship Fund" or "Building Maintenance").

GAU Allocation: This custom junction object links a single Opportunity (the total gift amount) to one or more GAUs. It records the specific dollar amount or percentage of the gift allocated to that GAU.

This native NPSP feature is the official and supported best practice for complex fund tracking and finance system reconciliation.

Incorrect Option:

A. Create Campaign records for each of the funds, create a custom Lookup to Campaigns on the Payment Object, and associate them with Payment records representing the amounts towards each fund.
Campaigns track how the gift was raised (the marketing effort), not how the funds are allocated. Customizing the Payment object to track funds is non-standard and bypasses NPSP's built-in GAU Allocation functionality, creating technical debt and breaking standard NPSP rollups.

C. Create a custom multi-select picklist on the Opportunity record to allow for choosing each of the funds towards which the gift is designated.
A multi-select picklist cannot track the specific amount allocated to each fund, only that the gift was designated to multiple funds. This fails the requirement to report on totals by fund for reconciliation.

D. Create Campaign records for each of the funds, and associate them with the Opportunity Primary Campaign field on the Opportunity records representing the amounts.
Again, Campaigns track the source/marketing effort, not the designated fund allocation. The Primary Campaign field only allows one campaign per opportunity and cannot split the gift amount across multiple funds, thus failing to meet the core requirement.

Reference:
Salesforce Help: Donation Allocations Overview and Create General Accounting Units (GAUs).

Explanation:
NPSP provides built-in acknowledgment tracking to help nonprofits verify whether donors have been thanked for their contributions. This tracking is stored directly on the Opportunity, since acknowledgments are tied to specific donations rather than Contacts or Campaigns. Gift officers can view the Acknowledgment Status field on the Opportunity to see whether a thank-you letter has been created, queued, or sent, making it the most reliable source of truth for donation acknowledgment history.

Correct Option:

C. Check the Acknowledgement Status picklist value on the Opportunity object.
This is the correct method because acknowledgments are tracked at the donation (Opportunity) level in NPSP. The Acknowledgment Status picklist reflects whether a letter has been generated, mailed, or is pending. It is automatically updated when acknowledgment processes or letter templates in NPSP are used, providing the clearest indicator for gift officers.

Incorrect Options:

A. Check the Status picklist value on the Task object.
Tasks may be used to remind staff to send acknowledgments, but they do not represent the official acknowledgment status. Task completion does not reliably indicate that a letter was generated or sent through NPSP’s acknowledgment workflows.

B. Check if the Campaign Member status is set to "Acknowledged".
Campaign Member statuses reflect engagement with marketing or fundraising campaigns, such as event attendance or email actions. They do not track donation acknowledgments and are unrelated to NPSP’s acknowledgment system.

D. Check the Acknowledgement Status picklist value on the Contact object.
Acknowledgments are tied to specific gifts, not individuals. A Contact may have multiple donations with different acknowledgment statuses, so tracking acknowledgment at the Contact level is not supported or accurate.

Reference:
Salesforce NPSP Documentation — Acknowledgments

Explanation:
The requirement involves personalized, behavior-triggered email automation based on a schedule (30/60/90 days) and member engagement data (website visits). This requires a sophisticated marketing automation tool that can track anonymous web behavior, score engagement, segment contacts, and trigger personalized email journeys based on both timeline and behavior. Core Salesforce automation tools are not designed for tracking external web behavior or complex multi-wave, personalized email campaigns.

Correct Option:

D. Pardot (now Marketing Cloud Account Engagement)
Pardot is Salesforce's B2B marketing automation platform designed for exactly this use case. It can track website visits (via tracking code), assign engagement scores, and segment members into lists based on this behavior.

It features Engagement Studio programs where you can build automated, multi-step email journeys (like 30/60/90 day renewal sequences) that can use dynamic list criteria (e.g., "visited renewal page in last 7 days") to send different email templates to different segments, all within a single automated program.

Incorrect Option:

A. Process Builder / C. Time-Based Workflow
These are core Salesforce automation tools that work on internal record data. They cannot track external website visits natively. While they could send timed emails based on a date field (like membership expiration), they lack the ability to dynamically change the template based on real-time web behavior without extremely complex and fragile custom configuration.

B. Apex Trigger and Scheduler
This is custom code and is unnecessarily complex and expensive. While an Apex Scheduler could handle the timed aspect, the system would still lack the native ability to track and evaluate website visit data to decide which template to send. Replicating marketing automation functionality in code is not a best-practice recommendation when a dedicated, integrated tool exists.

Reference:
Salesforce Marketing Cloud Account Engagement (Pardot) product documentation. For use cases involving lead nurturing, behavioral scoring, and personalized email journeys based on both schedules and prospect activity (like web visits), Pardot is the prescribed Salesforce solution over native automation tools.