Service accounts

An identity for software — an integration, a scheduled export, the support desk — that holds roles like a person, never signs in to the console, and is never asked for a second step.

Two-step sign-in is right for every person and wrong for every script: a program that signs in with a password is asked for a code it cannot type. A service account is the identity software uses instead. It holds roles and companies exactly as a person does, so every screen grant, org-unit confinement and duty rule applies to it — but it has no password anybody knows, the sign-in form refuses it, and it cannot use the personal or interactive parts of the console (preferences, personalization, the dashboard, the assistant, two-step set-up, the system console).

1. Open Platform → Access & Security → Access → Service Accounts (beside Users) and choose New service account.
2. Give it an address that says what it is for (nightly-export@service.yourcompany), a name, and a sentence on what it does.
3. Tick its roles. Give it the narrowest role that does the job: a role with display on Purchase Orders and nothing else is a key that can read purchase orders and nothing else.
4. Optionally limit it to addresses (an IP or an IPv4 range such as 203.0.113.0/24), shorten its token lifetime, or give it an expiry date.
5. Create it. The secret is shown ONCE — copy it into the program that will use it. It is stored only as a fingerprint and cannot be read back.

The program exchanges the secret for a token that lasts minutes, and sends the token on every call like any other bearer token:

POST /api/auth/service-token
{ "client_id": "nightly-export@service.yourcompany", "secret": "txs_…" }

→ { "token": "…", "expires_in": 3600, "companies": [ … ] }

GET /api/scm/purchase-orders
Authorization: Bearer <token>
X-Company: <company id>

• New secret issues a replacement and stops the old one at once. Tokens already issued run to their expiry unless you end them.
• Revoke stops the secret AND ends every live token on its next request.
• Deactivate retires the account; its name stays on every audit row it wrote.
• Every token is a session: it appears under Platform → Access → Web & User Sessions, and can be ended there like anybody's.
• Wrong secrets count towards the same lockout a wrong password does, and every exchange is in the audit log.
• Somebody who may manage service accounts but is not an administrator can give one only roles they hold themselves, and never Administrator.

The support desk's account

Every deployment carries one service account it did not have to create: support-desk@service.tranxact. It is provisioned by the deployment itself from a secret the vendor sets when the deployment is installed, so nobody in your company has to issue anything for your tickets to be answered. It holds the Support desk role in every company, which reads and answers support tickets and their attachments — and opens no module and no other screen. It is listed with "set by the deployment"; revoking it is your decision and the deployment will not overrule it.