The connected enterprise: integrating Salesforce, Atlassian, Adobe and ERP

The gap is wide. MuleSoft's 2025 Connectivity Benchmark Report surveyed more than 1,050 IT leaders. It found the average organisation runs 897 applications, and only 29% of them are integrated. Just 2% of respondents had connected more than half of their applications. The same survey found that 80% see data integration as the biggest obstacle to using AI. AI agents can only act on data they can reach, so the integration backlog has now become the AI backlog too.

This guide is for Australian CIOs, enterprise architects and operations leaders who run two or more of the big platforms. It covers which system should own what, and which integrations pay back first. It compares the architecture options and explains what vendor API limits mean for your design. It sets out the Australian privacy and APRA rules that shape where integration data can travel, and how to sequence the work.

What does "connected enterprise" mean in practice?

It means four things are true at once:

1. Every core record has one owner. A customer is created and changed in one place, and so are a product, an invoice and a service ticket. Other systems hold copies, and they know they're copies.
2. Changes flow automatically. When a deal closes in Salesforce, the ERP gets a sales order without anyone re-typing it. A customer case that needs engineering arrives in Jira with its context attached.
3. Integrations are managed like products. Each flow has a named owner, monitoring, an error queue and a runbook. Nobody learns that a sync has failed from a customer complaint.
4. The data is governed for where it goes. You know which flows carry personal information, where they're processed, and which contracts cover them.

The platforms themselves are rarely the problem. Salesforce, Atlassian, Adobe and the major ERPs all have mature APIs. The problem is usually that nobody has decided which system owns which record. So each new integration is built as a one-off, and the same customer exists in four places with four different addresses.

Which system should own which data?

Start with a system-of-record map. It's a one-page table that gives every core data object a single owner, the systems that consume it, and the direction it flows. It is the most useful artefact in any integration program, and it takes days to draft, not months. This is the starting pattern for an organisation running all four platforms:

Two rules stop most arguments. First, the system where a record is created and legally maintained owns it. That puts the invoice in the ERP, not the CRM, even if sales staff look at it in Salesforce. Second, if two teams both insist they own a field, split the object. The ERP owns the customer's billing address and credit terms. Salesforce owns the relationship, contacts and pipeline.

Which integrations pay back first?

Not every connection is worth building. The flows below come up most often in organisations that run Salesforce, Atlassian, Adobe and an ERP together. They are listed roughly in the order they tend to pay back, because each one removes re-keying that is both frequent and error-prone.

Start with one revenue-side flow (usually quote to cash) and one service-side flow (usually case to engineering). They touch different teams, so you learn your integration patterns twice without the two projects blocking each other.

The Microsoft Dynamics 365 program in our manufacturing ERP case study shows why the data work comes first. More than 2 million records were cleansed, de-duplicated and migrated from multiple systems with zero downtime at cutover. Power BI was then connected for real-time operational and finance dashboards. Month-end close got 30% faster and manual processes fell by 60%. Integrations built on top of that cleaned data have far fewer exceptions to handle.

Point-to-point, iPaaS or workflow platform: which architecture should we use?

There are four common patterns. Most organisations end up using two of them. The aim is to choose deliberately, rather than end up with all four by accident.

Here is a practical rule of thumb. If you will run more than about 10 flows across 4 or more systems, put them on a single integration layer, whether that's an iPaaS or a well-governed workflow platform. You get one place to monitor, one set of credentials to rotate and one team that knows how it works. Keep native connectors for simple, standard flows, and document them in the same register.

Data residency now affects this choice. Salesforce announced on 11 August 2026 that MuleSoft runs on Hyperforce in Australia, with both its control plane and runtime plane hosted locally. Self-hosted n8n runs on infrastructure you choose, including an Australian cloud region or your own data centre. Either can keep integration data onshore. A SaaS integration tool hosted in the US might not, and the integration layer carries some of your most sensitive data.

What do vendor API limits mean for our design?

They decide whether your design works at month end. Every platform rations API calls. Integrations that poll every few minutes or sync whole tables use up those allowances quickly, and then they fail at the worst moment.

• Salesforce gives Enterprise Edition orgs 100,000 API calls per rolling 24 hours, plus 1,000 per Salesforce licence (5,000 per licence on Unlimited Edition), according to its API request limits. A 200-user Enterprise org therefore has about 300,000 calls a day. That allowance is shared by every integration and installed managed package, and it isn't tracked per user. Production orgs are also limited to 25 concurrent requests that run longer than 20 seconds.
• Atlassian began enforcing points-based rate limits for Jira and Confluence Cloud apps on 2 March 2026. Heavier calls cost more points. Most apps share a global quota of 65,000 points an hour, and apps that exceed it get HTTP 429 responses with a Retry-After header. The new limits apply to Forge, Connect and OAuth 2.0 apps. Traffic using API tokens stays under the older burst limits.
• API versions expire. Salesforce's end-of-life policy retired API versions 21.0 to 30.0 in Summer '25. Versions 31.0 to 40.0 become unsupported from Summer '27 and are retired from Summer '28. The SOAP login() call is also scheduled for retirement in Summer '27. Integrations written years ago against old versions will stop working on a known date.

Three design habits keep you inside the limits:

• Trigger flows on events (platform events, webhooks, change data capture) rather than polling on a schedule.
• Move bulk loads into bulk APIs and run them off-peak.
• Track API consumption as a monitored metric, with alerts at 70% and 90% of the allowance.

Which Australian rules shape where integration data can go?

Integrations move personal information between systems and often across borders, so privacy and prudential rules apply to the integration layer as much as to the platforms. Four rules come up most often.

Privacy Act APP 8: cross-border disclosure. When personal information goes to an overseas recipient, APP 8.1 requires you to take reasonable steps to ensure that the recipient doesn't breach the Australian Privacy Principles. Under section 16C, you are accountable if it does. The OAIC's APP 8 guidelines explain when sending data to an overseas cloud provider counts as a "use" rather than a "disclosure". It requires a binding contract limiting the provider to storage, subcontractors bound the same way, and you keeping effective control of the data. Check this for every integration tool, not just the main platforms.

Data residency is per product and per feature. All four major platforms offer Australian hosting, but with exceptions:

• Atlassian: data residency pins Jira and Confluence content, and most Rovo data, to Australia, but user account data and app analytics are excluded.
• Adobe: Experience Platform has an Australian hosting location (AUS5, on Microsoft Azure in New South Wales).
• Microsoft: Microsoft's Dynamics 365 data residency documentation says data stays in your chosen geography at rest. But it warns that data can move outside that geography when Dynamics 365 is connected to external services, including Power Automate.

That last point is the important one. An Australian-hosted CRM and an Australian-hosted ERP can still be joined by an integration that processes data offshore.

APRA CPS 230: operational risk. For banks, insurers and super funds, CPS 230 has applied since 1 July 2025. Regulated entities must keep a register of material service providers, and notify APRA within 20 business days of entering into or materially changing a material arrangement. If an integration platform carries a critical operation, such as payments, claims or member transactions, it probably belongs on that register. It also needs the same continuity testing as the systems it connects.

Automated decisions from 10 December 2026. If an integration or AI agent uses personal information to make, or substantially help make, a decision that significantly affects someone, your privacy policy must say so from 10 December 2026. Our guide to automated decisions and the Privacy Act covers what to inventory and disclose.

Where do AI agents fit in a connected enterprise?

On top of the integration layer, not instead of it. Each platform now ships its own agent: Agentforce in Salesforce, Rovo in Atlassian, Copilot in Microsoft and Gemini in Google. Each works well inside its own platform. Questions that span platforms still need connected data. "Which of our top 20 customers have an overdue invoice and an open priority-one incident?" needs the ERP, Salesforce and Jira Service Management at once.

Two developments are making this easier. The Model Context Protocol (MCP) is an open standard for connecting AI applications to external systems, and vendors are adding MCP support to their platforms. Integration platforms are also adding agent-specific controls: MuleSoft's Australian launch included MCP support and an AI gateway. The governance question doesn't change. Agents should call the same governed APIs your integrations use, with least-privilege credentials, logged actions and human approval for high-impact steps.

AI also helps with the integration work itself. Agents can profile source data, propose field mappings, generate test cases and flag records that will fail validation before a migration run. Our article on agentic AI in systems integration goes deeper, and agentic AI in PIM integration works through a product-data example.

How should we sequence a connected-enterprise program?

In five stages. The first two take weeks, not months, and the rest repeat for each new flow.

1. Inventory (weeks 1 to 3). List every integration that exists today, including scheduled exports, marketplace apps, spreadsheets that someone uploads every Monday, and staff accounts used as API credentials. For each one, record systems, data objects, direction, frequency, owner, hosting location and whether it carries personal information.
2. Ownership and target design (weeks 3 to 6). Agree the system-of-record map above with business owners, not just IT. Choose your integration layer and your standards for authentication, error handling, logging and naming. Decide which flows carry regulated data and where they may be processed.
3. First two flows (months 2 to 4). Build one revenue-side and one service-side flow on the new layer. Each gets monitoring, an error queue, alerting, a runbook and a named business owner. Measure the baseline first (hours of re-keying, error rates, cycle time) so you can show the change.
4. Retire and replace (months 4 to 9). Move legacy point-to-point links and risky workarounds onto the integration layer, starting with the ones that have no owner or use old API versions. Switch off what you replace, or you'll end up running both.
5. Extend and add agents (month 9 onward). Once the core records flow reliably, add agent use cases that span systems. Run quarterly reviews of API consumption, credentials and vendor end-of-life notices.

A readiness check before you start building helps. Score each statement 0 (no), 1 (partly) or 2 (yes):

• We have a current list of every integration, with an owner for each.
• Every core data object has one agreed system of record.
• Integrations use service accounts or OAuth apps, not named staff credentials.
• Failed syncs raise an alert and land in a queue someone works through.
• We know which integrations carry personal information and where each one processes it.
• We track API consumption against each platform's limits.
• No integration depends on an API version that's scheduled for retirement.
• Integration changes go through test environments and change control.

A score of 12 to 16 means you are ready to scale. A score of 6 to 11 means stages 1 and 2 will pay for themselves. Below 6, fix ownership and credentials before you build anything new.

What does each platform add to the picture?

Each platform has its own integration options, and each partner page covers them in more detail:

• Salesforce: Platform events, change data capture and bulk APIs for moving data out efficiently; MuleSoft for organisations that want Salesforce's own iPaaS. See Salesforce integration.
• Atlassian: Webhooks and REST APIs for Jira and Confluence, Forge for apps that run on Atlassian's platform, and Jira Service Management as the front door for IT and business requests. See Atlassian integration and our post on integrating Atlassian with your tech stack. If you're still on Data Center, read the Australian migration guide first, because every integration changes when Jira moves to Cloud.
• Adobe: Experience Platform source connectors bring CRM and other data into Real-Time CDP. Adobe's Salesforce source connector detects only soft-deleted records, not hard deletes. That matters when a customer asks to be erased. See Adobe integration.
• ERP: Dynamics 365, NetSuite and SAP all expose order, customer and item APIs, but each has its own data model and tax logic. That makes the ERP the riskiest end of most flows. See Microsoft Dynamics 365 and agentic AI for ERP implementations.

Content systems need the same discipline as transactional ones. In our DAM case study for a global retailer, more than 300,000 assets (2TB) were migrated into one DAM. It was integrated with the retailer's eCommerce and campaign tools, giving a retailer that operates in more than 20 countries a single source of truth for branded content.

Frequently asked questions

What is enterprise systems integration?

Enterprise systems integration connects business applications such as CRM, ERP, service management and content platforms. Records and events then flow between them automatically, in line with agreed ownership rules. It covers the architecture, the integration platform, the individual data flows and the operating model that keeps them running.

Do we need MuleSoft if we already run Salesforce?

Not necessarily. MuleSoft suits organisations with many flows, reusable APIs and a team to run the platform. Smaller estates often do well with native connectors for standard flows and a workflow platform such as n8n or Power Automate for the rest. The deciding factors are flow count, volume, data residency and who will support the platform.

Can our integration data stay in Australia?

Usually, yes. Salesforce, Atlassian, Adobe Experience Platform and Dynamics 365 all offer Australian hosting, and MuleSoft and self-hosted n8n can run onshore. Check the exceptions for each product, such as identity, AI features and connected services. Also check the integration tool itself, because that is where data often leaves the country without anyone noticing.

How long does it take to connect Salesforce and an ERP?

It depends less on the API work than on the data. Mapping product, price and tax codes between the two systems, and agreeing who owns the customer record, take most of the time. If customer and product masters are inconsistent, clean them first; the build itself is the smaller part of the job.

Where to start

Great Minds is a Sydney-based systems integrator working across Salesforce, Atlassian, Adobe, Microsoft, Google and ERP platforms. Our agentic AI systems integration and data integration teams start most engagements with an integration assessment. We inventory what you have, draft your system-of-record map, score your readiness and identify the first two flows worth building. Contact us to book an integration assessment.