Salesforce-Nonprofit-Success-Pack-Consultant Practice Test Questions

Explanation:
The requirement is to track educational affiliations—specifically, the high school a student attended and their college enrollment. While standard NPSP includes a basic Affiliations object, it is designed for general relationships (e.g., board membership). Tracking detailed educational history, enrollment status, and dates is a specialized use case that is a core function of the Higher Education Data Architecture (HEDA) package, which extends and formalizes the Affiliation model for academia.

Correct Option:

D. Install the Salesforce.org Higher Education Data Architecture (HEDA) managed package and use Affiliations.
HEDA is the industry-standard Salesforce solution for educational institutions. It provides an enhanced Affiliation object with specific fields for academic relationships, including Role (e.g., Student), Status (e.g., Current, Former), and dates (Start/End).

This allows the org to accurately model both the past affiliation with a high school (Status: Former) and the current enrollment at a college (Status: Current) on the same Contact record seamlessly.

Incorrect Option:

A. Use NPSP Affiliations objects to connect the Contact to the Account...
While the basic NPSP Affiliations object could technically store this data, it lacks the specialized fields, validation rules, and automated processes (like auto-creation of Affiliations from Course Enrollments) that HEDA provides. For a dedicated educational tracking need, HEDA is the recommended and more robust solution.

B. Turn on Field History Tracking for the Account lookup field on the Contact...
This is completely insufficient. A Contact can only have one Account lookup (typically their Household). It cannot simultaneously link to both a high school and a college. This method also fails to track status, roles, or historical data effectively.

C. Set up a Campaign for each high school and college...
Campaigns are for marketing engagements and outreach, not for modeling institutional affiliations or enrollment status. Using Campaign Member Status (e.g., Sent/Responded) to represent academic status is a major misapplication of the object and would not support proper reporting or relationship tracking.

Reference:
Salesforce.org Higher Education Data Architecture (HEDA) documentation. HEDA is explicitly designed to manage relationships between people (Contacts) and educational institutions (Accounts), including student enrollments, faculty appointments, and alumni status, making it the prescribed solution for this scenario.

Explanation:
The deletion of a default scheduled job, particularly one that handles critical background processes like error handling (like the NPSP 00 - Error Processing job), is a common administrative concern. Salesforce's Nonprofit Success Pack (NPSP) is designed to automatically reschedule or recreate its default batch jobs when an administrator simply navigates to the configuration area that governs those jobs. This is the simplest and most efficient recovery step, avoiding the complexity of manually scheduling Apex or contacting support.

Correct Option:

A. Go to NPSP Settings | Bulk Data Processes | Batch Process Settings to automatically recreate it.
NPSP's scheduled batch jobs (which handle background functions like rollups, error processing, and recurring donations) are recreated automatically when a System Administrator accesses the Batch Process Settings configuration page.

This action triggers a check for missing default jobs and reschedules them under the current user's security context, ensuring they run at the appropriate time and frequency.

Incorrect Option:

B. Go to the NPSP Data Imports | Bulk Data Processes | Batch Process Settings to automatically recreate it.
This path is incorrect. While the general feature is under "Bulk Data Processes," the main tab is NPSP Settings, not "NPSP Data Imports." Using the wrong navigation may not trigger the required automated job check.

C. Go to the Recycle Bin and undelete the job.
Scheduled Apex Jobs are not standard data records and are not stored in the Recycle Bin when deleted. They must be rescheduled, either manually or, preferably, through the NPSP automatic process.

D. Go to help and create a case amd ask Salesforce Support to reschedule this job.
While Salesforce Support could do this, it is not the recommended action for an NPSP consultant. The consultant should advise the administrator on using the built-in, no-code NPSP Settings functionality to resolve common administrative issues like this.

Reference:
Salesforce Help: Edit or Reschedule NPSP Scheduled Jobs.

Explanation:
For a large nonprofit functioning like a social enterprise, where interactions are primarily B2B (corporations, sponsors, vendors) and the organization does not accept individual donations, using NPSP-specific household models is unnecessary. The standard Salesforce Account Model without NPSP is ideal because it supports Leads, Opportunities, and complex business-to-business relationships without the additional donor-centric features of NPSP, which are designed for individual giving and households.

Correct Option:

E. Salesforce Account Model without NPSP
This model is best for B2B-focused nonprofits. It allows full use of Salesforce standard functionality such as Leads, Opportunities, and Accounts without the household and donation tracking layers in NPSP, which are irrelevant for corporate sponsorships or product sales. It keeps the org simple and aligned with business processes.

Incorrect Options:

A. Administrative Account Model in HEDA
HEDA (now Education Cloud) is tailored for educational institutions, not social enterprises. It focuses on student, staff, and educational management rather than corporate-focused Opportunity pipelines.

B. Household Account Model in NPSP
This model is optimized for individual donor management, where each household represents individual donors. Since this organization does not accept individual donations, it is unnecessary and overly complex.

C. Household Account Model without NPSP
A household model without NPSP removes some automation and features but still centers around individual donors and households, which is not relevant for a corporate-focused social enterprise.

D. Individual "Bucket" Account Model in NPSP
This model aggregates individuals into single accounts for reporting, still focusing on personal giving. It does not suit organizations primarily managing corporate relationships or B2B sales.

Reference:
Salesforce NPSP Account Model Overview

Explanation:
The question asks how to represent wealth scoring for donor cultivation within NPSP. Wealth scoring refers to assessing a prospect's capacity to give based on external assets, property, and philanthropic history, not just their past donations to your organization. NPSP's core functionality does not include external wealth data aggregation or scoring. This specialized need is typically met by integrated third-party services available on the AppExchange.

Correct Option:

D. Using an AppExchange application, collect and rank donor prospects' wealth information to understand how to best cultivate individual donations.
This is correct because wealth scoring requires external data (e.g., real estate holdings, stock portfolios, previous donations to other nonprofits) that is not natively stored or analyzed by NPSP.

Specialized AppExchange applications (like WealthEngine, iWave, or DonorSearch) are designed to connect to NPSP/Salesforce, append this external wealth and philanthropic data to Contact records, and provide propensity and capacity scores to guide cultivation strategies.

Incorrect Option:

A. Using an AppExchange application, collect and rank other nonprofits' wealth information...
Incorrect focus. Wealth scoring for individual donor cultivation is about assessing an individual's wealth, not the wealth or performance of other nonprofit organizations. This misinterprets the target of the analysis.

B. Report on the total amount of donations received by the nonprofit in the past year, and rank it against peer institutions...
This describes benchmarking organizational performance against peers. It is a useful metric for the organization's leadership but does not provide individual prospect wealth scoring for a major donor officer's cultivation work.

C. Report on the total amount of an individual's donations summarized on their Contact record and rank it against donations by other donors...
This describes donor loyalty/recency/frequency/monetary (RFM) analysis using internal historical gift data. While critical for stewardship, this is not wealth scoring. Wealth scoring assesses capacity based on external assets, whereas this option only analyzes past demonstrated affinity based on internal giving.

Reference:
NPSP and Salesforce for Nonprofits best practices guides on Prospect Research and AppExchange. They consistently reference that for wealth screening and capacity rating, nonprofits should evaluate and implement dedicated AppExchange applications that integrate external data sources with the Salesforce platform.

Explanation:
When manually importing data into Salesforce objects using a tool like the Data Loader, you must respect the object dependency hierarchy. An Affiliation record is a junction object that connects a Contact (the donor) and an Account (the employer/organization). Therefore, both the target Contact and Organization Account records must exist in Salesforce before you can insert the Affiliation record that links them. This ensures the lookup fields on the Affiliation object can be successfully populated with the corresponding Salesforce IDs.

Correct Option:

B. Insert Organization Accounts for the employer, insert Contact records for the donor, insert Affiliation records for the employment information
Step 1: Insert Organization Accounts The Account object must be created first to generate the Organization Account IDs for all employers.

Step 2: Insert Contact Records: The Contact records for the donors must be created second. NPSP automatically creates a Household Account for each donor Contact. You must export the Contact IDs generated from this step.

Step 3: Insert Affiliation Records: The final step is to insert the Affiliation records. This step maps the Contact IDs from Step 2 to the Organization Account IDs from Step 1, correctly establishing the employment relationship between the donor and the employer.

Incorrect Option:

A. Upsert Contact records, export Contact ID, upsert Organization Accounts for employer with Organization Account ID in the "Primary Affiliation" field
This is incorrect because you cannot populate the Primary Affiliation lookup field on the Contact object with the Account ID of the employer before the employer account exists. More importantly, manually updating the Primary Affiliation field on the Contact only sets the lookup; it does not create the necessary Affiliation record (the junction object) itself, which is the required step.

C. Insert Affiliation records, export Contact records, export Account records, upsert Contact records
This is incorrect because Affiliation records must be inserted last. They rely on the existence of both the Contact ID and the Organization Account ID, which are exported after the initial insertion of those parent objects.

D. Upsert Organization Accounts, export Organization Account ID, upsert Contact record with Organization Account ID in the "Primary Affiliation" field
This sequence sets up the Contact's primary affiliation lookup but bypasses the Affiliation object insertion, which is required to capture additional employment details (like Role, Status, and Start/End Dates). While setting the Primary Affiliation field on the Contact is part of the process, a separate insert into the junction object is required to fully capture the Affiliation details.

Reference:
Salesforce Help: NPSP Data Loader Introduction and Create an Affiliation with an Organization (documenting the steps and dependencies for the Affiliation object).

Explanation:
A V2MOM is Salesforce’s strategic planning framework that helps organizations define a clear direction and align execution with measurable results. It stands for Vision, Values, Methods, Obstacles, and Measures. Including Vision ensures a clear goal or desired outcome, while Metrics (Measures) track progress and success. Proper use of V2MOM ensures teams are aligned and accountable, making it easier to achieve organizational objectives.

Correct Option:

A. Vision
Vision defines the desired outcome or ultimate goal. It provides clarity and focus for the team, ensuring everyone understands what success looks like. Without a clear vision, strategic planning and execution can become misaligned.

D. Metrics
Metrics, also called Measures, specify how progress and success will be tracked. Including metrics ensures that objectives are measurable and that teams can monitor performance against defined goals. It promotes accountability and data-driven decision-making.

Incorrect Options:

B. Milestones
Milestones are not part of the official V2MOM framework. While milestones may help track progress in projects, V2MOM focuses on broader measures rather than specific timeline checkpoints.

C. Objectives
Objectives are implied within Methods and Measures but are not a standalone section in Salesforce’s recommended V2MOM structure.

E. Virtues
Virtues are not a formal part of V2MOM. While values or principles may guide behavior, the framework emphasizes Vision, Values, Methods, Obstacles, and Measures, not “Virtues.”

Reference:
Salesforce V2MOM Overview

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.