I wanted to share a real story from a recent client engagement I had. For full transparency, I have partnered with GetInt to write this post. Use the following link to get started with a 30 day trial →
https://marketplace.atlassian.com/vendors/1218845/?utm_source=gated&utm_campaign=organic&utm_content=content
Jira is a great tool for managing work, but I have yet to see an organization that relies on Jira alone. It can handle a lot, but different teams have different processes and preferences, and that usually means using more than one platform.
Project managers might track work in Jira, developers may spend their day in GitHub, GitLab, or Azure DevOps, and IT teams may rely on ServiceNow. Add in the tools used by marketing and HR, and it does not take long to end up with several systems that need to communicate.
Having different tools is not really the problem. The challenge comes when work needs to move between them. Suddenly, people are entering the same information twice, manually updating statuses, or trying to figure out where a request stands. That is when teams start losing visibility and wasting time.
I have run into this situation plenty of times, and I recently worked through it with two teams. Both received requests through Jira Service Management (JSM), but the development team worked in Azure DevOps while the IT Infrastructure team worked in ServiceNow. Each team needed information to stay synchronized without changing the way they worked.
Let me start with the development team. Most customer requests could be handled by a service technician, but some needed to be escalated to a developer. We needed a way to get those requests into Azure DevOps and keep JSM updated as the work progressed.
The tricky part was that JSM and Azure DevOps have different fields, workflows, and ways of managing work. We did not want technicians copying information into Azure DevOps, and we certainly did not want developers jumping into JSM every time something changed.
Getint gave us a way to connect the two. We could synchronize the information that mattered while letting both teams continue using the tools they knew.
Our IT Infrastructure team had a similar requirement. They already had an established process in ServiceNow, even though the company's direction was to move toward JSM. That transition was not going to happen overnight, so we needed to support both systems in the meantime. Fortunately, Getint also supported ServiceNow, which meant we could solve both integration challenges without introducing a second product.
Choosing an Integration Tool
When the teams explained what they needed, I immediately knew we would need a third-party integration tool. Jira can integrate natively with some systems, but not every use case can be solved with built-in capabilities. I tested a few products, evaluating them on three factors: ease of configuration, features, and price.
The first couple of tools were feature-rich, but the setup took time to understand. I ran into a technical problem and submitted a support ticket. Because of the time-zone difference, getting traction took longer than I could afford, so I moved on.
The next product was easier to configure, but the price was higher than the team was comfortable with.
Finally, we installed Getint's Azure DevOps connector for Jira and Getint's ServiceNow integration.
Getting started was straightforward. The videos walked me through the process, and the documentation closely matched what I saw on screen. Azure DevOps took a little longer, but once I had the right Azure administrator on a call, the rest went smoothly. I had access to the ServiceNow administrator from day one, which made that configuration easier. We needed clarification from Getint on certain fields, but after being pointed to the right documentation, it was smooth sailing.
I established the connections, mapped fields and statuses, and configured how comments and attachments would synchronize. About two 30-minute sessions later, I had working proofs of concept ready for the executive team. The pricing also fit the budget.
Let me say that one more time. In about an hour, I had configured working integrations between very different tools using Getint.
The next day, I demonstrated what we had built. The executive team's reaction was extremely positive because we avoided the tool and data disruption they had expected. Instead of asking teams to change platforms, we were creating a bridge between the systems they already used. The important part of that demonstration was not simply showing that data could move from one tool to another. It was showing that each team could continue managing its own work without asking someone to copy updates or constantly check another platform.
Once the proofs of concept were approved, we began preparing for production testing.
Moving from Proof of Concept to Production
Going from a proof of concept to a production-ready integration can be challenging. Because we already had the connections working, our next step was to finalize the requirements and build around them.
First, we needed to control which JSM requests synchronized with Azure DevOps. We did not want every request moving between platforms, only those reviewed and determined to require developer involvement.
To accomplish this, I created an "Escalate to Developer" status in the JSM workflow. Then we configured Getint to listen only for work transitioning into that status. This prevented unrelated requests from synchronizing automatically. It also meant that the service technician could review a request before sending anything to development. That was important because not every customer request needed developer attention, and we did not want to create extra work for a team already managing its own backlog.
For ServiceNow, the requirements were slightly different. We did not need a special status. Instead, we used Getint filters to synchronize only a specific JSM request type mapped to the appropriate work type in ServiceNow. Everything else could be ignored.
Having control over what triggers synchronization is extremely important. Most teams do not want every piece of data copied into another system. They want to decide which records qualify, when they should move, and what information should travel with them.
Mapping Fields Correctly
The next requirement was getting fields from each tool to align. This is critical because you do not want information lost or misinterpreted during synchronization.
This took a couple of working sessions with the platform administrators. Most fields were easy to map, but one behaved differently than expected. I contacted Getint support, and within about an hour I had instructions for providing the logs they needed. By the end of the day, we had resolved the issue and mapped the remaining fields.
Field mapping is not just a technical exercise; it is also a business-definition exercise.
A field with a similar name in two systems may not mean the same thing. "Priority," "Severity," and "Impact" can sound related while representing very different concepts. Before mapping fields, make sure both sides agree on what the data means.
Mapping Statuses and Workflows
Once the fields were mapped, it was time to map statuses.
Technically, this was not especially difficult. The larger challenge was agreeing on which Azure DevOps statuses should influence JSM and which JSM statuses should influence Azure DevOps.
We wanted to keep the experience simple for the customer who submitted the original request, so we synchronized only a small number of meaningful statuses.
Different teams work differently, and you should not have to reproduce the same workflow in both tools. Getint gave us the flexibility to decide which transitions mattered and how each system should respond, without requiring a one-to-one match for every status.
The final piece involved moving the JSM request out of "Escalate to Developer" when the development work was completed. Once the Azure DevOps item reached the appropriate completion status, JSM needed to return the request to the technician for customer follow-up. That was straightforward to configure and gave us the handoff we needed.
On the ServiceNow side, there was considerable overlap between statuses and workflows because JSM and ServiceNow support similar service management processes.
Handling Assignees and Reporters
The next challenge was determining how to handle assignees and reporters.
This is one of the trickier parts of cross-platform integrations because users in one tool often do not exist in the other. Unless you know otherwise, you should assume the user populations will be different.
Getint gives you several options. In our case, we chose a service account and made sure it existed in both systems.
If the same user does not exist in both platforms, you can end up with mismatched ownership information. Depending on your use case, that might be acceptable, or it might create serious reporting and accountability problems. Decide this before building the integration rather than discovering it during testing.
Synchronizing Comments and Attachments
The final configuration involved comments and attachments.
These can be difficult to manage without a dedicated integration tool, so we were happy both were supported. Getint let us decide how information would move between platforms.
For our use case, attachments needed to synchronize from JSM to Azure DevOps and ServiceNow only. We did not want attachments from either external platform flowing back into JSM.
Comments, however, needed to synchronize bidirectionally so conversations remained visible regardless of which tool a team member used.
A few configuration changes later, comments and attachments were syncing exactly the way we wanted.
Testing with Real Production Scenarios
Once the rules were configured, it was time for the fun part: testing.
We created a JSM request and transitioned it into "Escalate to Developer." Within about 180 seconds, the corresponding work item appeared in Azure DevOps with the expected data.
Next, we added an attachment in JSM. It synchronized successfully. We then added an attachment in Azure DevOps, and nothing synchronized back, which was exactly what we expected.
We added comments in both tools and confirmed they synchronized in both directions. Finally, we moved the Azure DevOps work item to Done. As expected, the JSM request transitioned to the correct follow-up status.
For the IT Infrastructure team, we created two JSM requests: one IT Infrastructure request and one unrelated request. Only the IT Infrastructure request synchronized with ServiceNow. We also verified that fields, attachments, reporter information, and comments synchronized according to our configuration.
At that point, both integrations were behaving as intended. The Infrastructure team could continue using ServiceNow while the organization moved toward JSM, and development could keep working in Azure DevOps. We had also tested that the filters were doing their job. Just as important as getting the right information to synchronize was confirming that the wrong information would not move between platforms.
Could we have handled this manually? Yes. Could we have built custom automations and scripts? Probably. But the time, technical expertise, testing, and ongoing maintenance required would have been significant.
Getint allowed us to build functional bidirectional synchronization in a matter of hours rather than building and maintaining custom integrations ourselves.
Best Practices and Lessons Learned
After working with Jira administrators, project managers, developers, service teams, and other Atlassian users, I have learned that the most important integration question is not:
Can these two tools connect?
The better question is:
What should happen between these teams when they need to work together?
Connecting tools should not be the objective by itself. You need to understand how teams expect to collaborate without disrupting their existing flow. You want to eliminate duplicate data, manual work, and unnecessary overhead.
The best integrations are almost invisible to end users. People should be able to work in the tools they already know while the right information stays synchronized behind the scenes.
Understand the Process Before You Configure the Tool
Before integrating platforms, understand how each team expects information to flow.
One of the biggest mistakes is jumping into configuration before understanding the process. Most teams know what they expect from their own tool. Ask them what they expect from another team's tool, however, and the answer is often less clear.
Sit down with each team and map out how they work independently and together. Identify handoffs, document ownership, and clarify what happens when work is rejected, reopened, escalated, blocked, or completed. I would also make sure each team understands what information the other actually needs. It is easy to assume that because a field exists in one system, the other team needs to see it. Often, they do not.
Do Not Synchronize Everything
Only synchronize information that actually needs to move.
Just because a platform allows you to synchronize everything does not mean you should. Unnecessary data creates noise, increases the chance of accidental exposure, and makes troubleshooting more difficult.
I like to approach this using a least-privilege mindset: start with the minimum number of records, fields, statuses, attachments, and comments. Expand only when there is a clear business reason.
Get Stakeholder and Administrator Buy-In Early
Making two platforms communicate creates technical challenges, but it can also create organizational ones.
Stakeholders may question the integration. Security teams may want to understand how data moves. Administrators may hesitate to provide API access. Platform owners may disagree over which system should be the source of truth.
Work through these requirements before configuring production. Determine who approves API access, which account authenticates, who owns the integration, who troubleshoots failures, and who responds when mappings change.
I learned this lesson the hard way. On one project, I personally created the integrations. When the work was nearly complete, the team decided everything needed to be owned by a service account. We had to stop, request the account, obtain permissions, and recreate portions of the integration.
A few discovery questions up front would have saved significant time. Who should own the service account? Who is responsible for API permissions? What happens if an administrator leaves the company? Those might not be the exciting questions, but they become very important once the integration is running.
Start with a small proof of concept in a sandbox or test environment whenever possible. A working demo can make governance and ownership conversations much easier.
Do Not Assume Similar Fields Mean the Same Thing
This was one of the first mistakes I made with cross-platform integrations.
I once assumed the Status field in JSM was equivalent to the status field in another platform. I was wrong. That platform had both a status field and a state field, and state was what we actually needed to map.
Always validate assumptions with administrators from both systems.
For every field, understand its meaning, expected values, and business rules. What happens if one system has a dropdown value the other does not? What if a field is required in one system but optional in the other? Answer those questions before go-live.
Create a Real Testing Plan
Testing an integration can look simple when you only test the happy path. A request is created, it synchronizes, someone updates it, and the update comes back. Great. But production users will eventually do something you did not expect.
Build a plan that covers realistic scenarios, including:
- Reopened work items and deleted records
- Attachments, comments, special characters, and large descriptions
- Missing users, missing fields, and permission failures
- Multiple transitions, simultaneous updates, and duplicate records
Also test what happens when a connected system is unavailable. Does the integration retry or queue the update? Does someone receive an alert? Can you identify failed records?
If you only prepare for the happy path, users will discover the edge cases for you.
Decide Which System Owns Each Piece of Data
When information exists in two tools, someone needs to decide which system is authoritative for each field. Otherwise, two teams may update the same value and unintentionally overwrite one another.
Maybe JSM owns the customer-facing summary and request details, while Azure DevOps owns development status and technical resolution information. Perhaps both systems can add comments, but only one controls priority.
This becomes especially important with bidirectional synchronization because "both directions" should not mean "every field can be changed everywhere."
Monitor the Integration After Go-Live
An integration is not finished the moment it works in production.
Fields and workflows change. Permissions disappear. Accounts get disabled. APIs change. Tokens expire. Someone renames a status the integration depends on. A configuration that worked for six months can suddenly stop because one dependency changed.
Create a simple routine for reviewing integration health. Decide who checks errors, how often logs are reviewed, where incidents are reported, and what support teams need when something fails. It does not need to be a complicated process. It just needs to be clear enough that someone notices when synchronization stops working and knows what to do next.
Plan for API Token Expiration
API tokens expire, and that information belongs in your runbook.
One of my biggest lessons involved an integration whose API token was configured to expire after 365 days. I left the project a few months after go-live. About a year after the original setup, I received a call saying the integration had stopped working.
The service account owner had left the company, which made recovery more complicated. We eventually regained access and renewed the token, but better documentation could have prevented the incident.
Define how tokens will be renewed. Assign a primary and backup owner, document the replacement steps, and make sure credentials are stored in an approved secure location.
Document the Decisions, Not Just the Configuration
In the same spirit, document the rest of the integration decisions too.
Capture authentication, service accounts, field and status mappings, synchronization triggers, which comments and attachments move, and the direction data flows. More importantly, document why those decisions were made.
Do not put passwords in an ordinary project document. Record where approved credentials are securely stored and how authorized administrators can access or rotate them.
The goal is to give future administrators enough context to make changes safely. Six months later, nobody should have to guess why a particular status was mapped, why attachments only synchronize in one direction, or who decided which requests should trigger the integration.
Overall Impressions and Recommendation
A good integration tool should be easy to configure, cost-effective, flexible enough for real-world requirements, and reliable enough that users barely notice it is there.
In my experience, the integration technology itself is often not the hardest part. The challenge is getting teams to agree on the technical and nontechnical decisions needed to make it successful.
Which work should synchronize? What triggers it? Which fields and statuses need to move? Who owns each piece of data? How should assignees and reporters be handled? Who manages the service account and renews the API token? What happens when synchronization fails?
These questions may seem tedious compared with seeing two systems connected, but they determine whether the integration remains useful six months or two years later.
For this scenario, Getint gave us the right balance of flexibility, support, usability, and cost. The service team stayed in Jira Service Management, developers stayed in Azure DevOps, and IT Infrastructure stayed in ServiceNow, all while the necessary information remained synchronized without creating a major manual process.
That is ultimately what a good integration should accomplish. It should not force teams to change tools simply because they need to collaborate. It should connect the work, reduce friction, preserve visibility, and make cross-team handoffs feel like part of one process, even when multiple platforms are involved.
Understand the workflow, limit the data you synchronize, test beyond the happy path, assign clear ownership, and document your decisions. Do that, and you will dramatically improve your odds of building an integration that is not only functional on day one, but sustainable over the long term.
Jira Service Management and ServiceNow: Connecting IT Infrastructure Workflows
The development team wasn't the only group needing an integration. Our IT Infrastructure team had its own challenge. Although Jira Service Management (JSM) was being used to collect incoming requests, the team continued managing its day-to-day operations in ServiceNow.
The organization was working toward adopting JSM, but moving away from an established platform takes time. Rather than disrupting existing processes, we needed a solution that would allow both systems to communicate during the transition.
Since we were already using Getint for Azure DevOps, it made sense to use its ServiceNow integration as well. This allowed us to address both requirements without having to learn or maintain another integration product.
Controlling Which Requests Get Synchronized
Unlike our Azure DevOps setup, which relied on a specific escalation status, the ServiceNow integration required a different approach.
We used Getint's filtering capabilities to identify which JSM requests should be sent to ServiceNow based on their request and work types. Anything that didn't meet those conditions would remain in JSM.
This helped prevent unnecessary information from flowing between systems while ensuring the Infrastructure team received the work they needed.
Setting Up and Validating the Integration
One advantage we had was getting the ServiceNow administrator involved right from the beginning. This made the initial configuration much easier. We did run into a few questions about supported fields, but Getint's support team pointed us toward the documentation we needed to move forward.
Another benefit was the similarity between JSM and ServiceNow. Since both platforms are designed around IT service management, aligning their workflows and statuses required relatively little effort.
For attachments, we established a one-way synchronization from JSM into ServiceNow. Comments, however, needed to travel in both directions so that each team could see the latest conversations regardless of which platform they used.
Once everything was configured, we put the integration through a few tests. We submitted two requests in JSM, one intended for IT Infrastructure and another that had nothing to do with the team.
The results were exactly what we wanted. The Infrastructure request appeared in ServiceNow, while the unrelated request stayed in JSM. We also validated that reporter details, mapped fields, comments, and attachments were being transferred according to our rules.
Ultimately, Getint helped us bridge the gap between JSM and ServiceNow without forcing the Infrastructure team to abandon its existing processes. The organization could continue its transition toward JSM while both teams maintained access to the information they needed.
