Master Salesforce NP-Con-102: Nonprofit Cloud Consultant Exam Prep

Correct : A

Salesforce Nonprofit Cloud for Fundraising is organized into several distinct Lightning Apps, each tailored to a specific fundraising persona or business process. For consultants, understanding which app supports which business function is essential for user enablement.

Donor Engagement: This app is the hub for mass-market fundraising. It is designed for team members who manage large-scale outreach, direct mail, digital campaigns, and high-volume donor acquisition. It includes features for Campaign Management, Source Codes, and segmenting large lists of donors for automated outreach. This app focuses on 'one-to-many' relationships where the goal is efficiency and broad engagement.

Philanthropy & Partnerships: In contrast, this app is designed for 'high-touch' or major gift fundraising. It focuses on 'one-to-one' relationship management, tracking major donors, foundation partners, and corporate sponsors. It highlights tools like the Donor Profile, Wealth Screening data, and moves management stages.

Fundraising Strategy: This app (and its associated dashboards) is intended for leadership and data analysts. It provides high-level insights into fundraising performance, RFM (Recency, Frequency, Monetary) scoring trends, and overall revenue health, rather than day-to-day campaign execution.

By assigning the Donor Engagement app to the marketing and direct response teams, a consultant ensures they have immediate access to the Campaigns, Outreach Source Codes, and segments they need to run mass-market appeals effectively without being distracted by the specialized major gift tools found in the Philanthropy app.

Correct : B

Automatic Person Account Mailing Address Synchronization is a powerful feature in Nonprofit Cloud that ensures the standard mailing address fields on the Person Account stay perfectly in sync with the Contact Point Address related records.

In this model, the Person Account's 'Mailing Address' fields (Street, City, State, etc.) are essentially a 'mirrored reflection' of whichever Contact Point Address record is marked as Is Primary.

The Synchronization Logic:

Setting a Primary: When a user checks the IsPrimary box on a Contact Point Address, the system automatically copies that data into the Person Account's standard mailing fields.

Removing the Flag: If a staff member unchecks the IsPrimary flag, the 'bridge' between that specific address record and the Account fields is broken. Because there is no longer a designated primary address for that account, Salesforce clears the standard Mailing Address fields on the Person Account to prevent outdated or incorrect information from remaining in the primary display.

Data Retention: It is important to note that the Contact Point Address record itself is not deleted or archived. It remains in the related list; it simply loses its 'Primary' status and is no longer pushed to the main Account header.

Why other options are incorrect:

Option A and C: The system does not automatically set an end date or mark the record as 'Inactive' simply because the primary flag was removed. The record remains 'Active' but secondary. It is up to the user to manually mark it as inactive or undeliverable if that is the case.

For a consultant, this behavior is a critical consideration for data hygiene. If an organization requires that every donor always has a mailing address, the consultant must ensure users understand that unchecking IsPrimary will leave the main Account record with a blank address until a new primary is selected.

Correct : A

When processing checks for recurring gifts in the Nonprofit Cloud, the system attempts to find an 'expected' payment record to match against the physical check. In the NPC data model, recurring gifts are managed via Gift Commitments and Gift Commitment Schedules.

The system creates 'expected' transactions (installments) based on the schedule. However, donors often send checks that arrive slightly before or after the exact scheduled date. If a check arrives outside of the system's 'window of expectation,' the Gift Entry interface will not automatically suggest the matching commitment, leading to the 'no matching records appear' issue.

The Solution: Installment Extension Day Count

Function: This setting defines the number of days beyond the scheduled date that the system will look to find a matching installment. For example, if a gift is scheduled for the 1st of the month but the check arrives on the 10th, and the extension is set to 5 days, the system won't see it.

Configuration: The consultant must go to Fundraising Settings in the Setup menu.

Adjusting the Value: By increasing the Installment Extension Day Count (e.g., to 14 or 30 days), the consultant widens the 'search window.'

Result: The next time the manager enters a check for that donor, the Gift Entry tool will successfully find and display the active Gift Commitment as a suggested match because the check's date now falls within the extended installment window.

Option C is incorrect because 'Donor Matching' helps find the person, but the question specifies that the issue is matching the check to a specific Gift Commitment (the recurring gift record). Option B (RFM scoring) is for analytics and has no impact on the technical matching logic of the gift entry engine.

Correct : C

The Case Plan Wizard in Nonprofit Cloud Case Management is a tool that allows caseworkers to quickly build a customized care plan for a participant. To make this 'wizard' efficient and automated, the underlying 'templates' must be set up beforehand.

Required Pre-configuration:

To 'assign a group of services' effectively through the wizard, the consultant must ensure that the Program record is populated with:

Goals: These are the objectives the client wants to reach. In the wizard, the caseworker can select from these pre-defined goals rather than typing them from scratch.

Action Item Templates: These are the specific tasks or 'steps' required to reach a goal. By creating Action Item Templates and linking them to a Goal within a Program, the consultant enables the 'grouping' logic. When a caseworker selects a Goal in the wizard, the associated Action Items automatically appear as suggested tasks.

Workflow for the Consultant:

Navigate to the Program record.

Use the Goals related list to create standard goals for that program.

Use the Action Item Templates related list to define the repeatable steps for those goals.

Ensure the Case Plan Wizard component is added to the Contact or Case record page.

Why other options are insufficient:

Option A and B: If you only have Goals or only have Action Items, the wizard loses its primary value of providing a 'ready-made' plan for the caseworker.

Option D: A 'New Case Plan' is the result of using the wizard, not a prerequisite for the wizard's configuration.

Correct : C

In NPSP, aggregating data from child Opportunity records to the parent Contact or Account record is handled by the Rollup engine. While there are several ways to do this in Salesforce, Customizable Rollups are the standard NPSP tool for this requirement.

Why Customizable Rollups (C) are the best fit:

Cross-Object Support: Standard Roll-up Summary fields (Option B) only work if there is a Master-Detail relationship. Because the relationship between Opportunities and Contacts in NPSP is technically a Lookup relationship (managed through Opportunity Contact Roles), standard roll-ups cannot be used.

Logic and Filtering: Customizable Rollups allow the consultant to define specific 'Filter Groups.' For example, you can set the rollup to only look at 'Closed/Won' donations and ignore 'In-Kind' gifts.

Operation Types: To get the 'most recent' date, the consultant sets the rollup operation to MAX. The system will look at all qualifying Opportunities, find the one with the latest (highest) date, and write that date to the target field on the Contact.

Automation: Every time a new Opportunity is added or updated, NPSP's nightly batch (or real-time triggers) will re-calculate the value. If a new gift arrives with a more recent date, the old value on the Contact will be overwritten automatically.

Formula fields (Option A) cannot be used because they can only pull data up from a parent to a child, not aggregate multiple child records into a single parent field.