The Definitive Tutorial on Roles and Permissions

Discussion created by Employee on Jul 14, 2015
Latest reply on Apr 17, 2016 by Yuval Pecht
The Basics

Roles and Permissions (Setup->Roles) are a way to define what a user can and cannot do within the application.  A user can only be associated to one role, but multiple users can be assigned to the same role.  A role allows/restricts a user from doing ONLY what the role dictates.  For instance, if you have a role that allows a user to only Read: Assets, they won?t be able to do anything other than read those assets, including submitting tickets, adjusting the setup area, or viewing users.

There are a few roles that will automatically be in your account when you sign up with Samanage that cover most use cases.  We?ll cover custom roles in a moment but the majority of your users will fall into one of these 3 roles:

Administrator: This user can do anything in the application and cannot be restricted.  We recommend limiting the amount of Administrators you have in your account (typically one admin plus one backup), but the decision is ultimately yours.

User: Just like an Administrator except this role cannot change anything in the Setup section or delete anything.  They also cannot access the benchmarking functionality so that sensitive information remains available only to administrators.  We typically recommend using this for your technician team so they can effectively utilize the system but can?t mess up configurations or accidentally delete anything.

Portal User: This role will be used for almost everyone else.  Most of your end users will fall into this category as it allows them to go to your self service portal, submit incidents, and read your knowledge base/service catalog but it will not allow them into the back end of the application.  If you are strictly using Samanage?s asset management, this role will allow you to connect users to their respective assets but nothing else.  If a Portal User ever tries to go to your Samanage URL, it will automatically take them to your self service portal.

The majority, if not all of your users should fall into one of these 3 categories unless you choose to build custom roles.

Custom Roles

Why build custom roles?  Let?s start with a few examples and then talk about building these roles.

Example 1: You have 2 teams managing tickets in Samanage and don?t want the respective teams to be able to see each other?s tickets, reducing confusion and clutter in your service desk queue. (i.e. IT, HR, Procurement, Facilities, Marketing, Telecom, Sales, Ops, etc.)

Example 2: A manager at your organization wants to be able to come in and report on assets in your account but you don?t want them to be able to do anything else on the back end of the application.

Example 3: You have service catalog requests built out for HR and only want the HR team to be able to submit those types of requests.

There are plenty of other use cases where you might want to build out custom roles but those are 3 popular cases that we hear about a lot.  Now, how do we build these roles?

First, go to Setup->Roles and click on New Role.  Name your role, and then we can start adding permissions and restrictions.  Let?s define what those permissions/restrictions actually mean:

Manage: This permission/restriction encompasses Read/Create/Update/Delete.  If you want to give a role the permission to Manage: Incidents for example, you can then also restrict them from Deleting: Incidents, saving you some time in building this out.

Read: This permission/restriction allows a user to read certain sections of the application but doesn?t allow them to create, update nor delete these sections.

Create: This permission/restriction allows a user to create things in the application such as incidents, assets, or knowledge base articles.  If you allow a role to create something, we also recommend allowing them to read and update that creation as well.

Update: This permission/restriction allows a user to update things that are already in the application.  Examples being updating incidents with comments, updating existing service catalog requests, or changing an asset?s site or department.

Delete: This permission/restriction allows a user to delete objects in the application.  We recommend giving this permission out sparingly to avoid accidents.

Best Practices/Tips and Tricks

- Determine if users actually need to be restricted from things or not.  For instance, if you don?t care that your HR team can see IT?s tickets, then you could consider just helping them create their default views through reporting to save you some effort in building out a whole new role.

- Determine what you actually want the role to accomplish.  Will this person be spending the majority of their time managing things on the back end of the application and you just want to restrict them from certain areas?  Or is this person essentially a portal user that you want to give a bit more access to?
     - If they are going to be living in the back end mostly, a good rule of thumb is to give them permission to Manage: All and create your restrictions from there.
     - If they are going to be mainly a portal user with access to certain back end portions, a good rule of thumb is to model their role off of the Portal User role (making sure that the ?Users associated with this role can only access the Self-Service Portal button is NOT checked), and add additional restrictions or permissions on top of that.  That way, they can still submit tickets like a regular portal user, but can also come into the back end to manage what they need to.

- Order matters!  For example - If you give permission to manage incidents and then restrict from managing incidents by a particular category, it works as intended. If you restrict from managing incidents by a particular category first and then give the permission to manage all incidents second, it makes that first restriction pointless since I restricted and THEN gave permission afterwards.  As you can see in the example below, both roles have the same permissions/restrictions, but keeping everything in a logical order will make everything work better.

- In relation to order, a good best practice is to start with all of your permissions and then add all of your restrictions.  Don?t do them in random order, it can cause issues and confusion.

- Ask us for help!  The Support and Customer Success teams here at Samanage are more than happy to help you build out roles based on your specific use cases.

Any other questions?  Send us an email at or reach out to your Customer Success Manager for personalized assistance.