Granular Admin Roles in Australia: Precise access control for a platform that's moving fast

[maucblancha]

For some time, the answer to "what privileges should an agent be built with?” was often the same uncomfortable shrug: assign admin or itil_admin, and accept the overage. It worked, but it left a trail of over-permissioned users and every one of those excess permissions is a surface area you didn’t need to create.

That changes now. With the Australia release, ServiceNow is introducing 300+ new task-based, granular admin roles across the platform purpose-built to replace broad admin access for specific functions, with no admin role required. 

The Architecture Shift You Should Understand

This isn’t just a new feature drop. It reflects a deliberate platform direction: future product releases will not build new capabilities on top of admin permissions. That’s a meaningful architectural signal. The organizations that start adopting granular roles now will be aligned with where the platform is heading. 

There’s also an AI-specific reason this matters urgently. An over-privileged agent doesn’t just make a mistake once — it does so at machine speed across every task it executes. As autonomous AI agents inherit user permissions on the platform, admin over-permissioning stops being a configuration debt and becomes an operational risk. Granular role remediation should be a hard dependency in your Australia upgrade project plan. 

What's New: The Roles

Before Australia, most administrative responsibilities were handled through broad roles like admin, itil, or itil_admin, which routinely resulted in users holding far more access than their job required. The new granular roles move the platform toward module-specific access control. 

ITSM - A Closer Look: How We Broke Down Incident Management

To illustrate what this looks like in practice, take Incident Management. What was previously managed through a single admin or itil_admin assignment is now divided into purpose-built roles: 

• sn_incident_admin — configures incident settings and properties 

• sn_mim_admin — manages Major Incident Management rules and escalation criteria 

• sn_tcm_admin — handles task communication plan setup 

• sn_iam_admin — manages stakeholder communications during incidents 

• sn_contact_admin — manages contacts and recipient groups 

• sn_task_outage_admin — controls task-to-outage record relationships 

Change Management follows the same pattern: sn_change_admin replaces broad itil access for change configuration, containing sn_change_writer, change_manager, and sn_change_cab.cab_manager. This is one module, the same decomposition applies across 300+ roles shipping in Australia. 

Platform Security Roles

The granular role model extends across platform security as well. A sample of what’s available: 

Product Area	Role	Purpose
Adaptive Authentication	adaptive_auth_admin	Configure adaptive authentication policies
Encryption / KMF	sn_kmf.admin	Admin access to key management; assign cryptographic manager/auditor roles
Encryption / KMF	sn_kmf.cryptographic_manager	Read, write, and execute permissions for key operations
Identity Center	privileged_role_config_admin	Manage role configurations in Identity Center
Identity Center	user_login_history_viewer	View login history, timestamps, IP addresses, login status
Machine Identity Console	mi_admin	Manage machine identities interacting with systems and data
ServiceNow Vault	sn_vault_console.vault_console_admin	Collection of Data Classification, Data Privacy, and CA Admin roles
ServiceNow Vault	sn_vault_console.vault_console_auditor	View policies and metrics across ServiceNow Vault products
SSO (SAML/OIDC)	sso_config_admin	Configure SSO including SAML and OIDC
System OAuth	oauth_admin	Configure all OAuth-related inbound and outbound authentication
AI Agent Identity	agent_role_config_admin	Configure and manage AI agent access during agentic workflow execution
Security Center	sn_vsc.security_center_admin	Access Security Center consoles, create and manage security tasks

The full list is available in your instance under User Administration > Roles, where each role includes a description of its purpose and permissions. 

A New Role Worth Calling Out: instance_operator

Alongside the feature-specific granular roles, Australia introduces instance_operator, a role built for the people who keep instances running day to day without needing structural access. 

The instance_operator role is designed for users who handle routine operational tasks: checking logs, diagnosing problems, and keeping workflows running. Critically, it does not grant scripting access, the ability to modify flows or code, or the ability to assign roles or modify access. It contains identity_access_audit_viewer and user_role_history_viewer out of the box. 

In practice, this means your ops team can do their jobs without holding admin. That's a meaningful reduction in standing privilege for a user population that historically had few alternatives to the full admin role. 

How to Get Started

1. Review your current admin role assignments. Identify users in your instance with the admin role and evaluate whether they actually need full administrative access. 

2. Explore the Granular Role Documentation to view the list of new granular roles available in your instance from the ServiceNow Australia release. Each role includes a description of its purpose and permissions.  

3.Assign appropriate roles. For each user with admin access: 

• Determine which specific features they actually use 
• Assign the corresponding granular roles 
• Remove the admin role if full administrative access is not required 

Note: Before removing admin access, validate that users can perform all required tasks with their new granular roles by testing in a sub-production environment.  

4. Consider the instance_operator Role. 

For users performing routine operational tasks, evaluate whether the instance_operator role meets their needs instead of admin access. 

What Stays the Same

Adoption is encouraged, not mandatory. If you choose not to implement granular roles, your instance will continue to function normally no features break, no access changes. Existing admin users retain all current access. But every admin assignment that could be a granular role is a missed opportunity to strengthen your security and on a platform that is increasingly running autonomous agents, that calculus is changing. 

Availability

Granular Admin Roles GA in the first week of May 2026 and apply to all customer environments: GCC, NSC, SPP, AU, Singapore, and self-hosted. Your instance must be on the Australia release or higher to use granular admin roles.  

For additional guidance, review KB2773087 and  

Granular admin role documentation. 

Have questions about mapping your current admin roles to the new granular model? Drop them in the comments.