Explanation:
Accounting Subledger acts as an accounting engine within Salesforce, creating Ledger Entries from transactions (Opportunities, Payments). To get this data out to an external General Ledger (GL), you need an export or integration method. The available options range from manual exports to automated middleware or custom APIs.

Correct Options:

A. Integrate Salesforce with the accounting system using middleware.
Middleware (like MuleSoft, Workato, Celigo) can automate the extraction of Ledger Entries from Salesforce and push them to the accounting system's API, enabling real-time or batched sync. This is a common, scalable approach.

B. Export data via Salesforce reports to upload to the accounting system.
You can create custom reports on the Ledger Entry object and export them to CSV for manual or scripted upload into the accounting system. This is a manual or semi-automated method suitable for smaller volumes.

C. Develop a custom integration solution.
Building a custom Apex REST/SOAP API or using Outbound Messaging to send Ledger Entry data directly to the accounting system's API is a valid, though more technical, method. This offers full control over the integration logic.

Incorrect Options:

D. Schedule a Data Export from Salesforce.
The Weekly Data Export service exports backup files of standard/custom objects in CSV format. It is not designed for transactional integration with accounting systems, as it lacks real-time capabilities, does not target specific objects like Ledger Entries by default, and includes all data, requiring extensive filtering. It's a backup tool, not an integration method.

E. Configure Salesforce Connect to integrate with the accounting system.
Salesforce Connect is for real-time read-only access to external data sources (displaying external data inside Salesforce). It is not for pushing data from Salesforce to an external system. The direction is wrong for this requirement.

Reference:
Accounting Subledger documentation: "Exporting Data to Your General Ledger." It typically lists options such as:

Middleware/ETL integration (A),

Custom API development (C),

Report-based CSV export (B).
These are the standard patterns for moving ledger data to an external GL.

Explanation:
The fundraiser needs a way to easily track and update her gift asks (solicitations). In Salesforce, a "gift ask" is typically represented by an Opportunity record, and the stages of the ask (e.g., Prospecting, Cultivation, Pledged) are tracked via the Opportunity Stage field.

The Kanban View is a standard Salesforce feature that visually displays records (like Opportunities) as cards organized by a picklist field (like Stage). The fundraiser can easily:

Track: See all her asks grouped by their current stage (e.g., "Cultivation" or "Commitment").

Update: Drag-and-drop the Opportunity cards from one stage column to the next (e.g., from "Cultivation" to "Pledged") to instantly update the gift ask status, making it the most efficient solution for this requirement.

Why the Other Options Are Incorrect:

B. Einstein for Nonprofits
Einstein is an AI solution for predictive analytics (e.g., predicting donor propensity to give). It helps prioritize which ask to make, but it is not a user interface tool for managing and updating the gift ask pipeline.

C. Manage Campaign Members
Campaign Members track the response of Contacts to a marketing effort (e.g., "Responded" to an appeal). While the ask might originate from a Campaign, this feature is for group-level response management, not for individual management and visual progression of a gift ask pipeline

D. Path
Path is a visual component that appears at the top of a record detail page (like an Opportunity). It provides guidance and key fields for the user as they progress through the stages. While helpful, it only updates one record at a time. It is not a visual pipeline management tool that allows the fundraiser to view and update all of her asks simultaneously, which is what the Kanban View (A) provides.

Explanation:
The NPSP Membership feature uses a specific Opportunity Record Type to identify membership transactions. To enable automatic roll-up summaries (like "Last Membership Date," "Last Membership Amount," etc.) on the Contact/Account, you must correctly configure the membership settings in NPSP. This involves specifying which record type signifies a membership and optionally setting a grace period for renewals.

Correct Options:

B. Select the membership record type for membership rollups.
In NPSP Settings > Donations > Membership Settings, you must specify the Opportunity Record Type that designates a membership transaction. The roll-up engine uses this to identify which Opportunities to include in membership-specific calculations and roll-up fields.

D. Set a grace period for memberships.
The grace period (also configured in Membership Settings) defines how many days after a membership expires before a Contact is considered "lapsed." This affects the "Membership End Date" roll-up logic and membership status calculations, ensuring accurate reporting on active vs. lapsed members.

Incorrect Options:

A. Create a custom field for Membership Amount and select it for membership rollups.
Incorrect. The membership amount is taken directly from the Opportunity Amount field of membership-typed Opportunities. You do not need a separate custom field; the system uses the standard Amount field.

C. Create an Opportunity record type for memberships.
While you do need a dedicated Opportunity Record Type for memberships, this is a prerequisite step before you can complete the configuration in option B. However, the question asks for items the consultant needs to configure so the rollups work. The critical configuration is selecting that record type in NPSP Membership Settings (Option B), not just creating the record type itself.

Reference:
NPSP Documentation: "Configure Membership Settings." This outlines the steps:

Create an Opportunity Record Type for Memberships.

In NPSP Settings, select this record type as the Membership Record Type.

Optionally, set a Grace Period.
These settings enable the built-in membership roll-up fields and status calculations.

Explanation:
The integration works in sandbox but hits API limits in production. This discrepancy typically occurs because the sandbox environment had certain automation (like NPSP triggers) disabled, reducing the number of API calls or processing time per transaction. In production, with all automation active, each API call from the integration triggers additional internal calls (due to triggers, workflows, etc.), pushing the total over the limit. The limits themselves are the same per license type, but the workload per call differs.

Correct Option:

C. The triggers associated with NPSP were disabled in the sandbox environment.
If NPSP Trigger Handlers (e.g., for addresses, rollups, household naming) were inactive in the sandbox during testing, each integrated record required fewer processing steps and API calls. In production, with triggers enabled, each record update fires multiple triggers, consuming more API calls and causing limit exceptions. This is a common oversight in integration testing.

Incorrect Options:

A. Testing of the integration in the sandbox environment was insufficient.
While insufficient testing is a general risk, it's not the specific explanation for API limit errors appearing only in production. The testing may have been adequate for functionality but did not account for the different automation states between environments.

B. The incorrect sandbox environment was used for testing.
Using a different type of sandbox (e.g., Developer vs. Full Copy) could affect data volume but not the API call limits themselves. All sandboxes and production share the same API limits per license. The issue is the workload per call, not the sandbox type.

D. The API call limits were different for sandbox and production environments.
False. Salesforce API call limits are the same for sandbox and production environments of the same edition. A sandbox is a copy of production metadata and has identical governor limits. The difference lies in data volume, enabled automation, and concurrent usage, not the limits themselves.

Reference:
Salesforce Integration Best Practices and NPSP Implementation Guides warn that testing integrations must be done in an environment with identical automation (triggers, processes) enabled to accurately gauge API consumption. Disabled triggers in sandbox are a frequent cause of production limit surprises.

Explanation:
The nonprofit wants its staff to access other external applications without leaving the Salesforce interface. This embedding of external applications directly within Salesforce tabs, pages, or Lightning components is the primary use case for Salesforce Canvas.

Correct Option: A

A. Implement Salesforce Canvas
Rationale: Salesforce Canvas is a framework that allows third-party applications (often called "Canvas Apps") to be securely embedded into the Salesforce user interface using an iframe or similar technology.

User Experience: This creates a seamless experience where the staff can interact with the external application (like a proprietary finance system, a custom portal, or a specialized scheduling tool) while still navigating and remaining inside the main Salesforce environment, directly fulfilling the requirement.

Incorrect Option:

B. Configure External Data Sources
Rationale: External Data Sources (used with Salesforce Connect) are for integrating data from external systems (like SAP or an external database) so that the data can be viewed and reported on in Salesforce via External Objects (C). They do not embed the entire external application's user interface.

C. Configure External Objects
Rationale: External Objects are the virtual representations of the external data. They are designed to let users view, search, and report on the data residing outside Salesforce. They do not embed the actual external application's interface for staff to interact with the application's functionality.

D. Implement Distributed Marketing
Rationale: Distributed Marketing is a feature within Marketing Cloud that allows corporate or national marketing teams to create branded content that local users (like affiliates or program staff) can personalize and send directly from within Salesforce. It is a marketing solution, entirely unrelated to embedding third-party application interfaces.

Reference:
Salesforce Canvas Developer Guide (Focus on embedding external applications and user interfaces).