Companies that work together often track shared work in different systems. A customer reports a problem in ServiceNow, while the software vendor investigates it in Jira. Both teams need the latest details, even though they follow different workflows. In such cases, they integrate the systems they work in. When the integration is across different companies, we call it cross-company.
Such cross-company integrations keep records between multiple systems in sync, reducing the need to copy comments or chase updates. Each company still controls its own system, including its permissions and the information it agrees to share.
That arrangement becomes more demanding when AI agents start taking action. An agent handling a support ticket might create an issue in the vendor’s Jira or send an update back to the customer. When AI agents work autonomously, it’s important that both companies define clear rules about which actions they’ll accept and who’s responsible when something goes wrong.
I’m the CTO and co-founder of Exalate, a two-way sync app for Jira. I discussed these questions on Episode 29 of the CloudTweaks podcast, and they come up regularly in my conversations with Jira admins.
To understand what agents change, it helps to start with how these connections work today. Even before an agent gets involved, each team depends on a system it doesn’t control.
Cross-company integration means working with someone else’s rules
Inside one organization, teams can coordinate changes to their connected systems. If your Jira workflow changes, you can speak to the team responsible and arrange the corresponding integration update.
A customer or vendor follows its own priorities and release schedule. Their admins might rename a status, make a ServiceNow field mandatory, or reorganize Azure DevOps area paths without knowing how that affects your connection.
You may discover the change when a ticket stops syncing. Your team then has to identify what changed and work out which side needs to adjust its configuration.
This dependency is why each company needs control over its outgoing and incoming rules. Your team decides what leaves your system and how incoming data affects your records, while the other company makes those decisions for its own system.
Both sides still need an agreement about the data they exchange. Maintaining that agreement gets harder as you add more customers and connections.
Each client adds another set of changes to manage
Managed service providers deal with this across their client base. An MSP using Jira Service Management might connect to ServiceNow, Zendesk, and Jira instances owned by dozens of customers.
Each customer has its own workflows and admins. The MSP has to keep tickets moving while those customers make changes on schedules it can’t control.
We covered this operational challenge in 5 Hours Per Engineer, Per Week: How MSPs Scale to 50+ Clients Without Adding Headcount.
Keeping connection rules separate helps contain the work. For instance, if one client changes the priority values it sends, the MSP can adjust that client’s incoming mapping without changing the rules for everyone else.
That separation needs to hold in the implementation. Shared sync scripts or dependencies can still cause a change to affect multiple connections.
Adding AI agents to this setup brings its own set of challenges and they must operate within these same arrangements. Their ability to choose and trigger actions adds another behavior that both teams need to account for.
AI agents add decisions to the workflow
Consider an AI agent that reviews a JSM ticket and decides the vendor needs to investigate. It creates an issue in the vendor’s Jira, includes the relevant details, and later sends progress updates back to the customer.
For that workflow to work reliably, both companies need to define the agent’s scope. The vendor needs to decide where issues can be created and which fields can be changed. The customer needs rules about what information the agent can share.
Those decisions become particularly relevant when the agent acts on ticket content. A request in a description or comment shouldn’t give it permission to do something outside the connection’s agreed scope.
The receiving system therefore needs to apply its rules to every update, regardless of whether a person, an automation rule, or an agent triggered it.
I expect agents to increase demand for cross-company integration. They’ll also make the ownership of those rules harder to leave informal, which brings us to how the integration itself is managed.
Both companies need control over the connection
An integration platform as a service, or iPaaS, often puts configuration and operation under one team’s control. When one organization owns both systems, that team can manage the flow on behalf of everyone involved.
Across companies, that responsibility needs an explicit agreement. Who operates the platform? Who can edit the flow? How does each company approve or restrict changes that affect its system?
An iPaaS can support cross-company work, but you need to assess whether its permission model gives both parties the control they require. A setup that works for an internal data pipeline may need additional controls when a customer or vendor is involved.
AI agents make those controls more consequential because actions may happen without someone reviewing each one. The integration needs to enforce the agreed limits as part of processing the update.
Connecting an agent through MCP raises the same questions about authority and responsibility.
MCP provides access to tools, while teams define the permitted actions
The Model Context Protocol, or MCP, gives agents a standard way to use tools exposed by connected systems. The MCP server’s authorization controls and the connected identity’s permissions determine what access is available.
A workflow involving 2 companies also needs rules governing the exchange between them. Each company needs to decide which information it will share and what incoming requests can change.
For example, an agent at company A might request an update to an issue in company B’s Jira. Company B’s controls need to determine whether that update is allowed and which fields it can affect.
The same workflow needs a way to investigate mistakes. If the agent sends an incorrect priority or shares the wrong comment, someone must be able to trace the action and understand how it was processed.
These requirements give Jira admins a practical place to start: review the connection’s existing permissions and behavior before adding an agent.
Make the connection’s limits explicit
Some integrations rely on habits that people understand but haven’t written into the configuration. Your support team may know which comments to share or when to ask a vendor before changing a priority.
An agent needs those boundaries to be enforced by the systems and integrations it uses. Reviewing them first also helps you find assumptions that could already cause problems.
Start with these checks:
- Define what can leave each system. Review the outgoing fields, including comments, descriptions, and attachments.
- Specify what incoming data can change. Decide where issues can be created, which fields can be updated, and whether workflow transitions are allowed.
- Test changes before publishing. Check the intended behavior and keep a configuration version you can restore.
- Keep enough history to investigate an update. You should be able to trace the trigger, the data exchanged, and the rules applied.
- Assign an owner on each side and choose a low-risk connection for the first agent experiment.
Outgoing and incoming scripts show how some of these boundaries can be expressed in the configuration.
Use outgoing and incoming rules to control the exchange
Exalate uses sync rules to define what data moves between connected systems and how that data updates the receiving record. In Script Mode, these rules are written in Groovy, a programming language that lets you specify field mappings, conditions, and how to handle comments or attachments.
Each side of a connection has an outgoing script and an incoming script. For a Jira–ServiceNow connection, that means 4 scripts: Jira outgoing, ServiceNow incoming, ServiceNow outgoing, and Jira incoming.
When a Jira update syncs to ServiceNow, Jira’s outgoing script selects the data to send. ServiceNow’s incoming script then decides how to apply that data to its record. Updates traveling back follow the other pair of scripts. Each direction can have different rules.
This separation gives each company control over its part of the exchange. Your outgoing script determines what you share, while your incoming script determines what a partner’s data can change in your system. For example, you can send your status to a partner without accepting status changes from them.
This Jira example includes the issue’s main fields and filters out internal comments:
// Jira outgoing sync: select what leaves your instance
replica.key = issue.key
replica.summary = issue.summary
replica.description = issue.description
replica.priority = issue.priority
replica.status = issue.status
// Send public comments only
replica.comments = issue.comments.findAll { !it.internal }
replica.attachments = issue.attachments
The comment filter covers one part of the sharing decision. This example also sends descriptions and attachments, so your team needs to check whether those can contain information the partner shouldn’t receive.
The receiving side then determines how it uses the shared data.
In this incoming example, your Jira configuration controls issue creation and maps the partner’s priorities to your own:
// Jira incoming sync: define what incoming data can change
if (firstSync) {
issue.projectKey = "SUP"
issue.typeName = "Bug"
}
issue.summary = replica.summary
issue.description = replica.description
// Map the partner's ServiceNow priorities to Jira priorities
def priorityMap = [
"1 - Critical": "Highest",
"2 - High" : "High",
"3 - Moderate": "Medium"
]
issue.priority = nodeHelper.getPriority(
priorityMap[replica.priority?.name] ?: "Medium"
)
issue.comments = commentHelper.mergeComments(issue, replica)
On the first sync, this script creates a Bug in the SUP project. It copies the summary and description, maps the priority, and merges comments.
The mapping defaults to Medium if it receives an unknown priority. Your team needs to decide whether that fallback is acceptable, particularly if an unfamiliar value could represent an urgent incident.
The script also leaves status unassigned, so it doesn’t directly apply the partner’s status to your Jira issue. Local Jira automation could still respond to changes in other fields, which is why testing needs to include what happens after the sync.
In a setup with independent administration, your team controls these incoming rules. They determine how your Jira uses the partner’s data, including data sent following an agent’s decision.
Test the full behavior and keep a record of changes
Reading a script tells you what it’s configured to do. Running it against representative items helps you check how that configuration interacts with your fields, workflows, and local automation.
The New Exalate experience includes Test Run to preview script changes against real items before publishing. It also keeps published configuration versions with rollback, while Aida, Exalate’s AI assistant, explains sync errors in plain language.
Configuration history helps you identify changes to the rules. Operational records are also needed to trace individual syncs and agent actions.
Together, these give both teams a way to investigate unexpected behavior before expanding what the agent can do.
Start with one workflow
Choose a real workflow with a limited scope. Agree with the other team on what the agent can do, who reviews failures, and when to pause the connection.
Test the cases that could cause trouble: an unknown priority, a comment that should stay internal, or a request to change a field outside the agreed scope. Check the results in both systems.
Share what you find with the other team, within each company’s data-sharing limits. Use those results to decide which permissions to add next.
You can find Exalate’s approach to independent sync rules on the Atlassian Marketplace.
Are you already letting Rovo or your own agents trigger changes outside your organization? What was the first restriction you put in place?
