Jira is one of those tools that can do almost anything. It is a powerful project management and work-tracking platform, relatively easy to adopt, and used by organizations around the world.
But no matter how popular or versatile Jira becomes, one fact remains: Jira is rarely the only tool a team uses.
A project management team may use Jira to track requirements, while developers work in a combination of GitHub and GitLab. A support team may use a platform such as ServiceNow to manage service and incident requests across the business. Marketing might use Monday.com, while HR may prefer ClickUp. Whatever the scenario, the reality is that modern businesses depend on many tools, and those tools often need to work together.
Getting them to work together, however, is easier said than done. That is where an integration platform such as Getint can make a major difference.
Tool fragmentation is nothing new. In fact, it is a normal part of running a business. Every platform has its own strengths, and it often makes sense to purchase different tools for different purposes. The problem begins when data needs to move from one system to another. That is where teams can quickly run into duplicate work, missing information, manual handoffs, and poor visibility.
I've encountered these challenges many times over the years. One recent project involved two teams with different requirements: a development team using Azure DevOps and an IT Infrastructure team working in ServiceNow. Both received requests through Jira Service Management and needed reliable synchronization with their existing systems.
In the following examples, I'll walk through how we used Getint to connect these platforms, the challenges we encountered during configuration, and the lessons that can help other teams plan their own Jira integrations.
JSM Azure DevOps Data Integrity Case
Let me set the stage. A few months ago, I was working with a team that used Jira Service Management (JSM), to capture service requests from customers. A request would come in, and if the technician could solve it, they would. However, every once in a while, a request needed to be escalated to the development team.
That is where we encountered our first problem: the development team was using Azure DevOps.
JSM and Azure DevOps are not designed to exchange information seamlessly out of the box. Their workflows, fields, terminology, and overall ways of working are different. So how do you successfully escalate a request from JSM to developers working in Azure DevOps without forcing one team to abandon its preferred tool?
For us, Getint's Jira-to-Azure DevOps integration became the answer.
A good integration can eliminate duplicate data entry, reduce manual status updates, improve visibility, and allow teams to continue working in the tools that make sense for them. That is really the goal. We do not want to duplicate data, and we do not want users constantly switching between platforms. We want each team to keep working in the tool they already know while ensuring the necessary data exists in both systems and stays synchronized without ongoing manual intervention.
Getint allowed us to do exactly that.
Choosing an Integration Tool
When the team first explained what it was trying to accomplish, I immediately knew we were going to 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 alone. I also knew that there were several integration products available, so I tested a few different options.
I evaluated them based on three major factors:
- how easy they were to configure,
- how feature-rich they were,
- and whether the pricing fit the team's budget.
The first couple of tools I tested were feature-rich, but the setup process took some time to understand. I eventually ran into a technical problem and submitted a support ticket. Because of the time-zone difference, however, 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.
Getting started was straightforward. There were videos that walked me through the process, and the documentation closely matched what I was seeing on the screen. It took me a little longer to work through the Azure DevOps side, but once I had the right Azure administrator on a call, the rest of the setup went smoothly.
I was able to establish a connection, map fields and statuses, and determine how we wanted to synchronize comments and attachments. About 30 minutes later, I had a working proof of concept ready to show the executive team. The pricing also fit the budget, which meant we could move forward without a lengthy procurement debate.
The next day, I demonstrated the integration to the executive team. I showed them what was possible, and the reaction was extremely positive because the solution avoided the tool and data disruption they had expected. Instead of asking one team to change platforms, we were creating a bridge between the systems they already used.
Once the proof of concept was approved, we went back into the integration settings and began preparing for a real-world production test.
Moving from Proof of Concept to Production
Going from a proof of concept to a production-ready integration can be challenging, but Getint made that process easier. Because we already had part of the integration working, the next step was to finalize the requirements and build around them.
The first thing we did was create a mechanism so that only specific work coming into JSM would synchronize with Azure DevOps. We did not want every request to cross platforms. We only wanted the requests that had actually been reviewed and determined to require developer involvement.
To accomplish this, I created an "Escalate to Developer" status in the JSM workflow.
Then, in Getint's JSM integration settings, we updated the configuration so that the integration would listen only for work that transitioned into that status. This ensured that not every item in the JSM project would be synchronized automatically.
Having control over what triggers a sync is extremely important. Most teams do not want every piece of data in one system copied into another. They want to define which records qualify, when they should move, and what information should travel with them.
Mapping Fields Correctly
The next requirement was getting the fields from each tool to align. This is a critical step because you do not want to lose or misinterpret data during the integration.
This part took a couple of working sessions with administrators from both platforms. We needed to understand how each tool handled the information we were trying to synchronize. Most fields were easy to map, but we eventually ran into one that behaved differently than expected.
I contacted Getint support, and within about an hour I had instructions explaining how to provide the log files they needed for troubleshooting. By the end of that same day, we had resolved the issue and successfully 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. For example, "Priority," "Severity," and "Impact" can sound related while representing very different concepts depending on the team and platform. Before mapping fields, make sure both sides agree on what the data actually means.
Mapping Statuses and Workflows
Once the fields were mapped, it was time to map statuses.
From a technical perspective, this part 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.
Because we wanted to keep the experience simple for the customer who submitted the original JSM request, we decided to synchronize only a small number of meaningful statuses.
Different teams work differently, so you should not be forced to reproduce the same workflow in both tools.
Getint gave us the flexibility to map the workflows according to our own requirements. We did not need a one-to-one match for every status. Instead, we could decide which transitions mattered and how each system should respond.
The final piece of our status mapping involved moving the JSM request out of "Escalate to Developer" after the development work was completed. Once the related Azure DevOps item reached the appropriate completion status, we wanted JSM to move the request back to a state where the service technician could follow up with the customer.
That was straightforward to configure and gave us the handoff we needed between service and development.
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. In fact, you should assume that your user populations will be different unless you know otherwise.
Getint gives you several options for handling this. In our case, we decided to use a service account. We made sure the service account existed in both tools and used it for the integration.
If the same user does not exist in both systems, you may end up with mismatched ownership information. Depending on your use case, that may be perfectly acceptable, or it may create serious reporting and accountability problems. This is something you should decide before building the integration rather than discovering it during testing.
Synchronizing Comments and Attachments
The final part of the configuration involved comments and attachments.
This can be especially difficult to handle without a dedicated integration tool, so we were happy to see that both were supported. Getint gave us multiple options for deciding how comments and attachments should move between platforms.
- For our use case, we wanted attachments to synchronize from JSM to Azure DevOps only. We did not want attachments from Azure DevOps automatically flowing back into JSM.
- For comments, we wanted a bidirectional sync so that conversations could remain visible regardless of which platform a team member was using.
A few configuration changes later, comments and attachments were syncing exactly the way we wanted.
Testing with Real Production Scenarios
Once the mapping and synchronization rules were configured, it was time for the fun part: testing.
- We created a new JSM request and transitioned it into our "Escalate to Developer" status. Within about 180 seconds, the corresponding work item appeared in Azure DevOps with the data mapped as expected.
- Next, we tested an attachment from the JSM side. It synchronized successfully. We then added an attachment from the Azure DevOps side, and nothing synchronized, which was exactly what we expected based on our configuration.
- We added comments in each tool and confirmed that they synchronized in both directions.
- Finally, we moved the Azure DevOps work item to Done, indicating that the development work had been completed. As expected, the JSM request transitioned to the correct follow-up status.
At that point, we had confirmed that the basic integration workflow behaved exactly as intended.
Could we have handled all of this manually? Yes. Could we have built custom automations and scripts to move the data between platforms? Probably. But the time commitment, technical expertise, testing burden, and ongoing maintenance required to make a custom solution reliable would have been significant.
Getint allowed us to create a functional bidirectional synchronization process in a matter of hours rather than building and maintaining a custom integration ourselves.
.png)
Jira Service Management and ServiceNow: Connecting IT Infrastructure Workflows
While the development team needed to connect JSM with Azure DevOps, I was also working with an IT Infrastructure team facing a similar challenge. Requests were coming into Jira Service Management, but the team already had a well-defined process in ServiceNow.
The company's direction was to move toward JSM, but the transition couldn't happen overnight. We needed to support the team's existing ServiceNow workflows while the transition plan was being developed.
Fortunately, Getint supported both platforms, which meant we could address the two integration requirements using a familiar configuration approach rather than introducing another integration solution.
Synchronizing Only Relevant Requests
For the IT Infrastructure team, the requirements were slightly different from the development team's scenario. We didn't need to introduce a special escalation status in JSM. Instead, we configured Getint filters to synchronize only a specific request type mapped to the appropriate work type in ServiceNow. Everything else could be ignored.
This gave us control over which requests reached the IT Infrastructure team without transferring unrelated work between platforms.
Configuring and Testing the Integration
The initial setup was straightforward, particularly because I had access to the ServiceNow administrator from day one. We needed some clarification from Getint support about specific field capabilities, but once we were directed to the relevant documentation, the remaining configuration went smoothly.
Since JSM and ServiceNow support similar service management processes, there was also considerable overlap between their statuses and workflows.
We configured attachments to synchronize from JSM to ServiceNow, while comments could synchronize bidirectionally. This allowed the teams to exchange relevant information without changing their existing ways of working.
During testing, we created two JSM requests: one for IT Infrastructure and another unrelated request. Only the IT Infrastructure request synchronized with ServiceNow, exactly as we intended. We also verified that fields, attachments, reporter information, and comments synchronized according to our configuration.
The result was an integration that supported the IT Infrastructure team's existing ServiceNow processes while the organization continued moving toward JSM. Both teams could work in their preferred systems, with the relevant information kept synchronized.
Integrating Jira: 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 two tools should not be the objective by itself. You need a deeper understanding of how the teams expect to collaborate without disrupting their existing flow. You want to avoid duplicate data, unnecessary manual work, and extra overhead for people who are already busy.
The best integrations are almost invisible to end users. They should feel natural. A user should be able to work in the system they already know while the integration quietly keeps the right data synchronized behind the scenes.
1. Understand the Process Before You Configure the Tool
Before you integrate any platforms, understand how each team expects information to flow.
One of the biggest integration mistakes is jumping into configuration before understanding the full process. Most teams I work with know exactly what they expect from the tool they use every day. But when you ask them what they expect from another team's tool, the answer is often much less clear.
Sit down with each team and map out how they work independently and how they need to work together. Identify the handoff points. Document who owns the work at each stage. Clarify what should happen when something is rejected, reopened, escalated, blocked, or completed.
2. Do Not Synchronize Everything
Synchronize only the information that you actually need to transfer.
Even if the integration platform technically allows you to synchronize everything, that does not mean you should. Moving unnecessary data creates more noise, increases the chance of accidental exposure, and makes troubleshooting more difficult.
Sync only the information the receiving team needs to do its job. I like to approach this using a least-privilege mindset: start with the minimum number of records, fields, statuses, attachments, and comments, then expand only when there is a clear business reason.
3. Get Stakeholder and Administrator Buy-In Early
You are trying to make two different platforms communicate, which creates technical challenges, but there can also be organizational challenges.
Some stakeholders may question whether the integration should happen at all. Security teams may want to understand how data moves between systems. Administrators may be hesitant to provide API access. Platform owners may disagree over which system should be considered the source of truth.
Work through these nontechnical requirements before you begin configuring the production integration.
Determine who approves API token requests. Decide who will own the integration. Identify which account will authenticate. Clarify who will troubleshoot failures. Determine which team is responsible if a mapping changes in one of the connected platforms.
I learned this lesson the hard way. In one project, I personally created the integrations. After the work was nearly complete, the team decided that everything needed to be owned by a service account. We then had to stop, determine how to request the account, obtain the necessary permissions, and recreate portions of the integration under the new identity.
A few discovery questions at the beginning would have saved significant time.
Start in a sandbox or test environment with a small proof of concept whenever possible. A working demo can make governance and ownership conversations much easier.
4. Do Not Assume Similar Fields Mean the Same Thing
This is one of the first mistakes I made when working with cross-platform integrations.
I once assumed that the Status field in Jira Service Management 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 actually what we needed to map.
Always validate your assumptions with administrators from both systems.
For every field you synchronize, understand its meaning, intended use, expected values, and any business rules behind it. If a field has a dropdown list, determine what should happen when one system contains a value that does not exist in the other. If a field is required in one system but optional in the other, decide how that should be handled before go-live.
5. 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 testing plan that covers as many realistic paths as possible. Test:
- Reopened work items
- Deleted records
- Attachments
- Comments
- Special characters
- Large descriptions
- Missing users
- Missing fields
- Permission failures
- Multiple transitions
- Simultaneous updates
- Duplicate records
You should also test what happens when one of the connected systems is temporarily unavailable. Does the integration retry? Does it queue the update? Does someone receive an alert? Can you identify which records failed to synchronize?
If you only prepare for the happy path, you will be unprepared when users discover the edge cases for you.
6. Decide Which System Owns Each Piece of Data
Another practice that becomes important as integrations grow is defining system ownership.
When the same information exists in two tools, someone needs to decide which system is authoritative for each field. Otherwise, two teams may update the same value at the same time and unintentionally overwrite one another.
For example, 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 system should control priority.
This becomes especially important with bidirectional synchronization because "both directions" should not automatically mean "every field can be changed everywhere."
7. Monitor the Integration After Go-Live
An integration is not finished the moment it works in production.
Fields change. Workflows change. Users lose permissions. Accounts get disabled. APIs change. Tokens expire. Someone renames a status that an integration depends on. A configuration that worked perfectly for six months can suddenly begin failing because one small dependency changed.
Create a simple operational routine for reviewing the integration after launch. Determine who checks errors, how often logs are reviewed, where incidents are reported, and what information support teams need when something fails.
Plan for API Token Expiration
API tokens expire, and that information belongs in your runbook.
One of the biggest lessons I learned the hard way involved an integration whose API token was configured to expire after 365 days. I left the project a few months after the integration went live. About a year after the original setup, I received a call saying the integration had stopped working.
The service account owner was no longer with the company, which made recovery more complicated. Eventually, we regained access and renewed the token, but the incident could have been avoided with better operational documentation.
When you create the integration, define how the API token will be renewed. Assign a primary owner and a backup owner. Document the steps needed to generate or replace the token. If the token must be stored in an approved secure location, document that process as well.
Document the Decisions, Not Just the Configuration
In the same spirit, document the rest of the integration decisions too.
Capture how authentication works, which service accounts are involved, how fields are mapped, how statuses are mapped, what triggers synchronization, which comments and attachments move, which direction the data flows, and why those choices were made.
Avoid documenting passwords directly in an ordinary project document. Instead, document where approved credentials are securely stored and how authorized administrators can access or rotate them.
Document the reasoning behind important mappings so future administrators can change them safely.
Overall Impressions and Recommendation
A good integration tool should be easy to set up, cost-effective, flexible enough to support 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 difficult part is getting teams to agree on the technical and nontechnical decisions required to make the integration successful.
Before you begin, both sides should agree on which work needs to synchronize. What event will trigger the sync? Which fields need to move? How will statuses map between systems? Which system owns each piece of data? How will assignees and reporters be handled when users do not exist in both platforms? Who owns the service account? Who renews the API token? What happens when synchronization fails?
These questions may seem tedious compared with the excitement of seeing two systems connected, but they are what determine whether the integration remains useful six months or two years later.
For the scenario I described, Getint gave us the right balance of configuration flexibility, support, usability, and cost. It allowed the service team to stay in Jira Service Management, the development team to stay in Azure DevOps, and both sides to work with synchronized information without creating a major new 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.
If you approach the project by first understanding the workflow, limiting the data you synchronize, testing beyond the happy path, assigning clear ownership, and documenting your decisions, you will dramatically improve your odds of building an integration that is not only functional on day one, but sustainable over the long term.
