In SimpleOne, roles can be divided into three abstract layers based on the daily responsibilities and privileges associated with these roles. The role layers below are sorted in ascending order:
Depending on business tasks and demands, you can use standard system roles or create a new one. To configure the role's privileges and responsibilities, create an ACL Rule for it.
A user can get a role in many ways. Refer to the Role Inheritance article to learn more.
End-users
Generally, end-users have no specific role in the system. They can raise tickets via the Self-Service Portal, track them, add comments, read published articles and external known error records. However, end-users cannot use the agent interface and perform any actions. These actions require specific roles.
Users without a role have no access to any interfaces except the Self-Service Portal. If such a user tries to follow the link that leads to the agent interface, they will be redirected, for example, to the Service Portal main page.
A user granted with the user role can log in to the agent interface, but they cannot handle the tasks. This operation is available to employees with common ITSM, admin, or special administrative roles.
Refer to the Users article to learn how to grant roles.
Agents
Agents are the employees handling daily tasks in the system, for example, processing incidents, change requests, or configuring the CMDB. One or more roles should be assigned to the agent to perform these duties based on the tasks and responsibilities.
In SimpleOne, the following ITSM roles are provided:
| Role | Description |
|---|---|
ITSM_agent | ITSM agents can manage incidents, change requests, problems, requests, and corresponding tasks assigned to them or their group. Agents can also create change requests. They can read published articles related in the Knowledge Base. Users with this role can export lists in Excel format. This role includes the itsm_event_reader and cmdb_read roles. |
change_manager | Change managers can create, read, and update any record in the Change Request and Change Task tables. Users with this role can also edit the approval records related to change requests if the approval is in the Requested state. This role includes the ITSM_agent role. |
problem_manager | Problem managers can create, read, and update any record in the Problem and Problem Task tables in any state except Closed. This role includes the ITSM_agent role. |
incident_manager | Incident managers can create, read, and update any record in the Incident and Incident Task tables in any state except Closed. This role includes the ITSM_agent role. |
| itsm_event_manager | ITSM event managers can create, update and delete records in the following tables:
This role includes the itsm_event_reader and itsm_agent role. |
| itsm_event_reader | ITSM event readers can read records in the following tables:
|
request_manager | Request managers can create, read, and update any record in the Service Request and Request Task tables in any state except Closed. Request manager can update the approval records when these conditions are met:
This role includes the ITSM_agent role. |
| cmdb_agent | CMDB agents can read CI records and update them if they are owners of the CIs or members of responsible groups. The role includes the cmdb_read role. |
cmdb_manager | CMDB managers can create, update, and delete CI records. The role includes the cmdb_read role. |
| cmdb_read | CMDB readers can only read CMDB records (classes, attributes, models, and CIs) |
| kanban_manager | Kanban managers can create, update and delete kanban boards. |
| model_manager | Model managers can create, update, and delete CI model records. They can also choose classes when creating new CI models. The role contains the cmdb_read role. |
| monitoring_message_creator | Message creators can create records in the Monitoring Source Target Message table. The monitoring system will authorize under a user with this role. |
service_catalog_manager | Service catalog managers can update the article records related to services. |
service_level_manager | Service level managers can update SLM-related records. |
service_owner | Service owners can change the state of any article related to the service they own. Please note that the service_owner role is temporarily deactivated – our team is working improving its logic to make it more efficient and secure. We will inform you about the changes in a next release. |
Administrators
Administrative roles can be divided into two groups:
- Administrative roles
- Special administrative roles
Administrative roles
Specialists with administrative roles have access to all system features and data and can pass all security checks.
SimpleOne offers two administrative roles:
| Role | Description |
|---|---|
admin | The system administrator role. Admin users have extended privileges and can use nearly all of the system functions (except for assigning Roles, working with Access Control List (ACL), and User Criteria). Admin users have access to all data unavailable to regular users. |
security_admin | Security administrators can modify the ACL and access highly secured objects and operations. A session in the security_admin role lasts 1 hour. After that, you need to elevate the role once again. |
When a debugging scripts exception is thrown, or any other system error occurs, only users with the admin role can see the error message. The example of an error message is shown below:
Special administrative roles
Special administrative roles are assigned with specific administrative rights without the full privileges of the administrative role. For example, a notification admin can create notification rules but not assignment rules.
In SimpleOne, there are several special administrative roles:
| Role | Description |
|---|---|
announcement_manager | Announcement managers can create, update, delete, and publish Announcements. |
approval_admin | Approval administrators can update approval records. |
change_manager | Change managers can update the approval records when these conditions are met:
|
| cmdb_admin | CMDB administrators can create, update and delete CI records, classes, models and their attributes. |
| delegation_admin | Delegation administrators can create, update, and delete delegation records. They can update the only available fields on the delegation rule form. |
import_admin | Import admins can manage all aspects of imports. |
impersonator | Impersonators can impersonate users. The role does not allow the impersonation of admin users. Only admins can impersonate admins. |
knowledge_admin | Knowledge admins can create and update records related to the Knowledge Base. The user cannot update Article records in the Published state – only reading is available. This role contains the knowledge_agent role. |
knowledge_agent | Knowledge agents can update records related to the Knowledge Base in the following cases:
|
notification_admin | Notification admins can create and update notification rules. |
user_manager | User managers can create new users, Employees, and add users into groups. |
wf_admin | Workflow admins can create and update workflows in the Workflow Editor. |
| wtm_admin | WTM admins can create, update and delete records within the Work and Time Management application. Users with the admin role have the same access. |
