The join between your two systems is logged in as somebody. Ask who

The orders stopped copying themselves into the accounts system on a Tuesday in July. Nothing announced it. No bounce, no error, no red banner on anybody's screen, and the figures carried on looking plausible because the last batch had landed the week before.

What happened on that Tuesday was that somebody in the office changed their password.

The setup screen asked a question nobody heard as a question

Every join between two systems is signed in as something. When yours was set up, a screen said "sign in to continue" or "connect your account", and the person setting it up did exactly that, while logged in as themselves. That was the decision. It did not look like one.

So the join runs on a person. Not on the business, and not on the software: on a named employee, with their password, their authenticator app and their permissions attached to it.

There are three things it could have been signed in as, and they behave very differently the moment anything moves:

That person's own account, which is what the setup screen asks for by default
An account the business owns, which nobody uses to read email or sit in meetings
A credential issued to the software itself, belonging to no person at all

Most small firms have the first one, everywhere, and have never been told the other two exist.

This is not only about somebody leaving

Leaving is the version people have heard of, and it is the least interesting one, because at least a leaver's last day is a date somebody wrote down. The quieter triggers are all ordinary housekeeping:

A password change, whether on a schedule or after a scare
A new phone, and an authenticator app registered again from scratch
A licence removed to save a few pounds a month, which can take the sign-in with it
A sign-in policy tightened, so a consent given two years ago no longer satisfies it
The person themselves tidying up their account and revoking an app they did not recognise

There is an uncomfortable overlap with security advice here. The most effective thing you can do after a convincing phishing email is reset the password and sign that person out everywhere, immediately. That is the right call and we would give it again. It also stops every join in the building that was signed in as them, and nobody has the list, so the firm spends the following fortnight discovering its own integrations one complaint at a time. If the underlying question is how somebody got in at all, we have written about that separately.

The correct security response and the quiet outage are the same action. Only one of them gets written down.

It inherited their permissions, which is the half nobody thinks about

A join signed in as a person can reach whatever that person can reach. That cuts three ways.

It usually has far more access than the job needs. The director's login is the most common choice, because the director was sitting there when it was set up, and the worst available: the thing that needed to read one folder can now reach the payroll and the bank.

The audit trail then records a real person doing it. Every automatic action in the log carries somebody's name, timestamped at four in the morning. When you eventually need to know who changed a record, the log answers with a person who was asleep, and that answer is no use to an insurer or an auditor.

And when the person's role changes, the join changes with it. Access they no longer need gets removed, correctly, and something that has run for two years starts returning less than it used to. It does not fail. It just quietly reads a narrower slice of the world, for a reason nobody will connect to a job title.

Which joins deserve an identity of their own

Not all of them, and this is where a lot of advice overreaches.

If a join is cheap to notice and cheap to restore, leaving it on a person's login is a perfectly reasonable answer. A calendar feed one person uses, a folder that syncs to their laptop, anything they would re-authorise in two minutes on the morning it stopped. Clicking a consent again twice a year costs less than building something formal around it, and a firm that insists on being rigorous about everything ends up being rigorous about nothing.

The ones that should not sit on a person are narrower than people expect:

Anything that moves money or reads a bank
Anything feeding a filing, a return or a payroll run
Anything whose output a customer sees
Anything whose failure would be noticed late rather than loudly

The last one is the real test, and it has nothing to do with how important the join feels. It is about the size of the gap between breaking and being noticed. A nightly sync that someone opens every morning can live on a personal login quite safely. A monthly one feeding a report nobody reads until the quarter ends cannot.

Three columns, and it is always the third that is blank

The record worth keeping is short. For each join: what it connects, what it is signed in as, and what tells you when it has stopped.

Most firms can fill in the first column from memory and the second with an afternoon's asking. The third is almost always empty, and the empty third column is the entire reason a July outage gets found in September.

That column does not need software. In a ten-person firm the honest version is that the output carries a date, and somebody looks at the date. A weekly glance at when each thing last updated catches more than any alerting you will realistically finish setting up.

Moving one off a person

01Find what the join is signed in as, from the platform's own list of connections
02Identify or create the account the business owns, with its password in the business password manager
03Re-authorise the join as that account in a quiet hour, while the old sign-in still works
04Confirm the thing it produces actually moved, not just that the screen says connected
05Write an owner's name against it, and the date you next expect it to update

The awkward step is the second one. Some platforms want a paid licence for an account that exists only to hold a connection, and a few will not let you have such an account at all. Where that is the case, the next best thing is a personal login chosen deliberately rather than by accident: not the director's, with the joins it carries listed somewhere findable, so that the next password reset is a decision instead of a surprise.

Why we see this one often

Integration is a service we sell and a thing we have built. The practice platform we built next door runs live joins to Xero, Companies House and HMRC, so what a connection is signed in as is a question we have had to answer properly rather than click past. Migrations are where it surfaces for everybody else: taking a client from on-premise Exchange to Microsoft 365, or an ageing phone system onto Teams Phone, the joins that break at cutover are reliably the ones nobody could say what they were logged in as.

This sits one level below the automations nobody owns. That question is what a thing is for; this one is what it is signed in as.

If something stopped arriving and nobody can tell you when it last worked, whose login it was using is the first question, not the last.