We've mentioned a number of times now that Permission Groups, or Page Permissions, control a user's ability to modify data in the system. When you set up your employees, you are required to select a Page Permission setting for them.
This section will help you visualize and define how each of your Page Permission Groups operates.
As mentioned previously, Data View permissions control what data is visible to a user, based on who owns it. Regardless of any other settings, a user is always allowed to view data that they own.
However, the Page Permission settings can be set up in ways to deny users the ability to edit data, even if they own it—and can block users from accessing entire site areas at all, even if that site area contains data that they own.
Obviously, blocking users from data they own is counterproductive, but as you explore the Page Permission section of the InsideSales.com system, understand that each setting is designed with the Data View permissions in mind.
Remember: Ownership precedes permission levels.
To get started, go to:
Admin Tab > Site Settings > Manage Permissions
This will take you to the main permission list page. By default, InsideSales.com includes three basic permission levels:
Depending on your organization's process, these three may be all you need, or you may need to create several more permission groups to further break down your users' roles.
QUICK NOTE: Unless you have a good reason to do so, we highly recommend leaving the standard Administrator permission settings exactly as they are. This ensures that the main Sysadmin, or "Super Admin," will always have the ability to make total changes to the system.
If you're not comfortable allowing other Sysadmins to have the same level of control as the "Super" Admin, create a new permission group called "Sub-Administrator," or "Admin Level II," and modify its settings accordingly.
For purposes of this guide we assume that you will be creating the alternative Admin permission group. If you decide you don't want to do this, you can always delete the Permission Group later.
Go ahead and click Add a Page Permission, and give your new permission group a name and a description, as shown.
When finished, it will take you back to the main list screen with your new Permission Group now visible.
Now click on the name of your new group, which is the hyperlink to edit the permissions.
The first thing you'll notice is that the permission settings are broken down according to the various site and object areas: Administrative, Leads, Accounts, Calendar, and so on.
Since this is a new permission group we've just created, each site area will have some baseline permissions selected, but notice the checkbox to the left of each of the site area headings.
This box controls the site area's visibility for the permission group. This can be useful if you have certain users who don't need access to the Accounts or Contacts tabs, for example. By unchecking this option, the site area simply doesn't appear for any users that belong to the permission group.
In this case, since we're creating a Sub-Administrator group, we want to add the appropriate site areas. Mark the Accounts, Administrative, Calendar, Campaigns, Contacts, Deals, Files, Leads, and Reports headings.
Now that you've set the visible site area, now go back through and update the relevant permission settings within each of our chosen site areas.
In some cases, you may want to add all permissions for a particular block. Notice the small icon on the right side of the block header, that looks like three boxes with checkmarks in them. Click this icon, and wait for a second or two, and all permissions for that site area should be added.
As you look through each permission block, most of the options should be fairly self-explanatory. One thing you may notice, particularly in the Administrative area, is that in some instances there's a permission to display a specific link, but there's also a separate permission that controls the function on the "back end."
Permissions are designed this way because many system functions can be accessed through more than one venue. Page layouts, for example, can be accessed directly through the Layout Group function in the Admin tab, but can also be accessed through Dialer Initiatives. In some cases, a user or admin may not need to access the full Layout Group tool, but may need the ability to adjust record layouts used in the PowerDialer. By splitting up the function from the link, it provides more granularity in creating permission sets.
What this means, however, is that you'll occasionally need to pay attention to not just the link being used, but the back-end permission associated with it.
See a description of the generic object/record permissions in the table below.
|Can Export Object (Leads, Accounts, Contacts, etc.)||Specifies whether users can use the Data Export function inside the main object tab areas.|
|Can change Object owners||Specifies whether users can change data ownership, either of data they directly own, or data owned by someone else accessed via Data View permission, Dialer Initiative, or Campaign.|
|Can edit other's Objects||Is the user allowed to edit data they don't own, period, yes or no? This option supersedes the Change Object Owner permission.|
|Can edit Leads in all Campaigns||This is a fairly process-specific permission available only for Leads. This option specifies that a user can view and edit any leads assigned to a Campaign, even if they themselves are not a Campaign attendee.
This option is typically only useful if a company wants to restrict access to the full and complete Leads tab area, but does want users to access data assigned to Campaigns. This is essentially a data segregation method—if a Lead is not assigned to a Campaign, then users without access to the Leads tab cannot view or access it. If it is assigned to a Campaign, however, then users with this permission, or those assigned as Campaign attendees, can access it.
|Can delete Object||Is the user allowed to delete and purge records from the database, yes or no?|
|On Complete Event, Use Log Activity||With this option enabled, any time a user completes a calendar Event, the system automatically brings up the Next Action dialogue to schedule a future action.|
|On Complete Task, Use Log Activity||Identical to the Event option, if a user completes a task, the system automatically loads the Next Action dialogue.|
|Can Re-Arrange Sublist||This permission allows users to redefine the appearance of sub-object data attached to a Lead or Account. In most cases, this option should be allowed, as users often like to organize their data differently.|
|Can Mass Update Objects||If the option is de-selected, users will not see the Mass Update dialogue area inside the specified object tab.|
|Add_object||Gives user the ability to manually add a new record of the specified type.|
|Clone_object||Allows the use of the Clone feature in the LMP, to make an exact replica of any record.|
|Edit_object||Is the user allowed to make changes to any objects of the specified type, yes or no?|
|View_object||Is the user allowed to view objects of the specified type within the main LMP?|
|Allow Users to Change Click-to-Call Caller-ID||Gives users the option to change their Caller-ID from the settings dialog in the dialer panel.|
|Show Users the Caller-ID in Use||Adds a display to the dialer panel that displays the Caller-ID when calls are being made.|
|Link: Manage Area Code Groups||
Allows the user to see the Manage Area Code Groups link on the Administrative tab. In conjunction with other tools, this page is used to create used to create specific groups of area codes which can be used to route calls to specific agents.
NOTE: By default this setting is not available unless activated by your InsideSales.com representative. If you are interested in using this feature, contact your representative and let them know.
There are too many Administrative permissions to enumerate in this chapter. Users who would like a more detailed breakdown of individual Admin permission settings should consult the available index table, but some basic guidelines are:
If your organization is using call monitoring, you might find it useful to limit which actions are available to them within the monitoring tool. Each permission group can have monitoring actions enabled or disabled as shown.