I’ve been there dozens of times. Customers asking me about Salesforce security. They say “I just don’t understand those roles and profiles and groups. What do I need to do to use Salesforce?”
I’ve finally been able to distill the issue down to two simple questions. If you can answer these questions, then you have just determined the direction you need to go with Salesforce security.
Question #1
Do I want every user in my company to be a Salesforce.com administrator?
If you answered “No”, then you just stated that you need to implement profile level security. Profiles define a user’s experience. Particularly, they enable an administrator to restrict users from accessing different parts of the system. You can restrict object access, field access, administrative and user level permissions. For you Windows NT guys, remember the Group Policy Editor? It’s the Salesforce equivalent.
There are many facets to profile level security. I generally find it is easiest to identify the users that will be using Salesforce first, and then back into the specifications for each type of user. Typical profiles include “System Administrators, Power Users, Standard Users”. Once profiles are identified, I review the needs of each group such as:
- Login restrictions on time and place
- Application and Tab accessibility
- Object and field accessibility
- User level abilities (run reports, export data, send emails)
- Administrator level abilities (manage reports, modify other user profiles, import data)
Question Number 2
“For a particular object, should all users be able to see and modify all of the records?”
If you answered “No” to this question, you indicate that you need to implement Role based security. Role based security can also be thought of as “Row Based” security. If you imagine a data table, roles allow you to restrict the roles of the table the user has access to. A row could be a particular customer account they should not be able to see.
Implementing role based security is often more mystical than profiles as there are may layers that impact a users visibility to a record. These layers include the “Organizational Wide Default” on the object, their position in the role heirarchy, Sharing Rules, and Manual Sharing. The short version of how to understand role based security needs is the following:
- Determine which objects need to have data restricted and enable organizational wide default restrictions (i.e. should all Accounts be public read/write, or Private to their owners)
- Determine the heirarchy of users that should automatically share data. (i.e. should a sales manager see data of their subordinates? If so you need to define a role heirarchy)
- What are the exceptions to the role heirarchy? Determine exceptions and craft sharing rules to open things up.
- Train staff on manual sharing usage so they can share records that fall outside the sharing rules if needed.
I hope this short, 2 cent tour of Salesforce security shines some light on the complexity. To recap, remember there are two separate security models in the application. Profiles determine a user’s experience in Salesforce. What applications, objects, and fields can they see. Roles determine what records a user has access to (Their own records, their team’s records, or all records).
Do you have any other critical questions you think all administrators should ask? Post a comment! Thanks for reading – Garry
