Servicenow To Azure Devops

Servicenow To Azure Devops

Reading time1 min
#Automation#Cloud#DevOps#ServiceNow#AzureDevOps#ITSM

ServiceNow ↔ Azure DevOps: Practical Integration for Automated ITSM-to-Dev Ticket Flow

Workflow fragmentation between IT Service Management and engineering remains a chronic source of latency. When a P1 incident originates in ServiceNow but sits idle until it’s manually copied to Azure DevOps, expect bottlenecks—especially with enterprise change velocities. The obvious solution: Remove that human middleware entirely.

Below: Hard-wired approaches for synchronizing ServiceNow with Azure DevOps. Direct triggers, REST API handling, and Power Automate–backed orchestration covered, including caveats from real deployments.


Problem

Incidents, problems, and changes logged in ServiceNow rarely travel at the speed business demands. Developers deal only with Azure DevOps; operations stick to ServiceNow. This division breaks traceability:

Incident in ServiceNow ──X──> Azure DevOps Work Item (missed, inconsistent, delayed transfer)

Consequences:

  • Slow incident-to-fix cycle times.
  • Poor visibility into what’s being worked on.
  • Error-prone handoffs; status diverges between systems.

There’s no value in synchronized chaos.


Essentials for Connecting ServiceNow to Azure DevOps

Expect friction with permissions and versioning. Before scripting, verify:

RequirementServiceNow (e.g., Tokyo)Azure DevOps (cloud)
API/V2 Table API enabledYesn/a
Integration User with rest_api roleRequiredn/a
Work Item API Access (v6.0+)n/aMust generate PAT (project scope)
Middleware (optional, but helps)IntegrationHub, Scripted RESTPower Automate, Logic Apps
  • Note: OAuth2 recommended for production but many start with username/password due to legacy custom table permissions.

Step 1: Permissions and API Setup

ServiceNow preparation

  • Create a service user (e.g., svc_integration).
    • Assign rest_api_explorer and table-appropriate roles (incident_admin or similar).
    • Use “REST API Explorer” in ServiceNow (instance > /now/nav/ui/classic/params/…).
  • Test API endpoint:
    curl -u svc_integration:changeme \
      "https://yourinstance.service-now.com/api/now/table/incident?sysparm_limit=1"
    
    Watch for errors like:
    HTTP/1.1 401 Unauthorized
    

Azure DevOps setup

  • Under "User Settings" > "Personal Access Tokens" (PAT)
    • Grant Work Items (Read & Write) and (optionally) Project & Team.
    • Store PAT securely; consider using Azure Key Vault or a variable group in pipelines.

Step 2: Determine Triggers and Data Mapping

  • Common scenario: Incident created (state=new) or escalated in ServiceNow auto-creates a work item (Bug or Task) in Azure DevOps.
  • Edge: Also sync status: if DevOps closes the bug, ServiceNow incident moves to ‘Resolved’.
ServiceNow FieldAzure DevOps FieldExample Mapping
numberSystem.Title"INC123456: Short Description"
descriptionSystem.DescriptionFull incident text
priorityPriority tagMap levels; beware mismatches
sys_idCustom field/linkBacklink for auditability

Gotcha: Some ServiceNow fields (HTML, reference values) don’t serialize cleanly into DevOps. Data translation layer likely required.


Step 3: Integration Options

Option A – Power Automate (Low-code, good for prototyping)

Flow outline:

  1. Trigger: HTTP Webhook from ServiceNow Business Rule or Table API subscription.
  2. Action: HTTP GET against incident record (for richer field data).
  3. Action: “Create a Work Item” in Azure DevOps.
  4. (Optional): Update ServiceNow’s incident with Work Item link.

Sample Power Automate Expression:

incident.fields.number → Azure DevOps "System.Title"
incident.fields.description → "System.Description"
incident.fields.sys_id → CustomField (track round-trip)

Known issue: Power Automate’s ServiceNow connector is less reliable; HTTP connector is safer for critical paths.

Option B – Direct REST API Scripting (Fine-grained, production-ready)

Python (requests ≥ 2.25 recommended):

import os, requests, json

# Credentials (use environment vars in production)
SN_INSTANCE = os.getenv('SN_INSTANCE')
SN_USER = os.getenv('SN_USER')
SN_PASS = os.getenv('SN_PASS')
ADO_ORG = os.getenv('ADO_ORG')
ADO_PROJECT = os.getenv('ADO_PROJECT')
ADO_PAT = os.getenv('ADO_PAT')

def get_new_incidents():
    r = requests.get(
        f"{SN_INSTANCE}/api/now/table/incident?sysparm_query=active=true^state=1",
        auth=(SN_USER, SN_PASS)
    )
    r.raise_for_status()
    return r.json()['result']

def create_ado_work_item(title, desc):
    url = (f"https://dev.azure.com/{ADO_ORG}/{ADO_PROJECT}/_apis/wit/workitems/$Bug"
           "?api-version=6.0")
    headers = {
        "Content-Type": "application/json-patch+json",
        "Authorization": f"Basic {os.environ['ADO_PAT_B64']}",
    }
    data = [
        {"op": "add", "path": "/fields/System.Title", "value": title},
        {"op": "add", "path": "/fields/System.Description", "value": desc},
    ]
    resp = requests.post(url, headers=headers, data=json.dumps(data))
    if resp.status_code == 203:
        print("PAT missing required scopes")
    resp.raise_for_status()
    return resp.json()

if __name__ == "__main__":
    for inc in get_new_incidents():
        title = f"{inc['number']}: {inc['short_description'][:80]}"
        description = inc.get('description', 'No description')
        created = create_ado_work_item(title, description)
        print(f"{inc['number']} → ADO Bug #{created['id']}")

Non-obvious tip: Store the cross-system link in both systems (external_id in DevOps; journal field in ServiceNow). This enables reconciliation later.


Step 4: Test and Validate—End to End

  1. Open a test incident in ServiceNow (manually or via API as below):
    curl -u svc_integration:changeme \
    -X POST "https://instance/api/now/table/incident" \
    -H "Content-Type: application/json" \
    -d '{"short_description":"Test – API integration"}'
    
  2. Confirm an Azure DevOps bug or task appears within seconds, with mapped fields.
  3. Change the status (“Resolved”) in Azure DevOps. Validate: ServiceNow should be auto-notified.
  4. Check for edge errors:
    • 400 Bad Request from DevOps API: often field mismatch or missing required fields.
    • Field mapping failures—fields not exposed via ServiceNow’s API due to ACL restrictions.

Beyond the Basics: Expand and Harden

  • Two-way status sync: Use Azure DevOps service hooks or polling.
  • Security: Never hardcode secrets in scripts; rotate PATs every 90 days.
  • Add links, attachments, custom field propagation (trickier, recommend scheduled sync jobs).
  • For high reliability, implement error retries and store integration logs.

Note: Power Automate scales poorly above a few dozen items per hour. For high-throughput or regulated environments, implement your own robust integration microservice.


Final Remarks

Automating ServiceNow-to-DevOps flow eliminates a long-standing blind spot in ITSM/DevOps processes. Outages, change requests, and escalations move instantly from ops intake to engineering resolution—no more email shuffling. Strong bi-directional links also streamline audits and RCAs.

There’s always room to optimize, but getting the API handshake right and field mapping consistent is the bulk of the work. For non-trivial enterprise scenarios (multi-project, extra compliance), plan for ongoing monitoring and traceability.

For reusable scripts, API postmortems, or advice on locking this down in production: raise an issue or get in touch.