The AutoElevate + ServiceNow integration enables automated ticket creation and updates in ServiceNow when privilege elevation events occur on managed endpoints. This eliminates manual ticket creation, improves auditability, and ensures all elevation activity is tracked within your service desk workflow.

This integration is outbound-only, meaning AutoElevate sends ticket data to ServiceNow for visibility and tracking, but approvals must still be performed within AutoElevate.

What the Feature Is

The integration connects AutoElevate with ServiceNow to automatically create and maintain tickets for elevation activity.

Ticket Types Created

Elevation Request

• Triggered when a user requests administrative rights
• Includes application metadata (name, vendor, hash, path) and security posture

Elevated Session

• Triggered when a temporary elevation session is granted

Ticket Updates

• The ticket state is updated based on technician actions
• Work notes are appended for approvals/denials
• Assigned To is automatically populated when a technician's email matches a ServiceNow user

Data Included in Tickets

• Short description (request summary)
• Structured description including:
  • Admin Portal link
  • End-user justification
  • Device and user details
  • Application metadata
  • Security check results (e.g., AV status, publisher verification)

ServiceNow OAuth Setup

Complete the initial setup with the integration user holding the admin role, then reduce it to least privilege once setup succeeds. The setup wizard's initial reads (categories, states, assignment groups) require elevated access to complete; once the integration is configured, its ongoing ticket create/update operations run correctly under the scoped, least-privilege permissions described below.

In short:

Phase 1 — Initial setup: temporarily assign admin to the integration user and complete the AutoElevate setup wizard.

Phase 2 — Reduce to least privilege: once setup is working, remove admin and apply the scoped role below for ongoing operation.

Reference only: The ServiceNow-side security guidance below is a reference suggestion. If you already operate ServiceNow, apply your own organization’s security policies — this section documents the minimum access the integration actually uses.

Before you begin

You will need:

• ServiceNow admin access to create a role/user, register an OAuth application, and complete the initial setup. The integration user itself holds admin only during Phase 1 setup and is reduced to least privilege afterward.
• A ServiceNow release that supports the OAuth 2.0 Client Credentials grant (Tokyo or later).
• A dedicated integration user to act as the OAuth Application User. Because every ticket AutoElevate creates is attributed to this account, a dedicated user keeps your audit history clear.

Required permissions at a glance

The reference fields AutoElevate stamps on a ticket — company, location, cmdb_ci, assignment_group, assigned_to — only require write access to the ticket table's fields. They do not require write access to those referenced tables. Read access to those tables is needed only for the matching lookups above.

Step 1 — Create a dedicated integration user

1. In the filter navigator, go to User Administration → Users and click New.
2. Create a user such as autoelevate.integration. Mark it as a Web service access-only / non-interactive service account if your policies allow.
3. For initial setup only, assign the admin role to this user. You will remove it in Step 4 after setup succeeds.
4. Save the user.

Step 2 — Register the OAuth application

1. Go to System OAuth → Application Registry and click New → Create an OAuth API endpoint for external clients.
2. Give it a name (e.g. AutoElevate Integration).
3. Enable the Client Credentials grant type.
4. Set the OAuth Application User to the integration user from Step 1.
5. Set the Auth Scope to useraccount. This is required — without a scope, the issued token has no scope and every setup read (categories, states, assignment groups) fails with an authorization error, even when the user's roles are correct.
6. Save, and note the Client ID and Client Secret for the AutoElevate setup screen.

Important: Copy the Client Secret before leaving the screen. ServiceNow will not display it again after you navigate away; if you lose it you must generate a new one.

Step 3 — Complete the AutoElevate setup (Phase 1, with admin)

With admin assigned to the integration user, complete the AutoElevate ticketing setup wizard — save credentials and configure your Category, Assignment Group, States, and Ticket Defaults. Confirm the setup dropdowns populate and a test ticket is created. Once setup is working, continue to Step 4 to reduce permissions.

Step 4 — Reduce to least privilege (Phase 2)

After setup succeeds, remove the temporary admin role from the integration user and apply one of the two scoped options below. Most customers should choose Option A.

Option A — Assign the itil role (recommended, simplest)

Assign the out-of-box itil role to the integration user. This covers all the reads and the create/write access the integration needs for the incident, change_request, and sc_task tables, and it correctly handles ServiceNow's built-in field-level protections (so fields like short_description and description populate on create).

It is broader than the strict minimum, but it is the fastest, most reliable path, and still avoids admin.

Option B — Create a custom least-privilege role (strictest)

If you prefer to grant the absolute minimum:

1. Create a custom role, e.g. u_autoelevate_integration.
2. Grant read (via ACLs) on: sys_choice, sys_user_group, sys_user, core_company, cmn_location, cmdb_ci.
3. Grant create + write on the single ticket table you will use (e.g. incident).
4. Important: table-level write alone does not override ServiceNow's out-of-box field-level write ACLs. To populate protected fields such as short_description, description, and assignment_group, add field-level write ACLs for those fields on your ticket table. Without them, tickets are created, but those fields come through blank.
5. Assign the custom role to the integration user.

Trade-off: Option A (itil) is simple and populates everything. Option B is strictly minimal but requires the extra per-field write ACLs above and more ongoing upkeep.

After applying the scoped role, re-run a test elevation to confirm the integration still creates and updates tickets under least privilege (see Verification).

Warning: Once the integration user is at least privilege, editing the integration in the AutoElevate Admin Portal will fail with an authorization error, because reconfiguring re-reads ServiceNow (categories, states, assignment groups), which requires elevated access. Before making changes to the setup, temporarily reassign the admin role to the integration user, then reduce it back to least privilege when done.

Choosing your ticket table

AutoElevate can target incident, change_request, sc_req_item, or sc_task. We recommend incident.

Company, location, computer, and user linking

AutoElevate records are linked to their ServiceNow counterparts from the AutoElevate Admin Portal. Link in this order: Company first, then Location (if used), then Computer — a computer cannot be linked until its company (and location, when applicable) is linked. Company and User records may link automatically once a matching record exists in ServiceNow; check the "Linked to Ticketing System" column and link manually if they have not.

• Company (link first). Links to a ServiceNow company (core_company; requires read access):
  1. Make sure a company with a matching name exists in ServiceNow.
  2. In the AutoElevate Admin Portal, go to Companies (select the correct Distributor / MSP at the top if you manage more than one).
  3. Tick the checkbox next to the company, open the actions menu (the + button above the list), and choose Ticketing System → Link.
  4. Select the matching ServiceNow company and confirm. The "Number of Linked" column updates; use Ticketing System → Remove Link to undo.
• Location (link second, if used). Links to a ServiceNow Location (cmn_location; requires read access). After the company is linked, open the company\u2019s Locations in the AutoElevate portal, select the location, and use the same Ticketing System → Link action to pick the matching ServiceNow location. An unlinked location leaves the ticket\u2019s Location field blank; tickets are still created.
• Computer (link last). Links to a Configuration Item (cmdb_ci; requires read access) and requires the company — and location, when used — to be linked first. Go to Computers, tick the computer, open ACTIONS → Link, and select the matching CI. Applies to incident and change_request tickets; an unlinked computer leaves the Configuration Item field empty.
• User. Users are normally matched automatically by email to a ServiceNow user (sys_user; requires read access) — the requester on the ticket, and Assigned To when a technician\u2019s email matches. If a user has not linked automatically, go to Users, select the user, and use ACTIONS → Link to pick the ServiceNow user manually.

What NOT to grant

• Do not leave admin or security_admin assigned. admin is used only for the one-time Phase 1 setup and must be removed once the integration is working — the integration never needs platform administration for ongoing operation.
• No delete permission anywhere — AutoElevate never deletes records.
• No write access to sys_user, core_company, cmn_location, cmdb_ci, or sys_user_group — These are read-only lookups.
• No attachment permissions — the integration does not upload attachments.

Verification

1. In AutoElevate's ServiceNow setup screen, enter your instance URL, Client ID, and Client Secret and save. If the category/state/urgency/impact / assignment-group dropdowns populate, your read access and OAuth are working.
2. Trigger a test elevation request and confirm a ticket is created in your configured table (for Incident, look in incident.list). This verifies creation.
3. Approve or deny the test request and confirm the ticket's state updates and that a work note is added. This verifies write/update and the end-to-end flow.

AutoElevate Admin Portal Setup

Note: If your integration user is already at least privilege, reassign the admin role before editing this setup, or the wizard will return an authorization error.

Accessing the Integration Setup

• Navigate to the AutoElevate Admin Portal
• Open Ticketing System Setup
• Select ServiceNow

Step 1 — Host Info

• Enter:
  • ServiceNow Instance URL
  • Client ID / Client Secret from the OAuth setup
  • Select Target Table

Target Table Options

Incident (recommended)

• Best for standard help desks
• Supports Category, Urgency/Impact, CI mapping

Service Catalog Request Item (sc_req_item)

• Best for approval-based workflows
• No CI mapping; category behavior differs

Change Request

• Used for formal change management
• Uses Risk instead of Urgency

Service Catalog Task

• Task-based workflows
• Does not use Category or Urgency/Impact

Step 2 — Category & Assignment Group (Optional)

• Configure defaults for:
  • Category
  • Assignment Group

Example Use Case:
Assign all elevation tickets to a Tier 2 security team automatically.

Step 3 — State Mapping

Map each AutoElevate outcome to a ServiceNow state:

• New
• Approved (one-time)
• Approved (rule created)
• Denied (one-time)
• Denied (rule created)
• Client follow-up required
• Completed

Best Practice:
Align these mappings with your ticket lifecycle (e.g., “In Progress”, “Resolved”, “Closed”).

Step 4 — Ticket Defaults (Optional)

• Configure Urgency and Impact per ticket type

Note:

• In Incident tables, Priority is derived automatically
• Leaving fields blank uses ServiceNow defaults

Step 5 — Time Entry Duration Override

• Default: 15 minutes logged per approval/denial
• Customize or set to 0 to disable time logging

Advanced Use Cases

Security Auditing

Track all elevation activity in ServiceNow for compliance and auditing

Automated Workflow Routing

• Route tickets to different assignment groups based on category
• Integrate with escalation policies

Change Management Integration

• Route elevation requests through Change Request workflows
• Apply approval gates for high-risk actions

Multi-Tenant MSP Environments

• Match AutoElevate company names to ServiceNow companies
• Ensure proper ticket association

Best Practices

• Use a dedicated integration user in ServiceNow
• Grant least privilege access:
  • Write access to ticket tables
  • Read access to lookup tables (users, groups, companies)
• Standardize company names across platforms
• Start with the Incident table for the initial deployment
• Test using a sandbox environment only

Troubleshooting

Empty category / state / urgency / impact / assignment-group dropdowns    

• Missing read on sys_choice and/or sys_user_group
• The OAuth app is missing the useraccount Auth Scope
  "Please verify that the OAuth application has the correct scopes configured."    
• The OAuth Application User is missing a required read role/ACL, or the Auth Scope is not set to useraccount

Ticket created, but company / location / CI / assignee blank    

• Missing read on core_company / cmn_location / cmdb_ci / sys_user respectively (ticket creation still succeeds)
   

Ticket created, but short_description / description blank    

• Field-level write ACLs missing (Option B) — assign itil or add the per-field write ACLs
   

Ticket creation fails (403 / ACL error)    

• The integration user lacks create/write on the configured ticket table
   

Token request fails (401)    

• Client ID/Secret mismatch
• Client Credentials grant not enabled
• No OAuth Application User set
   

Ticket created but never closes / no work note on a Change Request    

• ServiceNow's Change state model is rejecting the direct state change — use the incident table instead

Tickets not creating

Verify the Client ID/Secret, confirm the integration user has create/write on the configured ticket table, and check that the instance URL is correct.

Company not matching

Ensure an exact company-name match between AutoElevate and ServiceNow.

Known Behavioral Considerations

• Priority (Incident) is derived from Urgency + Impact
• Caller field only populates when a matching user exists
• Service Catalog Request Item does not support category selection
• Change Requests use Risk instead of Urgency
• Service Catalog Tasks use Priority directly (not set by integration)

Related Articles

• https://support.cyberfox.com/ 
• https://support.cyberfox.com/en_US/integrations 
• https://support.cyberfox.com/en_US/ae 
• https://support.cyberfox.com/en_US/115000883932-PSA-Ticketing-System-Integrations