Description

ServiceNow User–Admin Configurations

ServiceNow user-administration revolves around controlling who can do what within the platform. These configurations ensure proper access, governance, security, and workflow routing.

1. Users

Users represent individual people who interact with ServiceNow. Each user record includes identity and access attributes.

Key User Attributes

1. User ID / Username
2. Password (managed via SSO or local authentication)
3. Email, Phone
4. Department, Location
5. Manager
6. Time zone & language
7. Assigned Roles
8. Group Memberships

Common Admin Tasks

1. Creating or importing users (manually or via LDAP/SSO)
2. Assigning roles directly
3. Adding/removing users from groups
4. Enabling/disabling users
5. Setting preferences (language, time format)

2. Groups

Groups are collections of users used for access control and workflow assignments.

Typical Group Types

1. Assignment Groups (e.g., Service Desk, Network team)
2. Approval Groups
3. Change Advisory Boards (CAB)
4. Security/Access Control Groups

Groups Include

1. Group name & description
2. Members (users)
3. Group managers
4. Roles assigned to the group
5. Workflows they participate in (assignment rules, routing)

Best Practice

Assign roles to groups, not individual users.

→ Easier governance and onboarding/offboarding.

3. Roles

Roles define what a user can access or perform.

Types of Roles

1. Base Roles – e.g., itil, catalog
2. Admin Roles – e.g., admin, security_admin
3. App-Specific Roles
4. Custom Roles (created per business needs)

Role Behavior

Roles grant:

1. Permissions (CRUD on tables)
2. Application/module visibility
3. UI actions, client scripts, server code execution
4. Access to APIs and platform features

Role Assignment Methods

1. Directly on the user record
2. Indirectly through Groups
3. Inherited through parent roles

4. Access Control Rules (ACLs)

ACLs ensure data-level security.

ACL Components

Each ACL rule may specify:

1. Object type (record/table, field, script, processor)
2. Operation (read, write, create, delete)
3. Condition (must match)
4. Role requirement (roles allowed)
5. Script (optional advanced logic)

ACL Example:

Only users with the role itil can write to incident.state.

5. SSO, LDAP, and Authentication Integrations

User authentication often comes from external identity providers.

Supported Methods

1. SSO / SAML
2. OAuth 2.0
3. OpenID Connect
4. LDAP integration
5. Multi-Factor Authentication (MFA)

Admin Responsibilities

1. Configure identity providers
2. Manage user provisioning (automation)
3. Test login behavior & session policies

6. Delegation & Impersonation

Delegated Development

Allows controlled access to scripts and application configuration without full admin role.

Impersonation

Admin can impersonate users to test permissions and workflows.

Only users with the admin role can impersonate.

7. User Criteria (Service Catalog, Knowledge, etc.)

User Criteria restrict visibility of:

1. Catalog items
2. Knowledge base articles
3. Service Portal pages
4. Workspaces

Criteria can be based on:

1. Roles
2. Groups
3. Departments
4. Locations
5. Users

8. Onboarding/Offboarding Automation

Admins often configure:

1. Role provisioning workflows
2. Dynamic group assignment rules
3. HR-driven user creation & deactivation

Automation reduces manual errors in access management.

Summary Table