Explanation:
Engagement Plan Templates in NPSP are used to generate a series of Tasks for Campaigns or Contacts. The key behavior is that once an Engagement Plan is created from a Template, it becomes a snapshot copy of the tasks at that point in time. The Template and the generated Plan are not dynamically linked after creation.

Correct Option:

B. Changes to Engagement Plan Templates only affect new Engagement Plans.
This is the defined functionality. When a user creates an Engagement Plan and selects a Template, the system copies the task definitions (subject, status, due date offset, etc.) from the Template into the new Engagement Plan record. Subsequent edits to the source Template do NOT retroactively update any Engagement Plans already created from it. The changes will only apply to new Engagement Plans created after the Template is updated.

Incorrect Options:

A. The development manager requires additional permissions for the new Engagement Plan Template changes.
Permissions control access to view or edit records, not the propagation of template changes. If the manager could see the Engagement Plan before, they can still see it. The issue is that the data in the existing Plan hasn't changed, not that their view is blocked.

C. Engagement Plan Template changes need to propagate through the platform.
There is no "propagation" process for existing Plans. The relationship is not dynamic. This statement implies a delayed sync that does not exist in the product's design.

D. Engagement Plan Template changes must be accepted by the user on the Template detail record first.
There is no acceptance or approval workflow for Template changes. Edits to a Template are saved immediately and are effective for new Plans. There is no user prompt or acceptance step required on existing records.

Reference:
NPSP Documentation: "Engagement Plans." The guide specifies that "Changes you make to a template don’t affect engagement plans you’ve already created from it." This is a key design point to understand when managing Engagement Plans. To update an existing Plan, you must manually edit the Plan's tasks or create a new Plan from the updated Template.

Explanation:
The Nonprofit Success Pack (NPSP) extends the standard Salesforce Opportunity object to include specific fields for managing grants. To track a renewal grant and maintain an easy link to its history, the organization should use the standard NPSP Grant fields on the new (renewal) Opportunity record. Specifically, the "Previous Grant/Gift Opportunity" lookup field is designed to link the new grant to the original grant, and the "Is Grant Renewal" checkbox provides a simple flag for reporting and process automation.

Correct Option:

C. Fill in the "Previous Grant/Gift Opportunity" lookup field on the Opportunity for the new grant and check the "Is Grant Renewal" field.
NPSP provides the Previous Grant/Gift Opportunity lookup field on the Opportunity object (often used with the Grant record type). This field creates a direct, parent-child-like relationship, linking the current renewal Opportunity back to the original funding Opportunity.

The Is Grant Renewal checkbox is a simple, standard NPSP field that provides a clear flag for reporting purposes, allowing the organization to easily filter or group all renewal grants.

This combination is the standard NPSP feature for tracking grant renewal history.

Incorrect Option:

A. Create a Campaign for the funder and add all Opportunities including the original grant and any renewal grants to the Campaign.
While Campaigns can group related grants, they are designed for tracking marketing efforts, not creating a clear, programmatic link between a parent grant and its specific renewal. It would make accessing the previous grant information difficult without cross-referencing reports.

B. Create a child Opportunity for the renewal grant from the original grant using the Renewal Grant Opportunity record type.
Creating a child Opportunity is technically possible, but it is not the required NPSP best practice. NPSP provides the dedicated lookup field (Previous Grant/Gift Opportunity) on the standard Opportunity object precisely for this purpose, eliminating the need to customize with a separate "Renewal Grant" record type or master-detail relationships.

D. Ensure that when naming the Opportunity for the renewal grant, "Renewal" is included in the name as well as the name of the funder.
Naming conventions are helpful for identification, but they are a manual and non-relational tracking method. They do not create an actionable data link or relationship between the two Opportunity records, which is crucial for easy access and reporting on the grant history.

Reference:
Salesforce Help: Manage Grantseeking Opportunities and the corresponding sections on Opportunity fields in NPSP, which specifically list and describe the purpose of the Previous Grant/Gift Opportunity lookup field and the Is Grant Renewal checkbox.

Explanation:
The requirement is to conditionally display the Engagement Plans related list on the Opportunity page based on the Opportunity's Amount field. This is a dynamic visibility requirement tied to a specific field value on the record. The solution must use Salesforce's Lightning App Builder capabilities to show/hide a component based on a filter rule.

Correct Option:
A. Add the Related List - Single Lightning component to the Opportunity Lightning page. Add a component visibility filter to display the Engagement Plan when the Opportunity Amount field is greater than 10,000.
This is the correct, declarative approach. In Lightning App Builder:

Add the "Related List - Single" component to the page.

Configure it to show the Engagement Plans related list.

Set a Component Visibility Filter rule: "Show component only when Opportunity Amount is greater than 10,000."

This meets the requirement precisely.

Incorrect Options:

B. Create a tab and associate the Engagement Plan object to the tab... Give read access for the Engagement Plan object to all profiles.
This makes Engagement Plans globally accessible via a tab, not conditionally visible on the Opportunity page. It also does not restrict visibility based on the Opportunity Amount. Object-level read access would allow users to see all Engagement Plans, violating the requirement.

C. Create a custom Lightning component that displays all Engagement Plans...
Building a custom component is unnecessary over-engineering. The standard "Related List - Single" component already exists and can be filtered declaratively. This option adds development cost and maintenance overhead for no benefit.

D. Add the Related Lists component... Set the component visibility filter... Assign the page to the development director's profile.
The "Related Lists" component shows all related lists for the object, not a specific one like Engagement Plans. More critically, assigning the page only to the director's profile would prevent other users from seeing it at all, whereas the requirement is for all users to see it conditionally.

Reference:
Salesforce Lightning App Builder Help: "Control Component Visibility." This feature allows components to be shown or hidden based on record field values, user attributes, or permissions. Using a visibility filter on the Related List - Single component is the standard method for conditionally displaying a specific related list.

Explanation:
When a custom Opportunity naming formula is created or changed in NPSP, it applies only to newly created Opportunities. It does not automatically update the Name field of existing records. To apply the new naming convention to historical Opportunities, a bulk update action is required. NPSP provides specific tools for this purpose.

Correct Options:

B. The organization should only change existing Opportunities to the new naming convention by using the "Refresh Name" action.
This is the manual, single-record method. On an individual Opportunity record page, users can click the Refresh Name button in the Highlights Panel to recalculate and update its name using the current naming formula. This is suitable for one-off updates.

C. The organization should change existing Opportunities to the new naming convention by using the "Refresh All Opportunity Names" button in Bulk Data Processes.
This is the bulk, administrative method. Under the Bulk Data Processes tab in NPSP, an administrator can use the "Refresh All Opportunity Names" process to recalculate and update the names of all existing Opportunities in bulk, applying the new custom naming formula. This is the efficient way to update historical data.

Incorrect Options:

A. The organization should change existing Opportunities to the new naming convention through an upsert.
Upsert is a data import/update operation using the Data Loader or API. While technically possible, it is not the recommended or supported NPSP method. It would require manually calculating the new name for every record in an external file, which is error-prone and inefficient compared to using the built-in tools that automatically apply the formula.

D. The custom naming convention only applies to new Opportunities of matching record types; it is not retroactive.
This statement is only partially true. It is correct that the convention is not automatically retroactive. However, the implication that it cannot be applied retroactively is false. The purpose of the "Refresh Name" and "Refresh All Opportunity Names" tools (Options B & C) is specifically to make the convention retroactive for existing records.

Reference:
NPSP Documentation on Customizing Opportunity Names. The documentation clearly states that after creating a new naming formula, you must use the "Refresh All Opportunity Names" bulk process or the individual "Refresh Name" button to update existing records.

Explanation:
The core requirement is to install the Nonprofit Success Pack (NPSP) into an existing Salesforce organization. NPSP is delivered as a set of managed packages. The recommended, easiest, and most reliable method to ensure all dependencies are installed correctly and in the right sequence is by using the official NPSP Installer. This tool simplifies the process significantly, preventing common errors that could arise from manually installing the individual components.

Correct Option: A

A. Install from the NPSP Installer page.
The NPSP Installer page is the official, specialized web tool provided by Salesforce.org that streamlines the installation of the core NPSP package along with all its necessary dependent packages (like recurring donations, households, etc.).
This single-step process is the best practice for a consultant to ensure a complete and correct installation in an existing organization, automatically handling the dependencies and sequence.

After installation, the consultant must proceed with the post-install instructions within NPSP Settings to finalize configuration.

Incorrect Option:

B. Install using the NPSP Conversion Utility tool.
The NPSP Conversion Utility is a tool used after NPSP is installed. Its purpose is to help organizations that were using an older data model (like the 1-to-1 Account Model) convert their existing data to the recommended NPSP Household Account Model. It is a data migration tool, not an installation tool.

C. Install each NPSP component from the AppExchange.
While the NPSP components are listed on the AppExchange, installing them individually is discouraged. This manual method is error-prone, as the consultant must know the correct installation order and dependencies, which the NPSP Installer (Option A) handles automatically.

D. Install each NPSP component from the Trailblazer Community.
The Trailblazer Community (including the Power of Us Hub) is the communication and documentation platform for NPSP users. It provides links to the installer (A) and documentation, but it does not host the installation files or provide the direct installation mechanism itsel

Reference:
Install NPSP in a New or Existing Org - Salesforce Help