Skip to main content
Version: 1.22.3

Role Structure

In SimpleOne, roles can be divided into three abstract layers based on their daily duties and authority. Role layers are sorted in ascending order:

  1. End-users
  2. ITSM Agents
  3. Administrators

Depending on your business tasks and demands, use standard system roles or create a new one. To configure role permissions and responsibilities, create an ACL Rule for it.

A user can get a role in many ways. See the Role Inheritance article to learn more.

End-users

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, the end-users cannot use the agent interface and perform any actions. The actions require specific roles.

caution

Users without a role, such as end-users, 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 work on tasks. This operation is available to employees with ITSM, admin, or special administrative roles.

See 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 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 agents are provided:

RoleDescription
ITSM_agentITSM agents can manage incidents, change requests, problems, service requests, and related tasks assigned to them or their group. ITSM agents can create change requests and read published articles related in the Knowledge Base. Users with this role can export lists in Excel format.
change_managerChange managers can create, read, and update any record in the Change Request and Change Task tables.
Change managers can update the approval records when these conditions are met:
  • If an item to be approved is a change request OR if the approver is the change manager.
  • If the approval state is Requested.

This role contains the ITSM_agent role.
problem_managerProblem managers can create, read, and update any record in the Problem and Problem Task tables in any state except Closed. This role contains the ITSM_agent role.
incident_managerIncident managers can create, read, and update any record in the Incident and Incident Task tables in any state except Closed. This role contains the ITSM_agent role.
request_managerRequest managers can create, read, and update any record in the Service Request and Request Task tables in any state except Closed.
Users with this role can update the approval records when these conditions are met:
  • If an item to be approved is a request OR if the user is the approver.
  • If the approval state is Requested.

This role contains the ITSM_agent role.
catalog_managerCatalog managers can create, edit and delete records of the Request Model Catalog they are responsible for.
cmdb_agentCMDB agents can read CI records and update them if they are owners of CIs or members of responsible groups.
The role contains the cmdb_read role.
cmdb_managerCMDB managers can create, update, and delete CI records. The role contains the cmdb_read role.
cmdb_readCMDB readers can only read CMDB records of classes, attributes, models and CIs.
itsm_event_readerITSM event readers can read records of the Monitoring and Event Management module.
itsm_event_managerITSM event managers can create, update and delete records of the monitoring rules, event rules and actions for event rules. The role contains the itsm_event_reader, ITSM_agent roles.
model_managerModel 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_creatorMessage creators can create records in the Monitoring Source Target Message table. The monitoring system will authorize under a user with this role.
service_catalog_managerService catalog managers can update the article records related to services.
service_level_managerService level managers can update SLM-related records.
service_ownerService owners can change the state of any article related to the service they own.
Note that the service_owner role is temporarily deactivated – our team is working on its logic improvement to make it more efficient and secure. We will inform you about changes in the next releases.
product_managerA product manager can create, edit and delete the product records.
product_agentA product agent can edit the products for which they are the Product owner.
crm_certificate_managerCertificate managers can add and edit certifications and certificates and view the majority of CRM application pages.
crm_marketeerThe marketing manager is able to add and edit the marketing campaigns, view the majority of records in the CRM application tables and add records to the marketing lists.
crm_salesThe sales manager is able to add and process the leads and opportunities and view the majority of CRM application pages.
crm_managerThe CRM application manager is able to add and process the leads and opportunities, reassign them and manage the majority of CRM application records.
crm_pamThe account manager responsible for a partner company. The user with this role can read the opportunities of their selling direction and edit the opportunities with the Partner the current user is Responsible for.
crm_presaleThe pre-sale manager. The permissions of this role are identical to crm_pam.
pda_userThe user of the SDLC application has limited access to the application sections and records that allows basic work operations. The project member, product owner and product module owner with that role has extended access to the application records.

Administrators

There are two groups of administrative roles:

  • Administrative roles
  • Special administrative roles

Administrative roles


Specialists with administrative roles have access to all system features and data and pass all security checks.

SimpleOne offers two administrative roles:

RoleDescription
adminThe system administrator role.
Admin users have extended privileges and can use nearly all system functions (except assigning User Roles, working with Access Control List (ACL), and User Criteria).
Admin users have access to all data unavailable to regular users.
security_adminSecurity 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 debugging scripts exception appears, or any other system error occurs. Only users with the admin role can see the error message.

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, the following special administrative roles exist:

RoleDescription
announcement_managerAnnouncement managers can create, update, delete, and publish Announcements.
approval_adminApproval administrators can update approval records.
catalog_adminCatalog admins can create, edit and delete records of the Request Model Catalog module.
cmdb_adminCMDB administrators can create, update and delete CI records, classes, models and their attributes.
delegation_adminDelegation administrators can create, update, and delete delegation records. They can update the only available fields on the delegation rule form.
import_adminImport admins can manage all aspects of imports.
impersonatorImpersonators can interact with the system on behalf of other users.
The role does not allow users to impersonate admin users. Only admins can impersonate admins.
knowledge_adminKnowledge admins can create and update records related to the Knowledge Base.
Users cannot update Article records in the Published state – only reading is available.
This role contains the knowledge_agent role.
knowledge_agentKnowledge agents can update records related to the Knowledge Base in the following cases:
  • The user is the responsible person.
  • The user belongs to the responsible group.
  • The user is responsible for the defined parent category.
notification_adminNotification admins can create and update notification rules.
queue_adminQueue admins can create, read, update and delete records of the External Queues module.
user_managerUser managers can create new users, employees and add users into groups.
wf_adminWorkflow admins can create and update workflows in the Workflow Editor.
wtm_adminWTM admins can create, update and delete records within the Work and Time Management application.
The users with the admin role have the same access.
crm_adminThe CRM administrator can manage the majority of records in the CRM application, including selling directions.
crm_read_adminThe CRM system administrator can read all application records but cannot create, update or delete them.
pda_adminThe administrators can create, update and delete records within the SDLC application.
The users with the admin role have the same access.