Azure DevOps and ServiceNow Integration

Teams running ServiceNow for ITSM workflows often need to hand off work to engineering squads operating in Azure DevOps. Connecting both teams with an integrator eliminates duplicate data entry, missed updates, and frustrated teams copy-pasting the same info into two systems.

Exalate handles the heavy lifting of setting up a ServiceNow Azure DevOps integration, whether you're on ServiceNow's cloud instance or working with Azure DevOps Services and Azure DevOps Server. Both platforms can talk to each other in real time, with you deciding what flows where and under which conditions.

Exalate Ramp-up and Configuration Steps

Here's how to integrate Azure DevOps and ServiceNow.

Create an Account or Log In to an Existing Account

1. Go to the Exalate app.
2. Sign up using Google (SSO) with a business email, or roll your own account.
3. Click Create an account and enter your details (business email, first name, last name, strong password).
   
4. Confirm your password and click Create an account to keep going.
5. Verify your email: check your inbox for a verification message from New Exalate. Heads up: the verification link expires after 2 hours.
6. Click the link in the email. You'll land on a page to finish your account setup.
7. Log in to New Exalate using your email and password.

Create a Connection Between ServiceNow and Azure DevOps

1. Log in to your account.
2. Click Add Connections > Create New Connection.
3. An installation wizard pops up to walk you through the setup.
4. To configure System A (ServiceNow):
5. 1. Paste in the system URL [https://yourinstance.service-now.com].
   2. A console status check fires off automatically.
   3. If the system is already in your workspace, you'll get a confirmation and can skip authentication.
   4. If it's a fresh system, authentication fields appear automatically.
   5. Provide your ServiceNow username and password (or use OAuth if your setup requires it).
   6. Click Check Authentication and wait for validation. Once it's good, the Next button activates.
      
      
6. Click Next to move to System B (Azure DevOps), and repeat the same flow:
7. 
   
   1. Drop in the system URL for your Azure DevOps organization.
   2. Wait for automatic system type detection.
   3. Provide your Personal Access Token (PAT) with the right scopes.
   4. Click Check Authentication to verify.
   5. Click Next to keep going.
8. Give your connection a unique, descriptive name. If the name is already taken, you'll get prompted to pick another.
9. Add a short description that flags the connection's purpose, like "Sync incidents and stories between ServiceNow IT and Azure DevOps engineering."
10. Click Next to review all the details you’ve added.
11. Look over the details of your connection. Double-check the name and description.
12. Click Create Connection to kick off the setup.
13. Exalate registers your systems automatically and gets the connection ready. You'll see real-time updates while it works. Once it wraps up, you'll see a success message.
14. Click Continue to Configuration to proceed.
15. After your connection is created, pick which projects to sync between your systems.

Configure Your Bidirectional ServiceNow Azure DevOps Connection

You've got two paths here: Quick Sync and Edit & Test.

The Quick Sync option syncs a single item between your systems.

1. Under the "Item sync monitor," paste in the work item key and click Sync Now.
2. To link 2 existing items, click Link with existing.
   
   

Once the sync finishes, both items pop up in a new window. You can also compare changes if needed.

To use the Edit & Test Sync option, follow these steps:

1. Open your console and find the connection in the Connections list.
2. Click on the connection name or click the Edit button to load the configuration page.
3. Once you're on the configuration page, you'll see the current sync rules.
4. To make changes, create a new version or pick Open latest draft. That way, you don't mess with the live configuration.
   
   
5. Click the Edit button to open the editor:
6. 
   

   • Edit sync rules using Aida (the outgoing script holds the values passed from ServiceNow to Azure DevOps, and the incoming script defines how values from Azure DevOps get mapped in ServiceNow).

   • Click Save Script to save the version or Start Test Run to try out your setup.

7. Click Publish Version when you're ready to push the configuration live.
8. Click the icon to flip direction if you want to tweak the sync rules for the opposite flow (for example, the incoming script of ServiceNow and the outgoing script of Azure DevOps). This creates a new version (or draft) for that direction, which also needs review and publishing.
   
   
9. All configuration versions for a connection sit under the Version dropdown below the connection name.
10. Versions can have these statuses:
11. 
    

    • Active: The currently published configuration.

    • Draft: An editable copy of the Active version.

    • Archived: When a new version is published, the previous Active version gets archived. Restore an archived version by selecting Restore version.

AI-Assisted Configuration with Aida

1. Open your connection.
2. Click Add new version (or open the latest draft).
3. Click Edit to bring up the script editor.
4. In the Aida input field, type out your request in plain language.
5. Click the send button (or click Enter).
   
   
6. Aida starts drafting your script.
7. Review the suggested changes. Green highlights mark new lines being added, red highlights show lines being removed.
8. Click Insert to accept or Discard to reject.
   • For Outgoing scripts: describe what data should leave your system. For example, "Only sync incidents with priority 1".
   • For Incoming scripts: describe how incoming data should land in your system. For example, "Map priority values".

Test Run: Validate Before Production

Once your sync scripts are good to go, click "Start Test Run" to validate them.

1. Pick the items you want to test (multi-select works). Click "Start Test Run" to preview how the configuration behaves.
   
   
2. Review incoming and outgoing replicas for each test item. Verify field mappings look right. If something's off, jump back, adjust scripts, and test again.
3. Deploy only when you're confident things work end to end. Click "Publish Version" to push the updated configuration to live sync.

Automate ServiceNow Azure DevOps Integration Using Triggers

Triggers decide which items sync automatically based on conditions you define.

1. Click "+ Add trigger" to create a new one.
2. Add trigger conditions using platform-specific syntax.
   • ServiceNow encoded query:  assignment_group.name=Network Support^priority<=2
   • Azure DevOps WIQL: [System.WorkItemType] = 'User Story' AND [System.State] = 'Active'
3. Activate triggers by toggling them on. Save changes by publishing.

Troubleshoot with Aida

1. Navigate to the “Troubleshooting” tab in your workspace.
2. Hover over any error and click the Aida icon for immediate analysis. Aida shows affected systems, connections, and work items, plus a brief explanation of the error.
3. For deeper investigation, click “Error Details” to view the impact level, stack trace, error type, and occurrence date.
   
4. Use “View Full Analysis” for complete context. Once you’ve resolved the issue, click “Resolve” to clear the error.

Your integration is now active. Synchronization runs automatically based on your configured sync rules and triggers.

Advanced ServiceNow and Azure DevOps Integration Use Cases (Using Aida)

Exalate provides Script Helpers to save you setup time when building connections from scratch. Exalate also supports AI-powered ServiceNow integration with Azure DevOps through the scripting engine in the configuration panel.

Here are some real-world scenarios where ServiceNow Azure DevOps integration pays off.

Use Case 1: Map and Sync Statuses Between ServiceNow and Azure DevOps

When the status of an Azure DevOps work item changes from "New" to "Closed," the corresponding ServiceNow incident state should flip from "Open" to "Resolved." Same logic in reverse, with the right resolution metadata attached when things close out on the ServiceNow side.

A sample prompt to Aida:

Aida should generate something like:

def statusMap = ["New" : "Open", "Done" : "Resolved"]def remoteStatusName = replica.status.nameissue.setStatus(statusMap[remoteStatusName] ?: remoteStatusName)

Click Discard if the generated code is off. If it looks right, click Insert Changes. Once you're satisfied with the script, click Publish to apply changes.

If you also need ServiceNow's mandatory close fields populated when an incident moves to "Resolved," extend the script with close_code and close_notes logic, and store the Azure DevOps work item key in the correlation_id field for traceability:

if (remoteStatusName == "Closed"){ entity.close_code = "Known Error" entity.close_notes = "Closed by Azure DevOps"}entity.correlation_id = replica.key

This pattern works for sending ServiceNow tickets to Azure DevOps (either automatically when assigned to a group, or manually with a "send to Azure" button). It stores the Azure DevOps task link in the SNOW ticket and pushes comments and state changes back to ServiceNow when work wraps up on the engineering side.

Use Case 2: Map and Sync Custom Fields Between ServiceNow and Azure DevOps

Beyond the default fields like summary, description, and status, custom fields on both platforms can sync too. You just need to reference the correct field name through the API.

A sample prompt to Aida:

Aida should generate something like this for the Azure DevOps incoming sync:

workItem.customFields."Contact Name".value = replica.customFields."Contact Name".value

Use Case 3: Sync Urgency and Priority Between ServiceNow and Azure DevOps

Heads up: the priority field is read-only in ServiceNow, which means a direct bidirectional sync on the native priority field won't work. The workaround is to create a custom field in ServiceNow and sync Azure DevOps priority values into that custom field instead.

A sample prompt to Aida:

Aida should generate something like:

replica.customFields."Priority" = workItem.priority

For the outgoing value from Azure DevOps, the priority should be mapped using a clear lookup table:

def priorityMapping = ["1 - Critical": "High", "2 - High": "High", "3 - Moderate": "Medium", "4 - Low": "Low", "5 - Planning": "Lowest"]workItem.priority = nodeHelper.getPriority(priorityName)

Use Case 4: Bidirectional Incident-to-User-Story Sync for IT and Engineering

The IT team uses ServiceNow to track customer-reported incidents and internal escalations. The engineering team works in Azure DevOps Boards. 

1. ServiceNow Requests creates User Stories on an Azure DevOps Board,
2. Updates to an Azure DevOps Work Item update the associated ServiceNow request.
3. Closing the SNOW request closes the Azure DevOps item,
4. and closing the Azure DevOps item closes the SNOW request.

The setup:

• Configure a bidirectional connection between the ServiceNow Request table and an Azure DevOps board.

• On the ServiceNow outgoing side, pass the short_description, description, priority, attachments, and state along with a custom entityType marker so Azure DevOps knows to create a User Story.

• On the Azure DevOps incoming side, map the entityType to a User Story work item type on first sync, then apply the status mapping in both directions.

• Use bidirectional state mapping so "Closed Complete" in ServiceNow flips the Azure DevOps story to "Closed," and a "Closed" Azure DevOps story flips the ServiceNow request to "Closed Complete."

The result: IT and engineering each stay in the system they're comfortable with. Nobody has to update the same thing twice, and resolution status is always in sync across both tools.

Use Case 5: Catalog Item Fulfillment Through Engineering Workflows

Catalog items (like "New environment provisioning" or "Custom integration request") need engineering work to fulfill. The catalog item lives in ServiceNow as an RITM (Request Item), but the actual build happens in Azure DevOps.

The setup:

• Trigger sync when a specific catalog item gets approved in ServiceNow.

• Map catalog variables (requested environment, region, technical specs) to custom fields on the Azure DevOps user story.

• Sync developer comments and status changes back to the RITM so the requester can track progress in the self-service portal.

• When the Azure DevOps story moves to "Done," automatically close the corresponding RITM and trigger a notification to the requester.

Each request kicks off Azure DevOps work spanning network, security, and application teams. With the sync running, the retail operations team places one request in ServiceNow and gets status updates pushed back automatically as each Azure DevOps task wraps up

Use Case 6: MSP Multi-Tenant Operations

For Managed Service Providers running ServiceNow as their central operations hub, the challenge is connecting to multiple client Azure DevOps instances without giving clients access to the MSP's ServiceNow, and without the MSP needing access to each client's Azure DevOps tenant.

The setup:

• MSP runs a single ServiceNow instance connected to 5+ client Azure DevOps organizations.

• Each connection has its own sync rules tailored to that client's workflow.

• Work items sync automatically when clients log requests in their Azure DevOps board.

• Comments and attachments flow bidirectionally, but private comments tagged [INTERNAL] get filtered out before crossing the boundary.

• The unified Exalate console gives the MSP a single pane of glass to monitor all client connections and spot issues quickly.

Sample script for filtering internal comments on the outgoing side:

workItem.comments = replica.comments.findAll { comment -> !comment.body.contains("[INTERNAL]")}

A real-world example: any enterprise MSP running operations for multiple clients across financial services and healthcare uses this exact setup. Tickets enter the help desk in ServiceNow, get routed automatically to client-specific Azure DevOps boards based on assignment group, and resolution updates flow back to ServiceNow in real time. 

Use Case 7: Change Request Management for ITIL Workflows

An enterprise running ITIL change management in ServiceNow needs to coordinate with the DevOps team executing the actual deployment work in Azure DevOps. Not every change record needs to flow to engineering, only the ones tied to deployable code or infrastructure changes.

The setup:

• Sync ServiceNow change records to Azure DevOps only when a custom "Requires DevOps" field is set to "Yes."

• Map ServiceNow Change Request to an Azure DevOps Epic, with ServiceNow Change Tasks mapped to Azure DevOps User Stories or Tasks under that Epic.

• Pass change window timestamps to Azure DevOps iteration paths so deployment work lines up with approved change windows.

• When the Azure DevOps deployment Epic moves to "Done," automatically update the ServiceNow change record state to "Implemented" and capture the deployment evidence (build number, release link) as work notes.

• Aggregate time tracking from Azure DevOps child tasks back into a ServiceNow custom field so change managers have a clear effort picture.

A fintech company running this exact flow tags only about half of its monthly change records as "Requires DevOps." Filtering with conditional sync triggers means the DevOps team only sees the changes they actually need to execute, while compliance and audit teams keep full visibility in ServiceNow.

If you have a specific use case to walk through, book a demo with our integration engineers.

Supported ServiceNow and Azure DevOps Entities

Check out the comprehensive list of supported ServiceNow entities. Some of the most popular ServiceNow entities are incidents, problems, change requests, RITMs, and catalog tasks. Here's the comprehensive list of supported Azure DevOps entities.

Here's a sample mapping between ServiceNow incidents and Azure DevOps work items:

ServiceNow incident <> Azure DevOps work item

• short_description ↔ summary

• description ↔ description

• urgency ↔ priority

• state ↔ status

• caller ↔ assignee

• comments / work notes ↔ comments

• attachments ↔ attachments

• tags ↔ labels

• correlation_id ↔ work item key

• custom fields ↔ custom fields

• any field available via REST APIs

Other Resources

• Start a free trial with Exalate, or book a call with our integration engineers to talk through your use case.

• Using Exalate Classic? View its documentation here. Learn more about the difference between Exalate Classic and New Exalate.

• Visit our Trust Center for more security info.

• Got configuration-related questions? Find answers on the Exalate Community.

• Join our latest Webinar series: The Sync Room, where we dig into integration pain points, the latest AI trends in the integration space, and more.