Auditing Your Integration Estate

A team requests a new connector. Sales needs Workday talking to a new commission platform, or operations wants an Infor LN data feed into a third party warehouse system, or a product team wants a MuleSoft API exposed to a partner. The architect’s first question should not be how fast the new build can ship. It should be what is already running. In our experience, most organizations cannot answer that question with confidence, and the gap between what they think is running and what is actually running in production is where the next incident comes from.

This article gives you a structured method for inventorying, testing, and scoring your existing Workday, Infor, and MuleSoft integrations before you approve new build work on top of them. It is not a philosophy of integration health. It is a sequence of checks you can run in your own tenant or org this week, and a way to decide which findings have to be addressed before the new integration proceeds and which can wait.

Why Audit Before You Build

The case for auditing first is not abstract. The MuleSoft 2025 Connectivity Benchmark Report, produced with Vanson Bourne and Deloitte Digital, found that enterprises average approximately 897 applications with only 28 percent of them properly integrated, and that 95 percent of IT leaders cite integration issues as a primary barrier to AI and automation adoption. When an organization carries that much unintegrated surface area, the instinct to add one more connector without checking the state of the existing layer compounds the problem rather than solving it.

The specific risk of building on an unaudited base is not vague. When we run this audit for a client, the most common finding is a duplicate connector: two integrations independently built, months apart, by different teams or different vendors, moving the same data through different mechanisms because no one checked what already existed. The second most common finding is a conflicting field mapping, where two integrations write to the same downstream field using different transformation logic, and the receiving system silently takes whichever write landed last. Adding a new integration into that environment does not just add risk in isolation. It adds risk on top of security debt that has already been accumulating, often for years, because nobody has had a complete view of the estate to address it.

There is also a cost dimension to this that is worth being explicit about. The operational cost of integration downtime compounds when the cause of a failure is two integrations stepping on each other rather than a single point of failure that is easy to isolate. An audit before new build work is cheaper than the incident response after a new integration triggers a conflict nobody saw coming.

Step One: Build a Complete Integration Inventory

The inventory is the foundation everything else in this process depends on, and it is also the step organizations most often try to shortcut. An integration inventory is not a list of the integrations someone remembers building. It is a catalogue of everything actually moving data between systems in production, regardless of who built it, when, or whether it appears in any architecture diagram.

What counts as an integration that belongs in this inventory is broader than most teams initially assume. Scheduled Workday EIBs count, including ones that run nightly or weekly with no one actively monitoring them. Infor ION document flows count, including connection points that were configured for a vendor relationship that has since ended but were never deactivated. MuleSoft APIs deployed to CloudHub count, including ones built for a pilot that never moved to general availability but never got undeployed either. Point to point scripts running on a cron job on someone’s laptop or a forgotten EC2 instance count. Even spreadsheet driven manual processes that function as a de facto integration, where someone exports a report from one system and uploads it into another on a recurring schedule, belong in the inventory, because the moment that person leaves the organization, the data flow stops with no warning to anyone downstream.

The places these hide are predictable once you know where to look. In Infor environments, forgotten connection points are usually tied to a vendor or partner relationship that ended without anyone walking through the offboarding checklist in ION Desk. The connection point itself does not know the relationship ended, so it keeps polling or keeps waiting for inbound BODs that will never arrive. In Workday environments, EIBs that still run on a schedule for a vendor relationship that ended eight months ago are one of the most common findings we see, because EIB schedules are configured once and rarely revisited unless something breaks loudly enough to get noticed. In MuleSoft environments, APIs deployed to CloudHub that nobody on the current team remembers building accumulate during periods of high developer turnover or heavy reliance on contractors, where the deployment exists in Runtime Manager but the institutional knowledge of why it exists left with the person who built it.

Documenting what the inventory finds is not optional busywork. The output of this step should feed directly into a requirements document developers can actually build from if any of the findings require remediation work, because an inventory entry that says “Workday EIB, runs nightly, purpose unknown” is not actionable on its own. It needs to be paired with enough detail, source and destination systems, triggering mechanism, last known owner, that someone can pick it up and either confirm it is healthy or schedule it for retirement.

Step Two: Platform-Specific Technical Review

Once the inventory exists, each integration needs a technical review specific to the platform it runs on. The checks that matter on Workday are not the checks that matter on Infor, and neither maps cleanly onto MuleSoft, so this step has to be broken out by platform rather than treated as a single generic pass.

Auditing Workday Integrations

Start with EIB schedule review. Pull the full list of EIBs configured to run on a schedule and check each one against two questions: is the schedule still aligned with an active business need, and has the EIB failed silently at any point in the last several runs without anyone noticing. EIB failures are particularly prone to this because a partial file load can complete with errors on a subset of records while still reporting success at the job level, leaving bad data sitting in the target system without an alert ever firing.

Studio integration health is the next check. For every Studio integration in the tenant, confirm that the orchestration is still doing what its name or description claims, that the error handling is actually catching the failure modes it was designed to catch, and that the integration has not quietly become orphaned because the system it once connected to has since been replaced or retired.

ISU permission scope review is where we most often find security debt accumulating. Every Integration System User in the tenant should be checked against the principle that it has domain level permissions scoped precisely to what its integration requires, nothing broader. An ISU that was scoped generously at build time because it was faster than working out the exact domains needed is a standing risk, and it is the kind of finding that an audit surfaces cleanly because the ISU’s actual permission set can be compared directly against what its integration touches.

REST API OAuth client scope review follows the same logic for any integration built against the REST API rather than EIB or Studio. Each OAuth client should be checked for whether its granted scopes match its actual usage. A client that was registered with broad scopes for convenience during initial build and never tightened afterward is a common finding, and it is exactly the kind of gap that becomes a liability the moment a new integration is added to a tenant that already has unscoped credentials floating around.

For organizations whose audit surfaces a pattern of integrations built outside Workday’s supported integration methods, from Studio to REST APIs, or a need to formally evaluate whether the current mix of EIB, Studio, and REST is still the right architecture, that gap is worth scoping as a dedicated remediation project rather than folding into routine maintenance.

Auditing Infor Integrations

ION document flow and monitor review starts with pulling the list of active connection points and document flows configured in ION Desk and checking each one against current business need. A document flow that routes BODs to a system that was decommissioned eighteen months ago will often still show as configured, because nothing forces its removal unless someone actively goes looking.

BOD subscription cleanup is the next layer. Every BOD subscription should map to an active downstream consumer. Subscriptions that were set up for a one-time data migration and never cleaned up afterward continue receiving and processing BODs indefinitely, consuming ION resources and creating noise in the monitoring layer that makes it harder to spot the failures that actually matter.

ION Desk activation policy review means checking which monitors and alarms are actually active versus configured but disabled, and whether the alerting thresholds still reflect current operational reality. ION Desk monitors the outbox entry table and reports counts of processed and unprocessed messages, which gives you a direct way to spot a connection point that has been silently accumulating a backlog without anyone noticing, since an unprocessed count that climbs steadily over weeks is a strong signal of an orphaned or broken flow.

Checking for orphaned connection points is the final and often most revealing check in this section. A connection point with no recent message traffic, no active subscriptions, and no documented owner is a candidate for retirement, but it should never be deactivated without first confirming there is genuinely nothing depending on it, since the publish and subscribe model means a quiet connection point is not always a dead one.

Where the audit surfaces a genuine gap in Infor’s ION based integration architecture, whether that is missing documentation on existing BOD mappings or a need to formally map the current connection point inventory against business requirements, that gap is worth scoping as its own piece of work before any new ION based integration is approved.

Auditing MuleSoft Integrations

API Manager conformance review is the starting point for MuleSoft. Anypoint API Governance applies governance rulesets to APIs across the lifecycle and reports conformance status through the Governance console, so the first technical check is simply running every governed API instance against its assigned ruleset and reviewing the resulting conformance report rather than assuming conformance because the API has not generated a complaint.

Identifying unmanaged or unprotected APIs is the next step, and this is where the full lifecycle of API governance on the Anypoint Platform becomes directly actionable. The API Governance Dashboard provides an organization wide view of the API landscape and surfaces the count of unprotected APIs directly, meaning APIs that exist in the catalogue but are not currently managed in API Manager. From that dashboard you can create a governance profile targeted specifically at the unprotected population and apply baseline rulesets to bring them under management, which is a meaningfully different starting point than trying to track unmanaged APIs manually.

Reviewing CloudHub deployments against current business need means going through the list of deployed applications in Runtime Manager and confirming that each one is still serving an active purpose. Deployments left running after a pilot ended, or after a downstream consumer was decommissioned, continue to incur runtime cost and continue to represent attack surface even though they produce no business value.

Checking for deprecated Mule 3.x runtimes still in production closes out the platform-specific review. Any application still running on Mule 3.x carries both a security exposure and an operational risk, since the runtime is past its supported lifecycle and any new integration work that needs to interact with it inherits constraints that a Mule 4.x environment would not impose.

Step Three: Security and Access Review

This is the section of the audit most directly aligned with OWASP’s API Security Top 10, and it deserves to be run as a distinct pass rather than folded into the platform-specific review, because the same risk pattern shows up across all three platforms in slightly different forms.

Broken authentication is the first risk category to check for. OWASP’s API Security Top 10 describes this as a class of vulnerabilities covering everything from weak credential handling to a failure to properly invalidate or re-verify identity at the right points in a session, and integration layers are particularly exposed to it through two specific patterns: long-lived OAuth tokens that never expire on a meaningful cycle, and stale Integration System Users in Workday whose credentials have not been rotated since the integration was originally built. An ISU or OAuth client that has been running on the same unrotated credential for years is functionally equivalent to a static password that was never meant to be static, and it is exactly the kind of finding that a security review surfaces but that day to day operations will never flag on its own, because the integration keeps working right up until the credential is compromised.

Broken object level authorization is the second category, and in an integration context it shows up most often as overly broad security group scopes. A Workday integration system security group that grants unconstrained access to a wide set of data instances when the integration only ever touches a narrow subset is a BOLA risk waiting for the wrong request to expose it, since the access exists whether or not the integration’s normal logic ever exercises it. The same pattern shows up in Infor as ION connection points with broader read or write access than the actual BOD flows require, and in MuleSoft as API client applications granted scopes beyond what their registered use case needs.

Improper inventory management is the third category, and it maps directly back to the work done in Step One. OWASP describes this risk as the result of an outdated or incomplete inventory creating blind spots in the attack surface, including APIs and integration points that exist in production but are missing from documentation, have no defined retirement plan, or are running in an environment, such as a staging or beta deployment, that nobody is actively securing because nobody remembers it is there. The inventory built in Step One is not just an operational convenience. It is the direct mitigation for this specific, named risk category, and an audit that skips the inventory step has not actually addressed improper inventory management no matter how thorough the rest of the security review is.

Where the integration in question handles personally identifiable information, this is the point in the audit to check that how personally identifiable information moves through enterprise integrations is being handled consistently with the data classification the field actually carries, since a security review that confirms access controls but never checks what data those controls are protecting has only done half the job.

Step Four: Performance and Failure Pattern Review

Security and inventory findings tell you where the risk is. Performance and failure pattern review tells you whether the integration is actually doing its job day to day, and the two assessments frequently surface different problems on the same integration.

Reviewing error logs and retry behavior starts with simply reading what the integration has logged over a meaningful window, typically the last several weeks, rather than relying on a dashboard that only shows current status. The goal is to spot patterns: an integration that retries the same failure repeatedly without ever succeeding is burning resources and masking a problem that retry logic was never designed to fix, since retries are appropriate for transient failures and counterproductive for persistent ones.

Checking for silent failures is the part of this review most likely to surface something an audit’s other steps miss. A silent failure is a process that reports success at the platform layer while failing at delivery, meaning the integration’s own logging shows a clean completion even though the data never actually reached its destination or arrived in a corrupted state. This is precisely the failure mode that makes integration downtime more expensive than it first appears, because detection lag, the time between when the failure occurs and when someone notices, can run for days when the platform’s own status reporting is telling everyone the integration is healthy.

Reviewing latency against current business requirements closes this section. An integration that was built to satisfy a latency requirement from two years ago may no longer match what the business actually needs today, in either direction: a batch process running once a day might now need to be near real time because a downstream process changed, or a high frequency polling integration might be running far more often than its actual data volatility justifies, burning API rate limit budget for no operational benefit. This is also the point where the difference between webhook based and polling based integration patterns becomes relevant to the audit, since an integration built on polling when the source platform now supports event driven delivery, or one built assuming webhook support that the platform never actually provided, is a structural mismatch that a latency review will surface even if the integration is not technically failing.

Step Five: Score and Prioritize Findings

An audit that produces a long list of findings with no way to triage them is not more useful than no audit at all. Every finding from the previous four steps should be sorted into one of five categories, and the category determines urgency far more than the technical severity of the finding in isolation.

Active failure covers anything currently broken or silently failing in a way that is producing incorrect data or missed transactions right now. These findings take priority over everything else regardless of what else is on the list, because every day they remain unaddressed compounds the data drift or compliance exposure they are causing.

Security risk covers findings from Step Three: broken authentication exposure, overly broad authorization scopes, and inventory gaps that represent attack surface. These are not actively failing, which is why they get found in an audit rather than a help desk ticket, but they carry risk that compounds the longer they sit unaddressed.

Redundant or orphaned covers the duplicate connectors, abandoned connection points, and forgotten CloudHub deployments surfaced in Steps One and Two. These are not actively harmful in most cases, but they expand the attack surface, consume resources, and create confusion for anyone trying to understand the current state of the integration estate.

Underperforming but functional covers integrations that work, are not a security risk, but no longer match current business requirements, typically surfaced in Step Four’s latency and performance review. These are candidates for improvement rather than emergency remediation.

Healthy covers everything that passes the audit cleanly. This category matters because it is easy to assume an audit only produces bad news, and a complete and current view of what is genuinely healthy is itself a valuable output, since it tells the organization where it does not need to spend remediation effort.

The point of this scoring exercise is not that every finding needs to be fixed before the new integration that prompted the audit can proceed. It is that the organization needs to know, with confidence, which findings the new integration would inherit risk from or duplicate effort with. A redundant connector that has nothing to do with the new integration’s data path can be scheduled for later cleanup. An active failure on a system the new integration will also touch needs to be resolved first, because building on top of a known active failure guarantees the new work inherits the same instability.

Turning Audit Findings Into Action

Different finding types call for different responses, and matching the response to the finding is where the audit’s value actually gets realized rather than sitting in a report nobody acts on.

A healthy backlog of findings, meaning a substantial number of underperforming, redundant, or undocumented integrations that need structured remediation but are not actively on fire, is the clearest signal for an integration consulting engagement that includes an audit and assessment phase. This is precisely the kind of work that benefits from an outside team running the assessment to completion and translating the findings into a prioritized remediation plan, rather than an internal team trying to fit the work in around its existing workload.

An active failure, by contrast, calls for immediate attention rather than a planning exercise. Root cause analysis and cross-platform troubleshooting support is the right starting point when the audit surfaces something currently broken, since the priority at that point is restoring correct behavior, not designing a long-term architecture.

Chronic recurring issues, meaning integrations that fail repeatedly and have already been through ad hoc troubleshooting multiple times without a lasting fix, suggest the underlying problem is not a single defect but an absence of ongoing operational discipline. A managed integration services model with built-in governance and monitoring addresses this pattern directly, because the recurring failures are usually a symptom of nobody owning the integration’s day to day health between incidents, and a managed model assigns that ownership permanently rather than reactively.

A legacy point to point script that the audit flags as fragile, undocumented, or built on a deprecated runtime is a different kind of finding, and it calls for a custom-built connector rather than a brittle workaround. Patching a script that was never designed to be maintained long term usually costs more in cumulative effort than replacing it with a properly built integration that follows current platform standards.

Once the immediate findings are addressed, the audit results should not be filed away. They are the input to a coherent integration roadmap rather than a list of one-off requests, because an organization that has just completed a full inventory and technical review of its integration estate is in the best possible position to plan what comes next with an accurate picture of its starting point, rather than planning new work against an assumed state that the audit has just shown to be wrong in several places.

This audit is not a one-time gate that clears the way for a single new project and then gets forgotten until the next request arrives. It is a recurring discipline, ideally run on a regular cadence rather than only when someone is about to add a new connector, because the integrations that were healthy at the last review do not stay healthy indefinitely. Credentials age, business requirements shift, and connection points that were active become orphaned without anyone deciding to retire them.

The next time someone proposes a new connector, the organization should already know the answer to what it has and whether it is healthy, rather than discovering the answer mid-project when a new integration collides with something nobody remembered was there. An audit that is current at all times is far cheaper than a discovery process that happens under deadline pressure after something has already broken.

Frequently Asked Questions

How often should we audit our integrations if nothing seems broken?

A full audit on a quarterly or semi-annual cadence is reasonable for most organizations, with a lighter inventory refresh whenever a new integration is proposed or a major platform release lands. Workday’s biannual release cycle and Infor CloudSuite’s continuous delivery model both introduce changes that can affect existing integrations without producing an obvious symptom, so an audit interval tied only to visible problems will miss the issues that fail silently.

What is the difference between an integration audit and integration monitoring?

Monitoring is continuous and automated, watching for specific signals like job failures, authentication errors, or latency spikes that have already been configured as alert conditions. An audit is a periodic, comprehensive review that asks whether the existing monitoring configuration, security scopes, and inventory are still correct in the first place, including integrations that monitoring was never set up to watch. Monitoring tells you about the failures you anticipated. An audit finds the failures and risks you did not know to look for.

Can we audit Workday, Infor, and MuleSoft integrations ourselves, or do we need outside help?

Organizations with an internal team that has deep platform knowledge across all three systems can run this audit internally, particularly the inventory and platform-specific technical review steps. The security review and the prioritization step tend to benefit from outside perspective, since internal teams sometimes have blind spots around integrations they built themselves and are reluctant to flag as risky. A hybrid approach, internal inventory work supplemented by an external assessment phase, is common for organizations without a dedicated integration architecture function.

What is the biggest risk of skipping an audit before adding a new integration?

The most common consequence is a duplicate connector or a conflicting field mapping, where the new integration moves data that an existing, forgotten integration is already moving, and the two write to the same downstream field with different transformation logic. The second most common consequence is inheriting a security gap, such as building a new integration against an ISU or OAuth client that already has broader access than it should, compounding an existing risk rather than introducing a new one.

How do we find integrations nobody on the current team remembers building?

Start with platform-native discovery tools rather than relying on memory or documentation: API Manager and the API Governance Dashboard in Anypoint Platform will surface unmanaged APIs directly, ION Desk shows every configured connection point and document flow regardless of who set it up, and Workday’s integration tracking views list every EIB, Studio integration, and registered ISU in the tenant. Cross-referencing what these tools report against what is documented is usually how the gap surfaces.

Does an integration audit require downtime or access disruption?

No. The inventory, technical review, and security review steps are read-only against the platforms involved and do not require taking any integration offline. The only point where disruption could occur is if the audit leads directly into remediation, such as rotating a credential or deactivating an orphaned connection point, and those actions should always be scheduled deliberately rather than performed as part of the audit itself.

What should we do if the audit finds an integration that is technically working but was built by a vendor we no longer work with?

Treat it as a priority documentation and ownership gap even though it is not an active failure. Confirm what the integration does, who currently owns its operational health, and whether the credentials it runs on are under your organization’s control rather than the former vendor’s. An integration still running on a departed vendor’s credentials is a control gap regardless of how reliably it is currently functioning, and closing that gap should happen before any new integration touches the same systems.

How long does a full integration audit typically take?

This varies significantly with the size of the integration estate, but a mid-sized organization running a mix of Workday, Infor, and MuleSoft integrations should expect the inventory and platform-specific review steps to take several weeks of focused effort, with the security review and prioritization adding additional time depending on how many findings surface. Organizations with no existing documentation of their integration landscape should expect the inventory step alone to take longer than the technical review that follows it.

Should the audit cover manual processes that aren’t technically integrations, like someone exporting a spreadsheet every week?

Yes. A recurring manual export and import process is functioning as an integration even though no code or platform connector is involved, and it carries the same risks: it can fail silently if the person doing it is unavailable, it has no documented error handling, and it is invisible to any platform-level monitoring. Excluding these from the inventory because they are not technically built on an integration platform creates exactly the kind of blind spot the audit is designed to close.

What happens after the audit is complete?

The findings get scored and prioritized as described above, active failures and security risks get addressed first, and the complete inventory becomes the foundation for ongoing governance rather than a one-time report. The most effective outcome is that the audit’s findings feed directly into a forward-looking integration roadmap, so that the next integration request is evaluated against a current, accurate picture of the estate rather than against assumptions that will need to be re-verified the next time something breaks.