In the 20 months since I left Fight Colorectal Cancer, I would guess that I’ve logged in to no less than 150 nonprofit Salesforce organizations. First as part of my role supporting customers at Convio/Blackbaud, and now in my role at KELL Partners where I work with clients who contract with us for support or virtual administration services.

When trying to troubleshoot a problem, one of the first things I typically look at is how the organization has structured their security and sharing model. Profiles, roles, organization-wide defaults, sharing settings. I’m thrilled to say that I’ve logged in to many organizations where the System Administrator is truly that – someone whose is responsible (and accountable) for the way Salesforce works for everyone else. Someone who protects the data and their configuration. Someone who knows where experimentation is okay and where they need to tread lightly. If that’s you, then thank you – this post isn’t for you. But please read on and comment on anything I’ve missed, okay?

For this post, I’m talking to the organization whose Manage Users looks something like this (yes, this is from a real org I won’t mention by name):

Read on and I’ll explain exactly why it’s a very bad idea, and I’ll give you some suggestions on what to do to protect your organization’s data and your sanity.

Who should be a System Administrator?

Personally, I have this fantasy that before anyone accepts the profile of System Administrator they must stare at the website of their spirituality of choice, raise their hands in the air and say something like this:

I, [name], do hereby affirm that I am [organization’s name] System Administrator and I understand that as far as Salesforce is concerned, I am [insert name of deity that represents a supreme being]. I have the power to do whatever I want in Salesforce, and no one will stop me. I have the power to grant any Salesforce wish that any other user has (as long as I know how to do it), and no one will stop me.

I can edit any record. I can delete any record.

But that power means that I can also do a lot of damage. I can edit any record. I can delete any record. Lots of them. At the same time. I can turn features and functionality on and off and I understand that some of those features and functionality can’t be turned back off and can stop my organization from using Salesforce as they need to.

Therefore, I solemnly swear:

• I will participate regularly in the Power of Us Hub and/or NPSF.
  
• I will keep our installed applications updated, and will read release notes and documentation.
• I will set up the Weekly Backup and actually download the backup file within 48 hours of when I’m notified it’s ready. Better yet, I’ll save that .zip file to a computer/drive that is regularly backed up.
• I’ll do as much of my experimenting as I can in a Sandbox first, especially for functionality that can’t be turned off.
• I’ll find it in my organization’s budget to attend Dreamforce, especially since my nonprofit can get a great discount (psst – if you don’t qualify for the nonprofit discount rate, use code D13MVPREF for $100 off)

Not all organizations have someone who can devote hours a day or week to Salesforce. I get that. So you might consider working with a partner that can handle Administrator duties for you. Yes, KELL offers such services but so do the other Nonprofit consulting partners. Salesforce itself offers virtual administrator/premiere support options. It’s an expense. But it’s probably cheaper than paying later to clean up the damage. We have one client who had to start over in a brand new instance at some expense and downtime because a well-meaning but inexperienced so-called System Administrator turned on Custom Fiscal Years and it broke functionality in other applications. Don’t let that be your organization.

To learn how a single Administrator can set up their instance to grant proper access to records without assigning everyone as a System Administrator, check out Salesforce’s excellent Who Sees What video series. It will guide you step-by-step on how to set up the right combination of profiles, permission sets, sharing rules and defaults to give your users the access they need without compromising your overall data integrity.

What about sharing logins?

Let’s get real here: everyone does it. That’s what’s awesome about the cloud. Salesforce will indeed allow the same user to be logged in from completely different locations at the same time. You have more staff than granted Salesforce seats, so why not share? If two people perform the same duties in Salesforce, why not have a generic login they both share?

Here’s why not: Every record in Salesforce has an audit trail. It shows exactly when and by whom that record was created or last modified. It doesn’t matter whether that user is active or not. When there’s an issue, that audit trail is going to be important to determine what happened and when, and it’s not just about pointing fingers. Accurate audit trails are helpful to repair the damage, too. If every record was last modified by “Development Staff,” it’s no longer helpful.

Salesforce also has what is called a Setup Audit Trail. You can find it under Security Controls in the Setup menu. This will show you who has made changes to the structure of Salesforce. It will even report when it’s an application or automated process that is making the change. You can find the person who made a change and get an explanation. You can see the last 20 changes on the screen or download an Excel .csv for the last 6 months worth of changes. If every change was last made by “Development Staff,” it’s no longer helpful.

Create a unique user for each pair of hands that will log in to Salesforce. You can have as many users as you want. Only those that have the Active box checked on their user profile count towards your total used licenses. Resist the urge to edit an existing user to change the name or the email so someone else can use the same login. That ruins the audit trail I mentioned above and there’s no point to doing that. Only edit a user license if the person’s name or email address has changed, and it still represents the same person. When that one-time volunteer or infrequent user needs to access Salesforce, you simply need to check the Active box on their license and then deactivate them when they’re done doing whatever they have to do. Any records they edit while they’re active will still show that they edited them, even if they’re inactive. Only use this option for those users who are truly infrequent users…volunteers (with a limited profile to match) or consultants. There can be issues with records that are owned by inactive users, especially opportunity and account records. If someone is accessing Salesforce daily or even weekly on a regular basis or they’re creating a lot of records, they should have a license that isn’t turned on and off.

It may seem like a lot of extra work to set up security and monitor who is doing what in Salesforce. But it will be so worth it in the headaches and expense you’ll save later. Keep up the great work!