Your Institution Bought Salesforce, Now What?


Institutions often select Salesforce as the enterprise constituent relationship management (CRM) platform without consulting the development department. After the purchase, the development department may be left wondering what they do next.


Often, the next step is to consider whether to build or buy CRM customizations. Customizations increase efficiency. This is because they include tools overlaying the core database to create an ecosystem. If you have the correct integration tools, you can swap them out as new ones are developed or your organizational needs change.


And as you can imagine, there are many options.


Here’s what to consider as you decide whether to build or buy CRM customizations for Salesforce.


If you want to buy a CRM overlay …

Software vendors have created managed packages or overlays for the Salesforce platform that is specific to accommodate the process of philanthropy and engagement. Buying an overlay that fits your business practices can be beneficial because it is already built to accommodate.


Some examples of pre-built overlays are Affinaquest Relationship RM and Ascend by UC Innovation.


  • Affinaquest Relationship RM: Overlays Salesforce and helps your organization improve fundraising, build stronger relationships with constituents, and create a seamless donor experience.
  • Ascend by UC Innovation: Builds stronger relationships with constituents and provides a full-spectrum, integrated view of all advancement activities.


If you want to build a CRM overlay …

The build decision essentially leverages the Salesforce Nonprofit Success Pack (NPSP). The NPSP is preconfigured for nonprofits as easy-to-use fundraising and constituent management application designed to make your daily life a little easier.


Building custom overlays may not be feasible for smaller organizations. This type of practice is often reserved for larger philanthropy divisions to accommodate their complex business practices.


Single-org or Multi-org Architecture

Another big decision that an organization needs to consider after purchasing Salesforce is whether they will have a single- or multi-org architecture. Single-org architecture means using just one instance of Salesforce for your organization. While a multi-org architecture involves having more than one Salesforce instance.


A single org architecture is like “renting space” within a larger organization—like renting an office space within a commercial building. In this architecture type, there is more opportunity for sharing space and resources.


Single-org strategy uses one instance of Salesforce to serve your entire business. With this approach, you can standardize your business processes and create consistency in your organization’s use of Salesforce.


A single-org structure is beneficial if you need the same standards across your organization.


Other benefits of a Salesforce single-org architecture include scalability, leveraging integrations, ease of training, data management, and transparency (to name a few).


  • Scalability: Your global standards can be readily adopted in each new department.
  • Leverage integrations: Adding application integrations to Salesforce is easier when your team can roll out the same changes throughout your system.
  • Ease of training: Everyone can use the same Salesforce training, and you don’t need to maintain separate in-house training and guides.
  • Manage your data: Single-org strategies make it easier to manage data since you can apply the same data practices regardless of department or team. They also help prevent data duplication because all Salesforce users in your organization can see the same database.
  • Transparency: Your single-org architecture provides the same information, processes, and structure that the various business units within your company can access.


The downside is that a single-org architecture may not be the right fit for everyone. The more independent departments or business units are in your organization, the more likely you will need a multi-org architecture.


This is because a multi-org architecture is like having a dedicated space—like renting out an entire floor in a building—and sharing resources only as previously identified.


For example, some very large organizations have distinct businesses with different customer bases. A company with varying bases of the customer is unlikely to have much overlap in customer data.


A multi-org architecture needs a data integration plan to identify what you will “share”. You’ll also want to consider things like:


  • Stakeholders or departments: Including all those who may make the critical decisions about your Salesforce strategy.
  • Necessity of a multi-org architecture: Can you manage a multi-org setup appropriately?
  • Regulatory or security requirements: To stay compliant, what is necessary for your Salesforce use?
  • Cost: Is the overhead cost of a multi-org structure worth the investment?
  • Business goals: Do you need multiple orgs to achieve your business goals?


Customizing your Salesforce platform is likely necessary to make it work most efficiently for your organization’s needs. The decision may be difficult—but not impossible—due to the many variables and options. Salesforce is an ultra-adaptable platform. And whether you’re creating a new Salesforce customization or purchasing an existing overlay, it’s best to take everything into consideration.