1.2 User Access and Personas Flashcards
Impersonate the users
to test and confirm their access.
System administrator
provides access to all platform features, applications, functions, and data.
Admin role has almost all roles and access to all platform features, functions, and data, with some exceptions such as HR and Security Operations constraints.
The admin role can create and modify user roles, as well as impersonate other users.
Specialized Administrator
Users with specialized administrator roles may manage specific functions or applications, including:
- Assignment Rules
- Knowledge Base
- Human Resources
- Reports
- Web Service
Process User
Users with the process user role may fulfil ITIL activities associated with the ITIL workflow, including incident and change management.
Process Users have clearly defined paths and workflows in the platform and have one or more roles, including the itil and approver_user roles.
Approver
can perform (vykonávať) all requester actions and allows users to view or modify approval records directed to them.
Approvers have the approver_user role, but no other roles.
Requester
Also known as Employee Self Service (ESS) users, these users do not have roles but can submit and manage their own requests, access public pages, etc.
Requesters use the Service Catalog and Self-Service applications. They can make requests only on their own behalf and are not assigned roles.
The impersonator role
can be assigned to a user to allow impersonation of other users, excluding admins, for testing and visibility purposes.
Users are represented by a record on the User [sys_user] table and they may:
Among other tasks, within a ServiceNow instance, users may:
* Update records
* Import data
* Request items
* Implement flows
* Approve knowledge content
* Run reports
* Develop applications
A group is represented by a record on the Group [sys_user_group] table.
A collection of users is a group.
Groups share a common purpose (účel) such as users approving change requests or users receiving e-mail notifications
Examples of Groups include:
* Service Desk
* Knowledge Base Authors
* HR Administrators
Role-based access
It is crucial to protect sensitive data. Realize not every member of your organization needs access to all information at all times.
A group
is a set of users who share a common purpose. Members of groups perform similar tasks or need access to similar information for various purposes, such as approving change requests, resolving incidents, receiving email notifications, or administering the Service Catalog. Users are typically assigned to one or more groups. A group is part of the user hierarchy, and a user is part of a group.
Task: Add a user to your instance, Add a group to your instance
- by navigating to All > User Administration > Users > and select New.
- by navigating to All > User Administration > Groups > and select New. To add a user to a group, select Edit in the Group Members related list and select a name of your choice in the List collector. Add the user by double-clicking the name or by selecting the Add arrow. Once the user is added to the Group Members list, select Save.
Roles
Are used to define access at the application, module, and/or Access Control List (ACL):
* Grant access to the application/modules that a user has access to in the All menu
* Assign security rights.
* Access data in the tables via the ACL (read, write, update, or delete)
A role can:
* Be assigned to a group* or a single user
* Contain other roles.
A user can have more than one role.
Roles are represented by a record on the Role [sys_user_role] table
Role, user, group
Once access has been granted to a role, all of the groups or users assigned to that role are granted the same access.
*TIP: Rather than adding roles to individual users, add the user to a group and assign the role to the group. This method of role assignment makes maintenance easier when people transfer to different roles in the organization.
NOTE: You cannot delete roles that are assigned to the group from a user record. You must remove the user from the group record. The admin role provides access to all features and capabilities.
In the ServiceNow Platform, the word “role”
defines your capabilities (možnosti) in the application.
The second level of security for accessing data in ServiceNow
roles are used in conjunction with users and GROUPS as the second level of security for accessing data in ServiceNow.
ServiceNow Product Documentation about roles
Base system roles
NOTE: Users without any assigned role permissions
Can still log in to ServiceNow and access common actions, such as viewing a dashboard, accessing the Service Catalog, viewing knowledge articles, and taking surveys. These users will have access to anything the System Administrator has configured, that doesn’t require any specific role to access. These are often referred to as self-service users.
As a System Administrator, you will need to know how to impersonate other users for testing purposes (účely).
the admin or impersonator role can impersonate other users.
the impersonator can:
* Access exactly what that impersonated user can access (applications, modules, data)
* Test what different users can do in ServiceNow
When you impersonate a user with an application-specific admin role, you cannot access features granted by the application admin role, including security incidents, profile information, or other scope-protected features, unless you already have those roles. Access to modules and applications in the Filter navigator is also restricted (obmedzený). Admins cannot change the password of any user with an application admin role.
Impersonation TIP: It is recommended to create logins for the following roles to effectively test the system
- admin – to do work
- itil – to test as a process user
- ess(employee self service) – to test as an end user
NOTE: Impersonations are logged in the System Log. The sys_property glide.sys.log_impersonation
needs to be added and set to true in order to see impersonation events in the System Log. This log file enables (true) or disables (false) impersonation logging for interactive sessions.
Persona Types in the Platform
System Administrator
Specialized Administrator
Process User
Approver
Requester
Ak nieco pridas do noveho tabu, napr rolu v grupe, musis refresnut stranku, a to takto:
Note: You may need to Reload the form or right-click in the Related list header, then select Refresh List.
COE je skratka pre Center of Excellence
COE is an abbreviation for Center of Excellence
