A Case Study: Who Did We Help?
We were asked to help a Canadian nonprofit group (approx 80 employees) with their Account Model standardization. One important part of any Salesforce CRM implementation is the Account Model – which defines the way that people (contacts) link to companies (accounts) in the system. This relating of objects has its source in the “Business to Business” focus of the Salesforce product story. This Account Model can vary system to system (there are 3 primary models), and sometimes within the same system. Often an organization running their business on Salesforce will want (or need) to standardize this model across all their data/records. Optimally, the organization does this standardization pre-emptively, enabling better data quality and system usability, however, this effort is more typically a reaction to problems with applications and or integrations and sometimes simply required by new vendor products. This client had purchased an engagement platform app called StepUp which they were told required the newest account model; this requirement was the trigger event towards account model standardization, and thus begins our story. The client had also been warned (for some time) that the old model caused reporting to be slow and sometimes time out; more evidence that a standardization was a good idea.
This client’s Salesforce ORG (approx. 5 years old) had 800k+ contacts, 5 integrations, 27 packages, 58 triggers and many workflows. The ORG was a production instance sending a very large number of weekly emails via one of their integrations, so business continuity impact was a key concern.
Before We Get Going, A Bit More About NPSP
The Salesforce Nonprofit Success Pack (NPSP) is an open source set of managed packages for Salesforce, specifically oriented to help non-profit organizations track donors, clients, volunteers and others. It has been developed over many years and has a strong developer community dedicated to it. The NPSP has 3 account models that it supports: 1:1 accounts (each individual has one account: themselves,) the “bucket” account model, in which individuals are connected to a bucket, like “individuals.” The third, and optimum account model is the household model, where individuals are related to households.
How to Make This Model Standardization Successful
There are two ways to accomplish this account model shift. One option is an automated tool which will go through the data (just the data..) and make the account model change for you. Please review the web content for this tool very carefully, and heed the warning “The changes you make with the conversion utility are irreversible changes.”. The other option is to do the shift “manually,” by working through the necessary changes object by object. Open-Issue looked carefully at the risks involved in this process, and opted to do the manual process.
A Quick Note On Risks
Risks for this client meant that inbound lead generation and email acquisition, or outbound emails could stop. Additionally, more than 20 of their development and program folks would have had significant interruptions to their day-today work, not to mention the related potential for anxiety and panic! Given the number of integrations, users, packages and custom APEX, we opted for the manual route… its not just because we like difficult stuff you know…
First, the team needs to have a project manager who can not only keep the project on track, but also is able to communicate with many different stakeholders and vendors before the project even really starts (see more about risks below). Also, having both a data analyst and systems analyst on the team is critical – both sets of expertise is necessary for a project of this sort to succeed. When integrations are present, the interplay between Salesforce, NPSP package automation, the data model(s) and the integrated systems is much more complex and requires staged testing to completely mitigate potential for outages.
There are three places where an account model shift of this sort will have important implications. First, there are packages that the organization has installed. Some of those packages may, or may not be affected by the account model shift. Second, there are workflows and triggers, and again, some of these may or may not be affected. Last, but not at all least, are integrations that the Salesforce ORG has with other applications. In this case, the org was integrated with Marketo, WordPress, and Drupal, not to mention the new integration with the Percolator product waiting at the door..
- Detailed Workflow, Package and Integration Audit – Measurement of Complexity
The first thing Open-Issue took on was to measure the complexity of the project. We combine a set of assessment best-practices to obtain a “MOC” – or – Measure of Complexity, which considers all aspects of the effort including human factors, technology, roll-back plans, external events and constraints, and a combination of internal and ecosystem precedent. This project (on our scale of 1-5, 5=most complex) hit right around 3.2. Anything over 3 forces a higher level of prep/test. This initial assessment let us properly resource and manage timeline expectations for all parties involved.
The bulk of the project fell into two key areas of effort; first, the audits (packages, workflow, triggers, integrations) and second, coordination with Marketo technical staff on T5 cut-over sequence of events and integration sync planning. We always create a technical workbook ( We love Google Apps!) for our projects and have linked a redacted version of this project’s workbook here. A significant part of our consulting work over the years has met with an all-too-frequent dead end called “we don’t know”. This project, and this type of transition in general, will deliver you those responses – from vendors and from your own team; be ready, be brave!
- Detailed Sequence – What is Our Step By Step Process for this Org?
Any successful CRM (or really, technology project) will have a planned sequence of events. There are always some things you need to make sure you do before or after others. And documenting and reviewing closely two levels of sequences (Seq 1 = High level, Seq 2 = low level) is a critical step for this type of multi-variable, multi-vendor transition project. The link above to our Project Workbook will get you access to our Seq 1, let us know if you’d like the Seq 2 document… its a lot more detailed! You can dive into the timeline here.
- Sandbox Testing – More Risk Analysis
We had to enable the Percolator people to test their app against the large-row-count ORG of this client, while also proceeding along our audit steps, so we decided on 2 sandbox environments for the project (one Dev, one Full – which is a paid service of Salesforce). By having 2 sandbox environments, one engineer could proceed to test the sequence of data changes at the same time as the vendor could test app performance (this done in the Full sandbox), while the second engineer could do package, trigger, workflow and integration testing in the other (this in the Dev sandbox). Setup of these environments was key to coordinating the 5 groups involved in this transition.
Summary – Front-Loaded Process
This project took almost 125 hours – and much of that work was in analyzing risk, and communication with vendors. It is the sort of project where if you know everything, you can do it quite quickly (less than 20 hours) – but you never know everything! Because of the complexity of how objects, packages, triggers, workflows and integrations intersect and interact, understanding the effect of such a fundamental change as an account model shift is necessary before the shift is actually done. And that takes time, and attention to detail. Measure that thing twice before you cut!