In a previous post, I shared some thoughts on best practice and its relevance to implementing Salesforce. As a follow-up, I want to talk a little more about what it means to take on Salesforce from the lens of best practices in long-term administration.
Too often, in my experience, I’ve had clients treat a Salesforce implementation as a discrete moment in time: “We wanted Salesforce, we got Salesforce, we have Salesforce – and now… we’re done!” One of the trickier discussions I have is what I call the “Puppy Talk.” It essentially asks these two questions: If you adopt a puppy, do you expect that it will housebreak, train, feed and care for itself as it grows up? So therefore, how are you going to care for and grow your Salesforce instance?
I often will take a moment with clients to point out that just like the new puppy, a Salesforce implementation will need care and feeding, growth and maintenance, that they may not be accustomed to doing with Excel sheets and single-purpose donor databases. Salesforce is a changing entity, and ideally your mission and programs are going to change and evolve over time as well. The advantage Salesforce offers over other platforms and tools is that it is powerful enough to change with you, so you won’t feel constrained by more singularly-purposed tools.
However, taking on Salesforce as an organization means making a commitment to it. It will reflect all of the attention, maintenance and time you spend with it back to your organization – just like raising that new puppy. So, what are some of the best practice ways you can continue your Salesforce implementation long after the consultants have gone home?
Salesforce Seasonal Releases
These happen three times a year. They generally add capabilities to Salesforce over time, new features, and additional capacity to do specific functions. Sometimes, these can take the place of existing measures inside a Salesforce instance that are workarounds, other times they can bring entirely new ideas online for your instance.
Seasonal Releases also require reading release notes, making decisions about what to implement from each seasonal release, and understanding when and how long-term changes to Salesforce.com will happen. Very occasionally, they also change existing and expected behavior, as well as can affect the operation of managed packages and other customizations and configurations in Salesforce.
In addition to Seasonal Releases, there are Critical Updates – they will appear from time-to-time and require someone to pay attention to the changes they’re making and activate them before they activate themselves. Critical Updates are literal “bugfixes” in the Salesforce CRM that help streamline its operation and use.
Determining whether or not to use Salesforce declarative functionality, generally called “clicks,” and when to use and maintain Salesforce Apex code, I offer, should be governed by the longevity of the processes they’re designed to support. My co-worker recently wrote an entire blog on how to make this determination. This thought process is particularly necessary for smaller nonprofits, who sometimes have higher staff turnover, or evolving organizational business processes. The thing about using code in Salesforce is that it requires someone who knows how to write it and maintain it in a way that supports sustainable code coverage, and then requires documentation of its existence. For most nonprofits, this is a consultant.
To the average user, and unfortunately some administrators, Apex code is also “invisible” – it makes things happen behind the scenes in Salesforce that aren’t available through just using formula fields and workflows. However, I’ve seen instances where the purpose of the code gets lost over time, or the processes it supports change, and it creates data management problems for nonprofits who lose the ability to maintain it themselves internally because they can no longer afford or have lost track of the consultant who developed it. One of the best examples of this was a client who built a workflow to undo the changes made by Apex code because they believed that the custom code’s behavior, long forgotten, was, “just how Salesforce worked.”
None of these are reasons not to use code customizations of Salesforce – they’re additional considerations that help to better frame the use of code. Because code isn’t as easily done and undone as declarative “clicks” customizations, make sure that you have solid documentation of it, and you’re confident in the processes it’s designed to support. Code can feel easy because it makes ordinarily inaccessible things within Salesforce possible, but even in my developer training for certification, which is geared towards corporate Salesforce users, non-code solutions were always encouraged first.
User and Space Licensing
A lot of smaller nonprofits get the 10 licenses that are provided with their Salesforce instance, and yet have needs that require more than 10 staff members to use Salesforce at the same time. This can be a gray area for nonprofits for many reasons.
While the perfectionist in me wants to tell everyone, “One license, one user!” I recognize that this isn’t fiscally pragmatic for many nonprofits. Adding additional licenses, even with nonprofit discounts, can be a worthwhile but costly expenditure that needs annual renewal. One of my longest-term clients successfully operated their instance on 12 shared licenses for several years before the business process needs of the organization have finally required a stronger audit trail.
The best practice of administration gives every user their own login, which requires additional licenses in some circumstances. Salesforce security, task assignments, workflows, and other structures are set up to support this practice, along with the aforementioned audit trails critical to organizations handling sensitive information. You want to know precisely which user last touched a records’ data, not have to guess at it.
Additionally, the more “stuff” you put into Salesforce, the more space it requires – consider the longevity of things like Attachments, Task records, and other records you’re creating. Sometimes, the smallest organizations can run out of space fastest because “everything goes into Salesforce.” The problem is that getting space for more “stuff” can cost substantial money. So, think about why you’re hanging on to records, old data, and attachments before, during and after their use to maximize the data storage available to your organization in Salesforce.
Documentation
To me, there’s two types of documentation for users, and many kinds for administrators and developers. For users, there’s the basic “how-to” documentation – this generally tells folks where to go to create and enter Accounts, Contacts, etc., how to use basic Salesforce functionality, and how to make things “go.” Cloud for Good has put together a substantial amount of this “how-to” documentation as Nonprofits 101, available free on the Salesforce App Exchange. To more deeply inform your “how-to” documentation, there’s also business process documentation that instructs users that by entering Accounts and Contacts in specific ways, or employing specific types of Salesforce functionality and making things “go” the way they do, why processes at your specific organization are supported. It can really help with change management to give folks this bigger picture by documenting both the “how” and “why” of Salesforce use. For administrators and developers, there’s documentation that can support data mapping from other systems, integrated processes, code customizations, and custom Object/field development.
Don’t forget Salesforce’s “built-in” documentation systems as well: Description fields for custom fields, Objects, Workflows and other declarative functions that help administrators understand a field’s function; and, the Help Text boxes that exist on all custom fields for users to understand the field’s end use, which can generally be phrased as a question that the user answers when they fill out the field, such as “Does this person wish to opt-out of email?”
Capacity and Training
Nonprofits can also make some mistakes implementing Salesforce: from overreaching on the scope of their initial implementations, which leads to diminished user adoption or code/security structures in place they don’t have the capacity to administer, to simply adding everyone as System Administrators after the consultants leave because it’s simply “easier” than trying to maintain Profile-based security. Many Salesforce consulting firms, including Cloud for Good, offer additional support packages of time to further assist organizations with post-implementation administration.
However, a large part of capacity and training requires identifying your own internal resources inside your organization who will be responsible for the long-term care and feeding of your Salesforce instance. Joining the nonprofit Salesforce community and allowing your internal resource to participate in user group meetings, and if affordable, Dreamforce are also great ways to strengthen your internal capacity.
For nonprofits, Salesforce is a community-driven tool – don’t be afraid to engage the many peer organizations, user groups, and gatherings for nonprofits that support its use. Give your organization a gift, and find ways to support the development of your staff’s use of it by sending a staffer to Administrator training and certification (50% discount for nonprofits), conferences and events necessary to promote its longevity and health use.
