Advanced Training: Admin

Principles of Site and Data Security

With your goals, and objectives in mind, the first step is to correlate them to's basic principles of user access and site security.

The four core principles of system security are:

  • Data Ownership
  • Data Viewership
  • Data Actions
  • User Roles

Data Ownership

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 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).

Click to view larger image.

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 View X X*  
Can Edit X X*  
Can Delete Usually reserved for Sysadmins
Can Reassign Ownership X*    
Reporting Reflects Activity Yes Some None
*If allowed by the Sysadmin

The Basic Rules of Thumb:

  • If a user owns data, they are generally allowed to both view and modify it.
  • If a user doesn't own the data, but is allowed to share it (through a Campaign or dialer list), they can edit and view it, but only within the location specified.
  • If a user doesn't own data, they may be allowed to view it but not modify it; both view it AND modify it, or neither. Users must always be given specific permissions to view and modify data they do not own.

Non-standard Permissions

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.

Data Viewership

Once ownership of the data is established, 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.

Data Actions

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

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.

Sample Permission Group Settings

Click to view larger image.

In addition to linking data ownership and actions, permission groups also determine if a user is able to modify the structure of the 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.

Release Notes

Find our most recent release notes.


Our community forum is coming soon.

Advanced Training Guides

Advanced training for the Lead Management Platform.

Have questions?

We're happy to help. An expert is just a phone call away.

(866) 593-2807

Mon-Fri 6-7 MST

Back To Top

© 2004–2014, Inc. all rights reserved. Use of the service and this Web site constitutes acceptance of our Terms of Use and Privacy Policy. technology is protected by the following United States Patents: 8078605, 8325738, 8352389, 8510382, 8566419.