Servicenow - Azure Devops integration

[AnupKumarM]

As part of our ongoing improvement plan, we are initiating a revamp of the existing integration between ServiceNow and Azure DevOps, beginning with Incident and Problem Management. The objective is to ensure that a corresponding DevOps ticket is automatically created, updated, and closed in alignment with each incident/Problem managed within ServiceNow.

During our evaluation of integration options, we identified a potential enhancement: mapping Assignment Groups in ServiceNow to Projects in Devops (instead of the current mapping to Teams in DevOps). However, this approach presents a limitation—if a ticket needs to be reassigned to a different project, the integration fails to function as expected.

Example: we have an assignment group Service Desk and Cloud support in Servicenow, and we have established the integration where the Assignment groups in Servicenow is mapped to Respective projects in Azure Devops, Service Desk in Servicenow is mapped to Support Desk in Azure Devops and Cloud Support in Servicenow is mapped to Cloud Ops in Azure Devops, 

When the ticket is created in Servicenow and assigned to Cloud support in Servicenow, a Work item bug is created in Azure Devops in Assigned to Cloud support project in Azure Devops, and if we not reassign this work item to Support Desk, the incident in Servicenow does not get assined to Servicedesk, here the integration fails

We would like to understand if you are aware of any solutions or alternative approaches that could help us address or overcome this limitation.

[Vishal36]

Hi @AnupKumarM,

This is a common issue when mapping ServiceNow Assignment Groups to ADO Projects. ADO work items can't easily move between projects, so reassignments in ServiceNow can break the sync. What teams usually do instead:

• Map all groups to one ADO project, use area paths/tags to separate work
• Or use smarter logic that creates a new work item or relinks when assignments change

Things to consider before you begin:

• ADO projects are rigid — switching between them mid-flow causes sync issues
• Syncing by rules (not hard mappings) gives you more flexibility
• You may need audit trails and traceability when reassignments happen

You may consider an automated enterprise - grade, no plugin, no code sync solution, OpsHub Integration Manager (A ServiceNow Partner) that can help you with bidirectional integrations and:

• Define flexible routing logic — not just project-to-group, but based on fields, conditions, and business rules
• Sync across multiple ADO projects without hard coupling
• Maintain traceability even when items are reassigned, split, or closed
• There is free Community edition of OpsHub Integration Manager (OIM) that you can use for your use case without requiring a license

Would recommend thinking beyond strict 1:1 mapping if you want the integration to be more resilient as your processes evolve and scale.

Hope it helps!

[AnupKumarM]

Thank you @Vishal36, Appreciate your reply. However we have a limitation here, we do not have the leverage to use any 3rd party tools

[JavierPM]

Hi @AnupKumarM, I'm the community manager at Exalate.

Since third-party tools aren’t allowed, one workaround could be restructuring the logic to support reassignment — for example, using a routing layer or dynamic mapping when assignment groups change. If the restriction is due to security concerns, it’s worth noting that there are solutions, for example, Exalate can run on-premise within your ServiceNow environment, offering full control over your data while enabling flexible sync between platforms. This could help handle reassignment scenarios without compromising compliance. 

Good luck with the integration!