Why every important integration needs an owner.

Integrations are often treated as implementation work: connect system A to system B, test the data flow and mark the project complete. The operating problem starts later. Credentials expire. A field is renamed. An API changes. A business rule shifts. A source record is deleted. A queue backs up. The integration still exists, but nobody is clearly accountable for its continued behaviour.

That is how a technical dependency becomes an operational risk. When ownership is implicit, failures are discovered by downstream symptoms: a customer never receives something, a report is missing records, a team starts re-entering data manually, or finance finds that two systems no longer agree.

Every important integration should have someone who owns the business outcome, not merely someone who once built the connector.

Why integrations drift into having no owner

Integrations sit between teams. The sales platform belongs to sales operations, the finance system belongs to finance and the connector between them belongs, in practice, to whoever happened to build it. That might have been an implementation partner who has since left the engagement, an internal developer who has moved to other work, or a capable administrator who set it up on a Friday afternoon to stop a manual export.

Each of those people acted reasonably. The problem is structural. Project budgets fund the build, not the years of operation that follow. Application owners naturally look after their own platform rather than the connections leaving it. And because a working integration is invisible, nobody notices the ownership gap until something stops arriving.

The result is a common and uncomfortable pattern: the most important data movements in the company are the ones with the least clearly defined accountability.

Ownership is broader than administration

The owner does not need to write code. They do need to know what the integration is supposed to accomplish, which systems and processes depend on it, which failure states matter and who must be involved when it changes.

For business-critical integrations, document at least: source and destination systems, authoritative data ownership, trigger or schedule, authentication method, expected volumes, failure behaviour, retry logic, monitoring, escalation contacts, change dependencies and recovery procedure. Our guide on what to document before connecting two business platforms covers this in more detail.

Distinguish technical owner from business owner

Some integrations justify two forms of ownership. A technical owner is responsible for implementation health, credentials, logs, mappings and deployment. A business owner is accountable for the process outcome and can decide whether a change is acceptable.

Without the business owner, engineers can keep a technically correct integration running even after the process has changed. Without the technical owner, the business may know something is wrong but lack a reliable path to diagnose and repair it.

In a smaller business one person may hold both roles. That is fine, provided it is a deliberate assignment rather than an assumption.

Design for staff changes

Personal ownership is fragile when credentials, undocumented knowledge or administrative access sit with one employee. Microsoft's Power Automate guidance is explicit that the ownership model you choose affects the stability, security and compliance of flows. Its current documentation recommends service-principal ownership for critical or long-running flows, so they remain independent of specific users, and Microsoft also documents the operational problem of orphaned flows: flows that no longer have a valid owner and can fail when they use connections tied to that user's account.

The specific implementation differs by platform, but the general lesson is durable: important operational automation should not depend on one person's account or memory without a succession path. Leaver processes should include a check for integrations, scheduled jobs and connections that run under the departing person's identity. The same principle applies to designing workflows that can survive staff changes more broadly.

An illustrative example

The following is a hypothetical scenario, not a client case. A distribution business connects its e-commerce platform to its accounting system so that paid orders create invoices automatically. The connector was configured by a finance systems analyst using her own administrator account. Eighteen months later she leaves. Her account is disabled as part of a normal leaver process. The integration stops authenticating, but its failure alerts go to her mailbox, which nobody reads.

For three weeks orders continue to ship. Invoices are not created. The problem surfaces at month end when revenue looks unusually low. Nothing about the integration was badly built. What was missing was an owner other than the builder, a non-personal service identity, and an alert routed to someone who could act.

Make failure visible before customers find it

Ownership only works when the owner receives useful signals. Monitor successful and failed runs, unusual volume changes, authentication failures, backlog growth and business-level completeness where possible. A green API response is not enough if half the expected records never arrived.

Google's Site Reliability Engineering guidance on monitoring distributed systems frames monitoring around two questions: what is broken, and why. It also argues that rules which alert a human should be simple to understand and represent a clear failure. For an integration owner, that means alerts on symptoms the business cares about, not a stream of low-level noise that teaches people to ignore the channel.

For high-value flows, reconcile expected outcomes. If 1,000 source transactions should produce 1,000 destination records, the operating control should be able to detect a material mismatch. Our article on how silent automation failures damage operations explores why these gaps are so often found late.

Include integrations in change management

Integrations break when surrounding systems change without anyone considering the dependency. A field deletion, permission change, connector update or workflow redesign can alter behaviour even though nobody touched the integration directly.

Maintain an integration inventory and include it in platform change reviews. Before changing a source or destination system, ask which interfaces consume or write the affected data and what testing is required. This is one of the practical reasons uncontrolled configuration changes create operational risk.

Warning signs that ownership is missing

• Nobody can say, without investigation, which integrations exist or what they move.
• Failure notifications go to an individual mailbox, a former employee or a shared channel nobody monitors.
• Connections run under a named person's credentials.
• Teams have quietly started correcting or re-keying data that an integration is supposed to move.
• System changes are approved without anyone asking which interfaces depend on them.
• The only documentation is the original implementation proposal.

A practical ownership diagnostic

For each integration that the business would notice within a day if it stopped, answer these questions:

1. Who is the named business owner, and do they know they hold the role?
2. Who is the named technical owner, and do they have access to logs and credentials?
3. Whose identity does the integration authenticate as, and what happens if that account is disabled?
4. Where do failure alerts go, and how quickly would someone act on one?
5. How would the business know if the integration ran successfully but moved incomplete data?
6. Is the integration listed in an inventory that change reviews actually consult?
7. Is there a written recovery procedure that someone other than the builder could follow?

Any integration that cannot answer the first four questions is carrying unmanaged operational risk.

The trade-offs

Ownership has a cost. Naming owners creates obligations people may resist, monitoring needs maintaining and inventories go stale without discipline. Not every connection deserves the same treatment: a convenience sync that copies calendar entries does not need the controls of an order-to-invoice interface. The sensible approach is to tier integrations by business impact and apply the heavier controls only where failure would be expensive, visible to customers or hard to unwind.

What better looks like

A mature integration estate has named owners, documented dependencies, observable health, clear authority over data, tested recovery paths and an explicit process for change. When something fails, teams know who responds and what evidence to inspect. When a system changes, affected integrations are known before production breaks.

The objective is not bureaucracy. It is to prevent invisible technical connections from becoming unmanaged business dependencies.

Sources and further reading

• Understand flow ownership and access - Power Automate (last verified 10 October 2026)
• Manage orphaned flows when owner leaves organization - Power Automate (last verified 10 October 2026)
• Google SRE monitoring ditributed system - sre golden signals (last verified 10 October 2026)

Related Mellorca reading

• Why AI makes data quality more important, not less
• How to decide what should be the system of record
• How to decide which system owns which data