The account that took down a night job for two days
Two winters ago I lost a Tuesday and most of a Wednesday to an overnight job that had stopped writing invoice records into Dataverse. Finance noticed first, when the previous day's numbers went missing from their morning report. The integration said nothing. No failed run, no alert, no ticket, no history of it starting at all.
The cause was a password change. A colleague working through an expiry report reset the credential on an account called svcint01. Nothing on it told him what it did. No description, no owner field, no ticket history. He filed the new password in the team vault and moved on. Four integrations used that credential, and one of them read the vault at runtime.
Two days of five people's time went into finding that, and the fix took four minutes. Nobody could say who owned the account, so nobody could say what would break if it changed. That is the normal state in most estates I walk into.
Every identity process you have was written for people
Joiners, movers and leavers is the frame underneath every identity process in the building. Somebody starts, gets a manager, picks up an entitlement set, changes team, gets reviewed, leaves, gets deprovisioned. HR triggers both ends and the manager confirms anything doubtful. Every link in that chain assumes a person.
A service account has none of it. No HR record, no manager, no start date anything acts on, no termination event. Access certification in Salesforce or Workday hands a reviewer a list of people and skips whatever has no manager attached. The account keeps its permissions through the departure of whoever built it and the retirement of the integration it was built for. So the most powerful credentials in the estate get the least attention. Ask your platform owners for one list of every service account across your platforms and time how long it takes to arrive.
One shared account is cheaper until you have to revoke it
The first design decision is whether one integration account covers everything crossing a system boundary or whether each integration gets its own. Shared is what most estates have, usually because the first integration was built in a hurry and the second reused the credential that already worked. It is cheaper in licences and quicker to set up.
The bill arrives when something goes wrong. If a credential is suspected of exposure you revoke it. With a shared account, revoking it stops the order feed, the case sync, the nightly extract and whatever the analytics team wired up last quarter, and you find out which of those existed by waiting for the complaints. One account per integration means the damage stops at the thing you meant to touch.
Dataverse and Salesforce both record the acting user on every change, and a shared account puts the same name on every write, so identifying which process made a change turns into matching timestamps against run histories in four systems. My default is one account per integration. The licence objection is real on platforms that charge per user, and it still costs less than two days of five people. That same ability to tell one process from another sits underneath integration error handling that pages a named person.
Name it so the next person knows what it feeds
Naming looks trivial and does more work than anything else here. The account in my story was called svcint01. The person who reset it had no way to know it moved invoice data from an order system into Dataverse. A name carrying the owning team, the integration and the environment would have stopped that incident at the first step.
The convention I use reads left to right, general to specific. A fixed prefix marking it non-human, then the owning team, the integration, the environment. Something shaped roughly svc-finops-invoice-sync-prod. Where the platform gives you a description field, fill it with one sentence and a pointer to the record holding the owner. Dataverse, Salesforce and ServiceNow all have somewhere to put this, and those fields are empty in most estates I review.
One secret in one place, and a rotation you have rehearsed
The credential belongs in one store the runtime reads, rather than in four places people copied it to. What I usually find is a secret pasted into a Power Automate connection, the same one typed into a ServiceNow MID Server configuration, a copy in a team password manager, and a copy in the personal notes of whoever set it up. Rotation then means finding all four, and the fourth is the one nobody remembers.
Put it in a vault the integration reads at runtime. Azure Key Vault behind a Power Platform connection, a named credential in Salesforce, the ServiceNow credential store. Rotation becomes one write and the consumers pick it up. Where a platform refuses to read from a vault, record every location the secret is stored and make that list a step in the rotation procedure. Then rotate one low-traffic integration in a test environment and watch what breaks, because the breakages tell you where the copies are.
Who can read the vault is a separate decision and a larger one than it looks. Anyone able to read a production integration secret can operate with that integration's rights, and the audit log will not tell them apart. Keep that list short and review it on the same cycle as the account. The method in the Salesforce permission audit applies just as well to a vault access policy.
Nobody owns it, and that is what makes the incident slow
A service account with no named human owner is the normal state, and it is what turns a four minute fix into a two day search. During those two days every conversation ended the same way. Somebody thought the integration belonged to the data team. The data team thought it arrived with a vendor implementation two years earlier. The vendor had gone.
Record the owner outside the platform that holds the account. A ServiceNow configuration item, a register the platform team keeps, or a table in a governance environment all work. You need to read that list when the platform is the broken thing, and no single platform can hold accounts that live in five. If you already have an integration map drawn before the roadmap, that is the natural home.
The owner is one named individual with a named deputy, never a team mailbox. Next to the owner goes a review date, and the review asks three things. Does this integration still run. Are these still the permissions it needs. Is the owner still here. Ownership drifts the same way automation ownership drifts when the maker moves on, and the fix is a date in a field somebody acts on.
Narrow the scopes and alarm on behaviour you have never seen
Most service accounts carry more rights than their integration uses, because granting broadly is the fastest way to get a build working and narrowing later never happens. Start instead from the objects the integration genuinely touches, which you can read off its mapping, and grant exactly those. In Dataverse that is a security role scoped to named tables. In Salesforce it is a permission set whose object and field permissions match what the integration writes. An integration writing three fields on an account record has no business updating the other sixty.
Service accounts are the easiest thing in the estate to baseline, because their behaviour is boring by design. Same endpoints, same hours, same volumes, same objects. An alert on a first-seen object, a call outside the usual window, or a volume jumping by an order of magnitude catches both a stolen credential and a developer who pointed a new process at an old account.
Pick one production integration account this week. Write down who owns it, what it reads, what it writes, and where its secret is stored. If you cannot fill in all four inside an hour, you have found the account that will cost you two days. The identity topic hub collects the related pieces on reviews and exceptions.
