With your goals, and objectives in mind, the first step is to correlate them to InsideSales.com's basic principles of user access and site security.
The four core principles of system security are:
Each of the four elements interacts with the others to produce the overall data and security controls; however, ownership is the most crucial. Data ownership largely determines the structure of the other three elements.
If you're familiar with the term it likely doesn't need any explanation, but ownership refers to "which user of the system is data currently assigned to?"
Everything a user is allowed to do (or not do) while using InsideSales.com is first based on the question, "Does the user own the data?"
If the answer is "Yes," the user is allowed to work with the data in certain ways. If the answer is "No," the system uses a different set of parameters (NOTE: just because a user doesn't "own" certain pieces of data doesn't necessarily mean they're restricted from looking at it, or working with it).
Ownership rules are typically determined by User Role. Some users are allowed to only work on data they own, some may be allowed to work on data owned by other people.
User permissions often follow company hierarchy: System Administrators and managers are allowed to see, access, and modify all data and areas of the system; front-line supervisors can see and access data owned by their team; general users can only access data they own, unless allowed to share it through a dialer list or Campaign (see the table below).
Each user role is then codified into a Permission Group, which can be assigned to multiple users who share the same role.
|User Owns Data||User Shares Data (i.e., doesn't own the data directly, but is allowed access to it through shared ownership, a Campaign or Dialer Initiative)||User Does Not Own Data|
|Can Delete||Usually reserved for Sysadmins|
|Can Reassign Ownership||X*|
|Reporting Reflects Activity||Yes||Some||None|
|*If allowed by the Sysadmin|
By splitting up permissions into the owner/view/modify matrix, it gives Sysadmins a lot of flexibility in how they allow users access. However, if you're not careful, it's theoretically possible to create a set of permission structures that are broken. For example, you could create a permission set that allowed a user to view data that he or she owned, but was unable to modify it, or you could create a permission structure that allowed users to edit data they don't own, but weren't able to view it.
Once ownership of the data is established, InsideSales.com next determines if the user can see it, or search for it (remember, just because a user can see data doesn't necessarily mean they can edit it).
View permissions can be set up on an individual level (you only see what you own), in sets of teams (where everyone belonging to the same team can see each others' data), or universally (users can see all data, regardless of owner).
The idea is to think about whether you want users to be able to see data they don't own—even if they won't be allowed to modify it. This will all depend on personal taste, experience, and workflow. Some Sysadmins are unconcerned with allowing users to share data, some are very protective.
Once ownership and view permissions are established, the system then looks at whether the user is allowed to modify anything they can see. By default, users can modify any piece of data they own, including deleting it and change ownership (if some of these need to change, update the Permission Group accordingly).
Keep in mind that it's possible to allow some data modification actions, such as editing a record's status, while disallowing others. For example, even if a user is allowed to edit a record they don't own, in many cases the Sysadmin prevents the user from changing the owner. There are also advanced ways of preventing individual fields from being altered by non-owners if the Sysadmin deems it necessary.
Permission groups are the glue that holds the rest of the security and permission structures together, and can be tweaked and fine-tuned to fit nearly any role the Sysadmin wants. For example, a Sysadmin might have a group of "fronters," or lead generation reps, that they want to be able to view and edit Lead records, regardless of owner, but want to prevent them from viewing or making changes to the records once they convert into an Account. The granularity of the permission structure makes this possible.
In addition to linking data ownership and actions, permission groups also determine if a user is able to modify the structure of the InsideSales.com system. If you want a user to be able to create their own custom record layout views, for instance, they would need to belong to a user role that gives them permission to do so.
We'll focus in more detail on permission groups later. For now, the idea is for you to start connecting the concepts of user roles, data ownership, and site security to your workflow process.