The integration ran under a person's login, and that person left

If the integration stopped the morning after somebody changed a password, it is running under a person's login. That is not an operations slip to be repaired with a new password. It is a design decision made implicitly, and it will keep failing — on the next rotation, the next leaver, the next licence review, and the next role change made for entirely human reasons.

The outage is the cheap half. The expensive half is silent: every record the integration touched carries an employee's name, so the vendor's audit trail, any per-advisor report and any question beginning with who did this now contains a person who was at lunch. At 200 writes a day that is 4,000 mis-attributed rows a month.

Read the last hundred automated actions and see whose name is on them

1. In the system of record, list the last 100 actions your integration performed — appointments created, customer records updated, notes written, statuses changed. Use the DMS or CRM's own activity view rather than your application's log, because the question is what the vendor believes happened.
2. Record the user shown against each one. If a single human name appears on all 100, the integration has no identity of its own, and everything below applies whether or not anything has broken yet.
3. Check whether that person is still employed, still licensed and still in the same role. Ask whoever administers seats, not whoever set the integration up.
4. Find where the credential physically lives: an environment variable, a secrets manager, a spreadsheet, or one engineer's password manager. Write down every person who can read it today.
5. Ask what happens to that login on the leaver checklist. If accounts are disabled within 24 hours of departure, the integration's expected life is one resignation.
6. Check the inbound direction too. Where the feed is a scheduled export rather than a live interface, the same seat usually owns the export schedule, so a disabled account stops the file instead of the write — and a missing file looks exactly like a quiet Tuesday unless the loader is built to notice, which is building a change stream from a full nightly file.

Four ways a named seat dies, and one failure that never announces itself

What a human's name on 4,000 writes costs

Downtime is visible and gets fixed within the day. Attribution damage compounds quietly, because it makes every per-person number wrong and makes the record useless for the one purpose an audit trail exists to serve.

• Per-advisor and per-technician reporting. The integration's work sits on top of one person's real work and no report can separate the two — the mapping problem underneath is making who did this answerable across three systems.
• Disputes. Where the row is the evidence — an authorisation, a note about what a customer approved, or which software version a vehicle carried when work was signed off, which is why a software update can invalidate a repair record — a wrong name is the difference between a record and an argument.
• Access reviews. A login used by a person and a machine cannot be right-sized. The person needs screens, the machine needs a narrow set of objects, and what gets granted is the union of both.
• Offboarding. Nobody disables a leaver's account when disabling it stops the shop, which is the moment the credential outlives the employment relationship everyone assumed it was tied to.

The general argument — a delegated user token against a shared service account, and the conditions under which each is right — is set out in delegated user token vs shared service account. The rest of this page is the dealership-specific part: who has to be asked, and what to do while you wait for the answer.

The request to put to the vendor before anyone scopes the build

This cannot be engineered around. Whether an integration may hold its own identity is decided by the vendor's user model and by what the dealer's agreement permits, which makes it a scoping question rather than a build question. The wider list is the access questions to answer in writing; these are the identity rows.

1. Ask for a non-human identity named for the function rather than the person, and get the answer in writing from whoever administers the dealership's account.
2. Ask whether it consumes a user seat and what that costs. If it does, put the seat in the contract, because an unclaimed seat is the first one a licence review reclaims.
3. Ask whether it is exempt from interactive password rotation and, if not, what the supported rotation mechanism is and who triggers it.
4. Ask which permissions can be granted to it object by object, and refuse the default bundle — the same argument that supports asking for fewer fields than they offer.
5. Ask how its actions appear in their audit trail. An identity that shows only as API user with no further detail is half a fix.
6. Ask who at the dealership can revoke it, and confirm the dealer holds that control rather than you or an aggregator in the middle.

An integration without an identity of its own is not integrated with the system. It is impersonating somebody who works there.

Interim controls while that request sits in a queue

• Move the credential into a secrets store the dealership controls, and remove it from the repository, the config file and the 3 chat threads it was pasted into. Whoever holds the store holds the integration.
• If the vendor genuinely offers named seats only, create the seat for the purpose and register it to a role-based mailbox the dealership owns, so password recovery does not depend on one person's inbox.
• Put that seat on the leaver checklist as a named exception with an owner, so offboarding pauses on it deliberately instead of breaking the shop by accident.
• Alarm on authentication failure, not on the symptom. A credential rejection should page inside 15 minutes, and queued writes should stay visible while it is unresolved — the queue-for-a-human pattern is already the design where write access is closed, in the read-only-first playbook.
• Log your own actor on every request you make, so you can still answer which automation performed which write even where the vendor's trail cannot show it.

One related question tends to arrive with this one. If a model is drafting the note, the reply or the summary that the integration then writes back, ownership of the credential and ownership of the data are the same conversation: whose environment holds the customer's words at the moment of the call. That has 4 real answers rather than 2, ordered by cost and control in private and on-premises deployment.

Swapping the identity without losing a day of writes

1. Run both identities in parallel for one business day, with the new one performing a small, reversible class of write — a note, not an appointment — and confirm it appears correctly in the vendor's own activity view.
2. Re-point everything in the quiet window, and verify the first production write under the new identity shows the right actor before the shop opens.
3. Backfill nothing. Do not rewrite historic rows to the new actor: those rows are a true record of what the system was told at the time, and rewriting evidence to tidy a migration is the worse outcome.
4. Record the changeover date where reporting can read it, so any per-advisor report spanning it can exclude the integration's rows on both sides of the line.
5. Disable the old login inside the same week — a Monday is the wrong day for it, a Wednesday is the right one — and watch what breaks. Anything that does is a second integration nobody documented.

An agent that books, updates and writes back needs an identity of its own before it needs anything clever, which is where we start when scoping AI agents and automation. This page belongs to DMS, CRM and shop-system integration, inside our automotive retail and aftermarket work.

• dms integration
• credentials
• audit trail
• vendor access