Disclosure: I am on the CumulusCI team at Salesforce.org and am one of the release engineers working on the Nonprofit Success Pack.
The accepted answer on this question is/was correct but is now somewhat outdated.
The recommended route to install the Nonprofit Success Pack in a scratch org is via CumulusCI, which is the SFDX orchestration build tool we use to build the package. CumulusCI is free and open source.
CumulusCI automatically manages NPSP's install dependencies:
- The five underlying managed packages:
- Contacts & Organizations
- Recurring Donations
- Relationships
- Households
- Affiliations
- Creation of a default Opportunity Record Type
- Deployment of unpackaged Account Record Types
It selects the latest version of each managed package by inspecting the GitHub releases found in our open source repositories.
CumulusCI is designed to make it easy to build new projects that extend existing managed packages like NPSP. When you start a new project with cci project init
, the ensuing questionnaire will ask if you'd like to extend NPSP or EDA and automatically configure dependencies for you. This process is covered in the Trailhead module CumulusCI for Post-Install Customizations, which I co-wrote.
Manual Installation
If you choose not to use CumulusCI, you can still install NPSP in a scratch org by executing the above steps manually or in your own scripting.
Be aware that each biweekly release of NPSP is dependent upon the latest release of the five underlying packages, which are themselves released irregularly (but in SFDO's biweekly release cadence). Ensure that your scripting both
- Pins a specific set of managed package versions.
- Is regularly updated to the latest versions of the managed packages
or
- Automatically resolves the latest versions by inspecting the GitHub releases in our open source repositories.
Otherwise, you risk building your scratch orgs against increasingly outdated versions of NPSP that will not reflect what you see in production through our biweekly push upgrades.
To appropriately configure Record Types, script the creation of any Opportunity Record Type prior to installing NPSP, and deploy the content of the directory unpackaged/pre/account_record_types
from NPSP's repository.
Be aware that the repository structure is subject to change. NPSP's CumulusCI configuration is the source of truth for how to script an installation.
Ok, looks like I stand corrected
I'm not sure if I was doing something wrong, or that a minor improvement was made in CLI version sfdx-cli/7.144.2 - but I was able to push the permission-set metadata from the sandbox over to my scratch org just now...
DEPLOY PROGRESS | ████████████████████████████████████████ | 19/19 Components
Updating source tracking... done
=== Pushed Source
STATE FULL NAME TYPE PROJECT PATH
─────── ────────────────────────────────────── ───────────── ───────────────────────────────────────────────────────────────────────────────────────────────────
Created Create_Report_Dashboard_Folders PermissionSet field-svc\main\default\permissionsets\Create_Report_Dashboard_Folders.permissionset-meta.xml
Created Edit_Task PermissionSet field-svc\main\default\permissionsets\Edit_Task.permissionset-meta.xml
Created FSL_Admin_License PermissionSet field-svc\main\default\permissionsets\FSL_Admin_License.permissionset-meta.xml
Created FSL_Admin_Permissions PermissionSet field-svc\main\default\permissionsets\FSL_Admin_Permissions.permissionset-meta.xml
Created FSL_Agent_License PermissionSet field-svc\main\default\permissionsets\FSL_Agent_License.permissionset-meta.xml
Created FSL_Agent_Permissions PermissionSet field-svc\main\default\permissionsets\FSL_Agent_Permissions.permissionset-meta.xml
Created FSL_Bundle_License PermissionSet field-svc\main\default\permissionsets\FSL_Bundle_License.permissionset-meta.xml
Created FSL_Bundle_Permissions PermissionSet field-svc\main\default\permissionsets\FSL_Bundle_Permissions.permissionset-meta.xml
Created FSL_Community_Dispatcher_License PermissionSet field-svc\main\default\permissionsets\FSL_Community_Dispatcher_License.permissionset-meta.xml
Created FSL_Community_Dispatcher_Permissions PermissionSet field-svc\main\default\permissionsets\FSL_Community_Dispatcher_Permissions.permissionset-meta.xml
Created FSL_Community_Self_Service_Permissions PermissionSet field-svc\main\default\permissionsets\FSL_Community_Self_Service_Permissions.permissionset-meta.xml
Created FSL_Dispatcher_License PermissionSet field-svc\main\default\permissionsets\FSL_Dispatcher_License.permissionset-meta.xml
Created FSL_Dispatcher_Permissions PermissionSet field-svc\main\default\permissionsets\FSL_Dispatcher_Permissions.permissionset-meta.xml
Created FSL_Mobile_License PermissionSet field-svc\main\default\permissionsets\FSL_Mobile_License.permissionset-meta.xml
Created FSL_Resource_License PermissionSet field-svc\main\default\permissionsets\FSL_Resource_License.permissionset-meta.xml
Created FSL_Resource_Permissions PermissionSet field-svc\main\default\permissionsets\FSL_Resource_Permissions.permissionset-meta.xml
Created Field_Service_Crew_Management PermissionSet field-svc\main\default\permissionsets\Field_Service_Crew_Management.permissionset-meta.xml
I did have to do a minor touch-up to the FSL_Admin_Permissions.permissionset-meta.xml
, it was referencing a tab that I didn't have in my metadata
FSL_Admin_Permissions.permissionset-meta.xml (element I removed)
<tabSettings>
<tab>FSL__Master_Settings</tab>
<visibility>Visible</visibility>
</tabSettings>
While I know how to actually obtain an instance of the FSL__Master_Settings
custom tab metadata file, my scratch org complains if I push the tab over.. it thinks that I'm trying to create something in the FSL namespace... but if I remove this element, everything works as shown above
Best Answer
This should be possible with Second Generation Packaging. You can specify the dependencies of a package in the sfdx-project.json file.
In case you prefer to install the package in a script, you could do it like this: