The enova365 service account — what read-only actually means

The fastest I have ever received working credentials to a production enova365 was the same afternoon. The slowest was five weeks. Same kind of work, same read-only scope, comparable companies. The difference had nothing to do with security policy. It came down to a licence slot.

That gap is the practical version of a question this series keeps circling. When I wrote about implementation timelines I called it the access lag: days from we agreed to the connector holds working read-only credentials against production, and a better predictor of go-live than ERP type, scope and portfolio size combined. This post is what sits underneath that number in one specific system.

"Read-only" is three different things, and people mix them freely

Start here, because almost every disagreement I have seen about integration safety turns out to be this confusion wearing a suit.

The first meaning is object rights: what the operator may do with a kind of record. Read a sales document, edit it, delete it. This is the layer everybody pictures when they say permissions.

The second is row-level restrictions: which records the operator sees at all. An operator can hold read rights to invoices in general and still be scoped to one organisational unit. The rights answer what, the restrictions answer which, and an integration can pass the first check while quietly failing the intent of the second.

The third is not in the permission model at all. It is the transport. An integration reading through WebAPI logs in as an operator and therefore inherits both layers above. An integration reading a SQL replica inherits neither, because a database connection has no idea the ERP's permission model exists. Both get described in meetings as read-only. One of them respects every restriction you configured; the other sees the payroll table.

Say that part plainly, because people skate past it. Read-only is not the same as harmless. An operator with broad read access across modules can see salaries, and a replica connection with broad rights certainly can. If your data protection story is "it only reads", you do not have a data protection story.

The licence is a better boundary than the permission tree

Here is the part that surprised me the first time and that I now design around.

The permission tree is configuration. Any administrator, any partner consultant with access, can widen it on a Tuesday afternoon, and nothing about that change announces itself — the same pattern as the custom-field drift in the post on pola własne. Whatever you scope today can be silently different in six months.

The licence is not like that. Which modules an operator's licence covers is a commercial fact, enforced outside the configuration screens, and widening it requires somebody to buy something. That makes it the one boundary in the installation that cannot be quietly loosened by a person working inside it.

So the practical move is counter-intuitive: buy the integration the smallest module coverage that does the job, not the most convenient one. If the agent's work lives in Handel, a licence that does not reach the payroll module is a stronger guarantee than any checkbox you could tick, and it survives staff turnover, upgrades and helpful reconfiguration.

One caveat, and it matters: licence terms in enova365 differ by contract, licence type and version, including whether a WebAPI session consumes a slot the way an ordinary login does. In every installation I have worked on it behaved like a login and needed its own headroom, but check your own licence file with your partner rather than trusting a general rule. That question also happens to be the first item on the list below.

Where the access lag actually comes from

Four questions decide almost all of it, and you can ask all four on day one, before any architecture is drawn.

Who owns the licence file, and is there a free slot for the modules the integration needs? If there is not, an access request has become a purchase, with a quote and an approval, and your one-day task now runs on somebody's procurement calendar. This single question explains most of the difference between the afternoon and the five weeks.

Who is allowed to create an operator? In a good number of installations the answer is the reseller, not the client, no matter what the client believes. That inserts a third company into a step everybody had assumed was internal.

Is there a test database, and is it a recent copy of production? A stale copy is worse than none, because it produces confident results about a schema that has since moved. If it is more than a few months old, plan on discovering things late.

Is the installation reachable at all from where the integration will run? VPN-only, on-premise machines are ordinary and fine, but the routing work is real and belongs in the plan rather than in the surprise column.

Ask these four and you will not shorten the lag by much on the first project. But you will know its size before you promise a date. That is the whole point. And if you are the one buying, a vendor who asks these four in the first conversation is telling you they have done this before.

Least privilege by observation, not by specification

Nobody can write down what an integration needs. Not you, not your partner, not the person who built the last one. The list you invent up front will be too wide in most places and missing exactly one thing that stops the job at eleven at night.

So stop specifying and start observing. Create the operator with close to nothing. Point it at the test database. Run the integration. Collect every refusal. Grant precisely those rights, and run it again.

Two rounds usually settle it, and the whole exercise fits inside a day. You finish with two artifacts: a permission set that is minimal because it was derived rather than guessed, and a written list of what this integration touches — which is the document the security review was going to demand anyway.

Keep the denial list. When the same integration needs a new capability in March, the diff against that list is the change request.

One account per integration, because the audit trail is the product

The liability post argued that an implementation never transfers risk; it produces evidence. In enova365 that evidence is concrete: documents carry the operator that created or modified them, and that is where the answer to who did this lives.

Which means running the agent on a shared account is not a minor hygiene lapse. It deletes the deliverable. If the agent logs in as Administrator, its actions are now indistinguishable from those of every human who has ever used that login — and no amount of logging on your own side repairs the record inside the ERP.

The rules that follow are short. One account per integration, named after it, so a person reading the document history in a year can tell what touched it. Nobody logs in by hand with it, ever. And when the same system graduates from reading to writing — the level three to level four boundary from that post — give it a second, separate account rather than widening the first. The blast radius stays bounded, and the history distinguishes the agent that proposed something from the agent that recorded it.

What breaks it six months later

Two things, and I have watched both.

The first is a password rotation. Somebody runs a security review, rotates operator passwords, nobody remembers the integration account is on that list, and the connector starts failing authentication into silence. This is the same failure I described in yesterday's post on the scheduler, and the same fix applies: the integration cannot be trusted to notice, so a heartbeat outside enova365 has to. Also put the service accounts on the rotation calendar itself, with an owner. Rotation is not the problem; rotation that forgets one account is.

The second is a version upgrade or a server migration, after which permissions come back changed and the integration either fails loudly or, much worse, quietly starts seeing less than it did. A job that suddenly finds nothing looks exactly like a quiet week. That is why the run summary should report what it examined and not only what it found.

Where I would start on Monday

Open the operator list and answer one question: which of these are people, and which are systems? In most installations the second group is not marked, sometimes not known. Name them, write down what each one is for, and note which are shared with a human. That list takes an hour and it usually finds at least one account nobody can account for.

Then, for the integration you care about most, run the four access questions and the observation pass. A day of work, and it removes the single most common reason these projects slip — not the build, but the wait.

If you want a second opinion, send me the module scope you think an integration needs and I will tell you which of the four questions is likely to be your bottleneck. Half an hour, no charge — get in touch.