Found in the Web interface of ITAM as a sub navigation item under Settings in the main left sidebar.
The equivalent of the Admin Access window in KeyConfigure, this page is used to manage privileged Accounts, Roles, and Groups. Note that the concept of Permissions is very deep and often best explored with a member of our Support team when working at the enterprise level.
- The left side sub navigation has three sub sections: Accounts, Roles, and Groups. Roles grant Privilege, Groups grant Access. In order to have Permission to a thing, you need both privilege and access. This complexity allows very granular federated rights.
- Roles and Groups are assigned to Accounts by drag and drop. They can also be automated by way of an External Authentication system (e.g. Azure) and group membership therein.
- You can right click on an account/role/group to access a context menu to Delete items or Duplicate them. You can not modify privileges in built-in Roles, but you can duplicate them as a starting point for a custom role.
- Making the divider between the sub navigation and main pane wide enough will show details like if an item is built-in or linked to an External Group.
Accounts
Selecting an Account will show the details for that account.
- The Name of the account is what is used to log in.
- If an account is set to External then the Password is disabled and not relevant.
- The email address is optional and for reference only.
- Default Section is used in complex access rights settings to assume where a resource is created if the account has access to multiple Groups.
- Default Forms can be assigned to set the view of various record types to a custom alternate from the normal Details view.
The Privileges section shows what the result of the assigned Roles is. These are additive in the case of multiple roles on an account. They can not be edited at the account level.
Roles
Roles can be linked to External Groups in a directory system. This allows for automatic provisioning of a Role to an external group member at login. The details of this can be slightly more complicated than that statement, and you're encouraged to talk with Support as needed to set this up.
The Privileges are the core of the permissions management in the platform, with Access rights being a secondary item when granularity is needed. Each sub section of this list has many items related to that data type or grouping of concepts. Note you can not modify any built-in Role, but you can Duplicate it as a starting point for customizations. Several items can be unclear as to their impact and importance when you are not familiar with the nuances of the platform. Again we encourage you to test any role and consult with Support as needed. A few such items are listed here:
- Under Settings: View Division Separator, View Default Purchase Currency, View System User Names, View Computer ID Settings. These all tend to be fundamental in some way, even if the users is only doing things like viewing purchase records (and being able to see the currency). They are not strictly required but lacking them can cause odd experiences.
- KeyReporter Privileges control the Web UI experience specifically, regardless of other settings. For example, if you lack View Computer List Page, then it doesn't matter that you have full Computer Privileges, you still can't see the computer page at all.
- Similarly, everything in the Web uses our API. So while not immediately obvious, Inspect and Modify objects via REST API are needed for red and write ability of any kind respectively.
- Forms and Scripts have individual rights to Use them vs View the list pages of them.
These are just a few examples, again Support is happy to assist with questions if you're having trouble getting a Role to work as needed.
Groups
There are only two built in Groups: Editors and Viewers. These grant view and/or edit access accordingly at a global level. Using this simplifies the Permissions structure to using the Role as the final say in what an account can see and do. Granular Access is only needed if you want to limit privilege to sub sets of objects like Computers or Purchases. When you create Sections, a Group is automatically created to manage the access rights on that Section.
To put this another way, if I grant the Editors group to all accounts, they still can not do anything that their Role does not allow. This takes a 2 tier permission system down to 1 tier. But if I needed two different help desk accounts to modify computers, but ONLY the computers in certain divisions for each account, then while they would have the same Role they would have a different Group (e.g. the ones made for Sections).