Nonprofits who use Salesforce benefit from a generous grant: Each 501(c)3 gets 10 free licenses that provide access to features that cost business users thousands of dollars each year. Organizations with more than 10 users get a steep discount — about 75% off the regular price — for additional licenses. But even with that discount, licenses cost up to $360 per user per year (see our tips on navigating Salesforce licensing to buy the right license for your needs). Since nonprofits are always looking for ways to save money, it’s not surprising that we get asked about sharing Salesforce licenses a lot. Who wouldn’t rather spend donor funds on directly funding their mission than on software?
Salesforce is built on the idea that every user will have his or her own license. Additional licenses are a critical investment to help your organization make the most of Salesforce. Here are some of the reasons why it’s important to license each of your users.
1. Accountability is key to keeping your data clean and safe. Salesforce provides built-in functionality to help you see who’s changing data or system configuration, as well as when and where users are logging in from. Those tools are only effective if you can connect a login to the user associated with it.
Field history tracking is one of the many tools you can use to improve data quality in Salesforce. When users change a tracked field, you automatically get a record of who made a change, what change was made, and when it was made.
It looks like Vicky isn’t the best at data entry. Since you know she’s the one who entered this mangled address info, you can have a conversation with her about your data entry standards, or you can decide she would be a better fit for another volunteer position. If you had several volunteers entering data under one login, you could be stuck cleaning up after Vicky indefinitely.
The Setup Audit Trail tracks who made configuration changes to your system, like updating page layouts or changing picklist values.
If one of your users makes incorrect changes to your configuration, it’s important to know who made the change. That can help you evaluate whether that user needs more training or whether their profile is granting them administrative permissions they shouldn’t have.
User login history gives you information about when and how each user has logged in for the past 6 months. If you suspect there’s been a security leak, you can see when a user account has been accessed from outside your office.
If you see something unusual in the login history, it’s easy to follow up with one person but pretty tricky if you’ve got multiple people using the same login. One out-of-place IP address might mean someone was logging in from home; if you see a dozen different IP addresses, does that mean one person was traveling, multiple people were logging in from home, or someone outside your organization has logged in to that account?
2. Record ownership and views are based on individual users. Salesforce includes “My” reports and list views that show records owned by whoever is currently logged in. These views and reports you a quick way to view records that you’ve entered or taken ownership of.
“My” list views show a different set of records to each user, since the definition of “my” is determined by who is logged in. With shared user accounts, this distinction would be meaningless and each user would need to create custom list views to capture only those records he or she cares about.
What shows up in those lists is determined by the Contact Owner field on the associated record.
3. Activities and tasks are based on the logged-in user. If you use calendar events or activities in Salesforce or you sync with Outlook, you need to have your own Salesforce license for those activities to be associated correctly.
If you shared a login and tried to sync with Outlook, your calendar could be scrambled with every other user who shared that login.
4. Sharing user accounts leads to security risks and hassles. Salesforce has built-in security features that detect when you’re logging in from a new location and set passwords to expire after a designated amount of time. When you login from a new computer for the first time, you’ll get an email from Salesforce asking you to verify that you are who you say you are. That means your shared account would need to be associated with a shared email account, or you’ve got to track down the email account owner just to get logged in. It gets messy quickly.
What happens when the person who that email is sent to is on vacation?
You also need to communicate changes in passwords with other users, or set your password to never expire. (That’s a bad idea. Those expiration dates exist for a reason. The bad decision to share user licenses is now cascading into even more bad ideas.)
5. Sharing passwords is never a good idea. If you’re sharing an account, you’re sharing a password, and if you’re the sort of user who’s comfortable sharing a password there’s a good chance you’re also the sort of user who uses the same password for multiple accounts. Can your co-workers guess your facebook password based on the Salesforce password you just gave them?
6. Sharing logins means resetting passwords every time staff changes. If you forget to do this, people who no longer work for your organization will still have access to your data.
7. You can’t build user adoption if you don’t know who’s not adopting. One of a Salesforce administrator’s most important jobs is building user adoption. Salesforce even provides an out-of-the-box user adoption dashboard to help you gauge who’s actually using your system. But those metrics won’t mean much if you don’t know who’s behind them.
Is Vicky on her way to becoming a super user, or have all the volunteers been using the same login?
8. Chatter is only effective with individual user logins. Chatter can be a powerful way to communicate with other Salesforce users. But your name and your interests are tied to your user account. There’s no way to meaningfully use Chatter with shared logins.
9. If you’re using a private sharing model, you need individual licenses to set record access. Many nonprofits use a public sharing model, which means a user who can view any contact record can view all contact records. If you’re using a private sharing model, you’ll need individual user licenses to determine who should have access to different records.
10. Sharing licenses violates Salesforce’s terms of service. The clearest argument for licensing every one of your users is that you technically have to.
From Salesforce’s Master Subscription Agreement: “4.2 Usage Limits. … (b) a User’s password may not be shared with any other individual, and (c) a User identification may be reassigned to a new individual replacing one who no longer requires ongoing use of the Service or Content.”
Ready to buy licenses? Check out our post on navigating Salesforce licensing to help you make the most cost-effective choices for your needs.
2 replies on “Why every Salesforce user needs their own license”
Great post Laura (and thanks Brad for sharing)!
This is very helpful! One other thought – since Salesforce storage is based on license count, when users share accounts they “cheat” the system out of having the “appropriate” amount of storage space to support the actual user base.