Flow Ownership: Owners, Backups, and Contacts

Ten past three in the morning. The monitor says the payment file to Bluewater Bank did not arrive, and the on-call administrator has the inventory open. The row says Tier 1. It does not say who decides whether to resend a file that might already have been half-processed. It does not say who at the bank can confirm what they received, or who to wake if the answer is "nobody knows." The inventory has told them what broke. On who, it has nothing to add, and neither does the wiki page, which was accurate once.

Ownership is the answer to "who." For every flow it names the person accountable for it and the person who operates it. It also names the person who steps in when the operator is away, and the people on the far end. Most transfer estates hold this information in someone's head or in an email thread from two reorganizations ago. This article puts it in the inventory and in a contact sheet beside it. It shows how to keep the names true when people change jobs, which they do without consulting the inventory.

By the end you will be able to fill the three owner columns of the inventory built in the transfer inventory. You will be able to build a contact sheet the inventory points into and write a one-paragraph RACI for a flow. You will also be able to run a monthly check that catches owners who have left. This article is part of our Flow Documentation series, and we continue the example of Meridian Parts, a fictional distributor with about forty flows.

Owner Versus Custodian

The first mistake is to write one name in an "owner" column and consider the job done. A flow needs two different kinds of person, and they are rarely the same one.

The business owner is accountable for the flow's existence and its outcome. They can answer "does this still matter?", "what does it cost us if it is late?", and "may we change it?" They are the one who is embarrassed when it is wrong. For Meridian's nightly orders export, the business owner is the logistics manager. She does not know what SFTP is and does not need to. She knows that if the orders file misses the freight partner's four o'clock deadline, tomorrow's deliveries slip.

The technical owner, also called the custodian, operates the flow: watches it run, fixes it when it breaks, makes approved changes, and keeps its documentation true. For the orders export that is the transfer administrator. He knows the host key, the task name, the retry behavior, and the fact that Sunday's file is always small. He cannot decide to stop sending it; that is the owner's call.

Why both? Because the two questions that come up at three in the morning belong to different people. "How do I restart it?" is a custodian question. "Is it safe to resend, or will the bank pay everyone twice?" is an owner question. A custodian who answers it alone is guessing with someone else's money. A flow with only a technical owner has nobody to make business decisions. A flow with only a business owner has nobody who can log in.

In small teams one person sometimes fills both roles — the finance analyst who both owns and operates the bank file. Write the name in both columns anyway. When that person leaves, the roles will go to two different people, and the inventory should already show that they are two roles. The name typed twice is cheaper than the argument later.

RACI in One Plain Paragraph

RACI is a way of writing down who does what for a task, using four letters. Responsible: the people who do the work. Accountable: the one person who answers for the result — there is exactly one A per task. Consulted: people whose input is needed before the work is done. Informed: people who are told afterwards. That is the whole idea. It exists because "the ops team handles that" hides the difference between the person who fixes the thing and the person who signs off on it. That difference is exactly what you need at night. The owner columns encode most of a flow's RACI already. But for a Tier 1 flow it is worth writing out once, as below for the orders export, because it exposes gaps. The partner is consulted before a schedule change, and somebody has to remember that. Until it is written down, somebody is nobody.

Read the third row again. It is the one that matters at night. The custodian does the resend, but the business owner is accountable for the decision. So the runbook for this flow must say "call the owner before resending" and the contact sheet must say how. Duplicate payments are a real outcome of skipping that call; the reasoning behind safe resends is covered in safe reprocessing patterns.

The Backup Owner

The backup owner is the person who operates the flow when the custodian is unavailable. Not "the team" — a named person. Teams do not answer pages; people do. The test of a real backup is short: have they run this flow, from the documentation, at least once, without the custodian in the room? If not, they are a name on a list, and a name on a list is what fails at three in the morning.

Three rules make backups real:

• Access before absence. The backup has the same access as the custodian today — the vault entries, the server logins, the scheduler rights. This is not a promise to be granted access "if needed." Granting access during an outage means finding someone with rights to grant it, at night.
• One rehearsal per flow. The backup runs the flow once by hand, or works through a simulated failure, following only the runbook. Every gap they hit is a documentation fix. The full version of this drill is the hit-by-a-bus test.
• Spread the load. If one administrator is custodian of thirty flows and backup for the other ten, the estate has one point of failure with two job titles. Aim for no person appearing in more than half the rows in either column.

At Meridian, the transfer administrator is custodian for most partner flows and the systems administrator is backup; for internal flows they swap. The finance analyst who owns the bank file is also its custodian, so the transfer administrator is her backup. The transfer administrator has run the bank flow once in the test environment. That took an afternoon, and it was well spent. I have never seen a rehearsal that found nothing.

Partner Contacts and Escalation

Half of Meridian's flows touch an external organization. For those, the person who can actually fix a problem is often not at Meridian at all. If Acme Freight's SFTP server rejects the login, the custodian can check the key and the host, but the fix lives with Acme. So the inventory needs an external contact — and, more precisely, a set of them. One number is not a plan; it is a hope.

For each partner, record at least three routes. The technical contact is the desk or person who looks at connection problems: the EDI support team, the file services operations group. The business contact is the person on their side who cares about the flow's outcome — Acme's dispatch planner. That person should hear "your file will be late" before their morning starts. The escalation contact is who you call when the technical contact does not answer: a named manager, with the understanding that you will use it rarely. For each, note the channel (a ticket address, a phone number, an email), and the hours they are staffed. A support desk that answers between six and ten is no use for a two o'clock failure. Knowing that in advance changes what the runbook says to do.

Contacts are one half of the partner relationship. The other half is what each side has promised the other — file by what time, response within how long. Those promises belong in the partner agreement, described in partner SLAs and expectations. The contacts are gathered in the first place during onboarding, per the partner onboarding runbook. The inventory does not repeat any of that; it points to it.

The Contact Sheet

Owner and contact details do not belong in the inventory row itself. If Acme's support desk changes its email address, you want to fix it once, not in the seven rows that mention Acme. So the inventory holds a contact reference — a short key — and a separate contact sheet holds the details. The sheet is a small table, one row per contact, internal and external alike. This is Meridian's, trimmed:

A few design notes. The contact_id is what the inventory's owner and contact columns hold, so it must be stable. A role-based key like MER-TXADMIN outlives the person in the role. The login half of the name column is only for internal people and is what the leavers check below uses. hours is the column people forget and the one that decides what a runbook can promise. escalates_to turns the sheet into a chain: follow it upward until someone answers. And last_verified is a date and initials, because a contact that nobody has confirmed in a year is a guess. A guess in a table looks exactly like a fact.

Keep personal mobiles out of any copy partners can see, and keep the sheet somewhere reachable when the transfer server is down. A printed copy in the on-call folder is not old-fashioned. It is the copy that works when the wiki is behind the VPN that is also down.

Keeping Names Current When People Move On

Ownership records rot faster than any other part of transfer documentation, because people change jobs more often than flows change shape. A custodian is promoted, a partner's EDI desk is outsourced, the logistics manager goes on leave — and the inventory still names them. Nobody notices until the night the name in the row does not answer. The accounts outlast the people for the same reason, which is the subject of why transfer accounts outlive their owners.

Kestrel Payroll found this out during a routine failover test rather than a real outage, which is the good way to find it out. The tester followed the escalation chain on the contact sheet for the bank file. The custodian's extension rang in an empty office. The backup's number belonged to someone who had moved to a supplier, and the escalation manager had retired the previous summer. Every entry on the sheet had been right when it was written. The fix was the quarterly "still mine?" review below, plus a rule that leaving the company means leaving the contact sheet in the same week. The next test reached a human on the second call.

Three habits keep names true. First, tie ownership to the joiners-movers-leavers process. When someone leaves or changes role, the checklist that removes their accounts also asks "which inventory rows name this person?" It reassigns those rows before the leaving date, not after. The same checklist already covers their keys and service accounts — see retiring keys at offboarding and service account hygiene. So ownership is one more line on that checklist. The whole checklist is in offboarding that closes the account.

Second, review ownership on a cadence, alongside the access reviews you probably already run for compliance. Once a quarter, each business owner receives the list of rows that name them and replies "still mine" or "not mine, try X." Owners who do not reply after two reminders are treated as unknown, which triggers the orphan process below. This is the same muscle as periodic access reviews for transfers, and auditors like seeing the two done together.

Third, automate the cheapest check: are the internal logins in the owner columns still active in the directory? If the contact sheet stores each internal person's login, a short script can compare it to the directory every month. This example uses the Active Directory module for PowerShell. If your directory is different, the shape is the same. Read the logins, ask the directory whether each is enabled, report the ones that are not.

# owners-still-here.ps1 — flag owners whose directory account is gone or disabled
$contacts = Import-Csv .\contact-sheet.csv | Where-Object { $_.organization -eq 'Meridian' -and $_.login }
$inv      = Import-Csv .\transfer-inventory.csv | Where-Object { $_.status -eq 'active' }

foreach ($c in $contacts) {
    $u = Get-ADUser -Filter "SamAccountName -eq '$($c.login)'" -Properties Enabled -ErrorAction SilentlyContinue
    if (-not $u -or -not $u.Enabled) {
        $rows = $inv | Where-Object {
            $_.business_owner -eq $c.contact_id -or $_.technical_owner -eq $c.contact_id -or $_.backup_owner -eq $c.contact_id
        } | Select-Object -ExpandProperty flow_id
        "{0} ({1}) is missing or disabled; named on: {2}" -f $c.contact_id, $c.login, ($rows -join ', ')
    }
}

Schedule it monthly and send the output to whoever is custodian of the inventory itself. An empty report is the normal result; a non-empty one is a row to fix today. The first run is rarely empty, and ours named four people. For external contacts there is no directory to query, so the check is human. Once a year, send each partner contact a short note asking them to confirm the details. Record the reply in last_verified. Partners who are being offboarded get removed from the sheet as part of partner offboarding, at the same time as their accounts.

Flows Nobody Wants

Every estate has a few orphaned flows: rows where the owner has left, or where the seed pass found a scheduled task nobody recognizes. The temptation is to leave the owner column blank and move on. Do not. A blank owner is a decision deferred to the worst possible moment, and the worst possible moment always keeps the appointment.

Use a simple adoption-or-retirement rule. When a flow's owner is unknown, the inventory custodian sets status: suspended in the record. This is not on the server — the job keeps running for now. The custodian then sends a note to the likely candidates: "FLOW-0031, warehouse scanner uploads, has no owner. If this is yours, reply within thirty days. Otherwise it will be switched off on the date below." One of two things happens. Someone claims it, usually quickly and often with the words "I didn't know that still ran." Or nobody does, and the job is disabled on the announced date. In that case, the row moves to retired after a further month of silence. Either way, the estate ends up with one fewer unknown.

Be careful with the switch-off. Disable the scheduled task rather than deleting it, keep the script and configuration, and note in the row how to re-enable it. A flow quiet for a month can turn out to be the quarterly extract that only mattered in month three. The cautionary version is the file that never arrived.

Writing It Into the Inventory

The inventory has three owner columns — business_owner, technical_owner, backup_owner — and one external_contact column. Each holds a contact_id, nothing more. When a flow has several external contacts, the column holds the technical one and the contact sheet's escalates_to chain leads to the rest. The runbook for the flow, built in runbooks per flow, is where the chain is spelled out in order. Try this desk, then this manager, then wake the business owner.

Ownership also has a natural home on the server side. On a hosted server with per-account settings, such as Sysax Multi Server, the sensible convention is one account per partner flow, named for the partner. So an inbound account called acme_orders tells the on-call administrator which contact sheet row to open before they have found the inventory. The same naming habit applies to scheduled tasks in an automation tool. A task named FLOW-0012-bluewater-payments carries its own pointer back to the row and its owners.

Finally, ownership feeds the alerting design. An alert to a shared mailbox is one everyone assumes someone else is reading. An alert to the custodian named in the row — and, if unacknowledged, to the backup — gets acted on. The mechanics are in alerting that gets read; the inventory is where the routing table comes from.

Wrapping Up

Every flow needs a business owner who can make decisions and a custodian who can make changes. It also needs a backup who has actually run it, and a route to the people on the other end. The inventory holds references; the contact sheet holds details, with hours and an escalation chain. Names stay true when offboarding reassigns them, quarterly reviews confirm them, and a monthly script catches the ones that slipped. Orphans get adopted or retired on a published date, never left blank. Then, at ten past three, the row can answer who.

With owners in place, the next question is what each flow depends on — mapping flow dependencies. Another is what the named custodian should actually do when it breaks — runbooks per flow. And the proof that the backup column is real comes from passing the hit-by-a-bus test.

Frequently Asked Questions