A Deeper Dive Into Samanage Roles

Document created by Tim Lawes Employee on Dec 9, 2016Last modified by Joseph Brown on Jan 12, 2017
Version 3Show Document
  • View in full screen mode

Samanage Roles and Permissions


Roles are one of the most important parts of Samanage, but they can also be the most intimidating. If you’re a regular human you may not be used to SQL join and union statements, but they are a simple concept and that’s really all there is to setting these up. I do want the user to access these parts of our service desk, but I don’t want them to be able do or see some things. This is Permission or Restriction in the ‘Type’ for Samanage roles.


I didn’t want to recreate the wheel, so check out this great tutorial on Roles and Permissions posted here: https://community.samanage.com/thread/1900


This webinar also shows you more about creating roles: https://community.samanage.com/message/6327


Another important part of creating Roles is to understand CRUD. This is simply an acronym for Create, Read, Update, Delete. These are the actions you can take in Samanage, the operations that you can perform on your records. We call these the ‘Action’ in Roles.


Let’s breakdown what CRUD means:


Create - Ability to create anything new in Samanage

Read - Ability to read/see items in Samanage

Update - Ability to make changes and update items in Samanage

Delete - Ability to delete items in Samanage


There’s also Manage - Perform all actions above (this is a timesaver instead of defining all four actions every time).


Here are some examples:

I want a user to work my Samanage Incidents but I do not want them to be able to delete them.




This Service Agent User can be a typical help desk worker. Notice that we’ve given them Permission: Manage: All, but taken away access to Setup, the ability to delete anything, and we don’t want them managing Benchmarks. This Role is provided to you when you first create a Samanage account, it is very popular and you can clone or update it if you find it helpful.



I want a user to manage only HR incidents and not see any other types like IT, Facilities, etc.



In this example, Users in our HR Group have been allowed access to HR related tickets. We also restricted the ability to Delete (hey, we’ve seen it done…), and taken away Benchmarking and Setup management. This is very similar to the Role above, but we’ve leveraged Scope to make it HR specific.



I want a user to only have access to Assets and not the entire Service Desk.



For this Role we’ve granted Permission: Manage: All, then added Restrictions for all of the Service Desk sections of Samanage. Think back to the SQL Joins- Here we started granting access to everything then taking Service Desk away, but you could also only grant Permission to the Asset sections of Samanage (Computers, Other Assets, Contracts, etc.) both accomplish the same thing.


I want Users to only have access to Samanage for their own Site and Department.



Notice the Scope- this is a great Role that acts as a blanket since it ties back to the setup for each user. You don’t need to create a Role for each Site and Department in your organization and this Role grows as you do. It sections off what Users can access without them having to create filters inside Samanage. This works well for large companies with various operations.



Where is everyone else on the community finding success in their Samanage Roles? Have you created a helpful Role in your account that you’re proud to share? Don’t be shy!


Here is a great example from one our customers that explains his journey of creating roles beyond IT:

Roles and Permissions Beyond IT

7 people found this helpful