IT — what you set up, and what you can switch off

An IT lead has a small and concrete job in Business-Gym: decide who holds which role, register the machines that act on your behalf, keep the connections alive, and know where the switch is that stops everything at once. All four are done in a browser, by a signed-in person.

The good news for a risk review is that the platform is propose-only today. Nothing executes on its own, and external sending and anything touching money are human-approved permanently — see the hard floor. Your configuration decides who may approve, not whether approval happens.

What do I have to set up before anyone can use this?

Your setup surfaces are grouped together in the sidebar under Admin, and there are six of them. The Audit log sits separately, under Measure.

• People — the employee directory and org chart. Distinct from Team.
• Team — app account membership: who has a login, and with what role.
• Integrations — the connectors. A disconnected connector puts a red badge on this sidebar entry.
• Data sources — tabular source bindings.
• Operators — the desktop operator registrations, and their one-time tokens.
• Settings — tenant policy and configuration.

A sensible first pass is Team, then one knowledge source, then the connectors your departments actually need. Getting started walks the knowledge-source and mailbox steps in order.

Which roles can I hand out, and what does each one allow?

Business-Gym ships exactly four membership roles, and the Team screen shows friendlier names than the values it stores. Both are listed here so a permission question and a screenshot agree with each other.

Stored value	Shown on the Team screen	What the screen says it covers
owner	Owner	Full control — billing, members, and every head
admin	Admin	Manage heads, workflows, and integrations
approver	Member	Approve cards and run workflows (offered as the recommended default)
read	Viewer	View-only across the workspace

Roles are cumulative, not a set of separate permissions: read < approver < admin < owner. An owner satisfies every check an admin does, and an admin satisfies every check an approver does. That is why you will not find a screen where you tick individual capabilities — there is no per-permission matrix, only the ladder above.

Roles are held per membership, so the same person can be an admin in one tenant and a viewer in another.

Note

Role names are load-bearing. If a deck or a spec you have been sent names a fifth role, it is describing something the product does not have. Who can approve, and where covers the approval side of the same four roles.

Who can invite and remove people?

Only an owner can invite a member or remove one. An admin can open Team and read the member list, but the invite and remove calls are refused below owner — and that is enforced on the server, not just hidden in the interface, so an admin cannot get around it with a direct request.

The invite dialog asks for an email address and a role, and it tells you plainly that invites and role changes are recorded in the Audit log. That much is verifiable — the entries are there.

About the compliance line on the audit page

The audit page describes itself as DSGVO- and GoBD-aligned with ten-year retention and a per-run trace. That is what the screen says; treat it as the screen’s own label rather than as an attestation these docs can confirm. The per-run trace is real and you can read it. The retention period and the compliance status are not something documentation can establish — the same product’s settings screen still lists those attestations as pending. If a retention guarantee matters to your audit, confirm it in your data-processing agreement and with your own advisor, not from this page.

Two fields on the invite dialog do not do anything yet

The dialog also offers a Heads scope picker, a personal note, and a choice between an Entra ID lookup and an email link. Only the email address and the role are actually sent. Per-head scoping is not enforced today — a Member you invite can approve across the workspace, not only in the heads you ticked. Plan your access model on the four roles, not on the scope pills.

The audit log’s Download, Send and auditor-access buttons are disabled today. You can read the log in the app; you cannot yet export it from that page to hand to an auditor.

How do I register an operator without leaking a credential?

An operator is a desktop agent you register to a machine, and its credential is a one-time token that is shown to you exactly once. Business-Gym stores only a hash of it, so it is genuinely not re-fetchable — not by you, not by support, not from the database.

Registering is short. On Admin ▸ Operators, press + Register Operator, enter the operator’s email address, and the token appears in a banner that tells you to paste it into the desktop app now. The registration itself is written to the audit trail; the token never is.

Three controls sit on every operator row:

• Rotate — issues a new one-time token. The previous token stops authenticating instantly.
• Revoke — flips the operator to revoked and its token stops working.
• View activity — opens a Token audit (register, rotate and revoke events, with who did them) and the recent directives that operator was given.

Each row also carries a health badge — online, offline, needs re-login or revoked — plus its capabilities, its session states and its queue depth. Those fields fill in once the operator heart-beats; before its first check-in a freshly registered operator shows almost nothing, which is expected rather than broken.

Caution

There is no way to read a token back. If someone closes the banner before copying it, the fix is Rotate, which issues a fresh one and invalidates the old.

When you issue a directive to an operator from this page, the Requires approval box is on by default. Operators drive tools you are already logged into; they do not create an exemption from the approval gate described in inbound → approve → execute.

How do I stop the whole team at once?

The Global panic switch lives on the Heads page, and one click drops every head back to supervised — meaning every action requires approval, whatever each head’s own dial says. You do not walk down a list changing dials one at a time.

Only an owner or admin sees the toggle, and the server enforces that and audits the change. Everyone else sees a read-only banner — Panic active — all heads supervised — but only while the pause is on, so nobody is left guessing why the system went quiet.

It does not erase your configuration. Per-head dial settings survive the pause and come back when you press Release panic. What it changes is what a head is allowed to do right now. More detail in the autonomy dial and the panic switch.

Be clear about what the switch is not: it is not a kill switch for the application, it does not sign anyone out, and it does not disconnect your integrations. It forces the safe mode, which today is already the mode everything runs in.

What keeps a connection alive, and what happens when one lapses?

Microsoft access tokens are time-limited, so the connection card is built to warn you before a sync starts failing rather than after. Inside a fourteen-day window before expiry, the connected card shows a token-expiry pill next to a Renew now button that restarts the consent flow.

Outside that window there is no renew control at all. That is deliberate — a permanently visible warning teaches people to ignore warnings.

If a token has already lapsed or a grant was reset, the card switches to a Reconnect needed state with a Reconnect now button, and it states that no folders or synced documents were lost. You reconnect; you do not rebuild.

And when a step needs a connector nobody configured, it says “not connected” and the item queues. It is never reported as done and no result is invented. That honest stop is the designed behaviour — see integrations for the per-connector matrix, and data sources for how knowledge sync is scoped.

What can I only do on a laptop?

Every surface on this page is web-only, and that is a design decision rather than a gap. Team and permissions, integrations setup, knowledge-base management, settings and billing all require a browser on a real machine.

There is no native mobile app — nothing in either app store — and no push notification infrastructure. Your phone will not buzz when something needs approving; Teams and email digests are the notification path. Approving itself does work in a mobile browser on the responsive approvals page, so the practical split is that a phone is for deciding and a laptop is for configuring.

If a colleague is travelling and needs a role changed or a connector added, that waits.

What is not there yet?

These are current limits, listed so you find them here rather than mid-rollout.

• Per-head scoping on invites — the picker exists on the dialog, but only the email address and role are sent. Access is governed by the four roles alone.
• Audit export — the download, send and auditor-access buttons on the audit page are disabled.
• Custom or granular roles — not available. The four-role ladder is the whole model.
• DATEV — not connected. Nothing reaches it today; see DATEV.
• Native mobile app and push notifications — not available.
• Autonomous execution — not available, and not a gap. The platform proposes; a person approves.

Can several people — or several companies — share one account?

Yes for people, and only partly for companies. One Business-Gym workspace is built for a whole team: an Owner invites colleagues by email address from the Team screen, and each person holds one of the four membership roles the product ships — owner, admin, approver and read. The Team screen displays the last two as Member and Viewer, but the four names above are the whole list; see Who can approve, and where. Only an Owner can invite or remove someone, and you need at least Admin rights to see the member list at all. A role is held per company, so the same person can be an Owner in one workspace and a Viewer in another.

Two honest limits. Business-Gym does not send the invitation mail for you. Inviting reserves that person’s place in the workspace immediately, and they are joined the moment they first sign in with that same address — so tell them to expect it. The Entra ID / Email link choice in the invite dialog makes no difference to what happens: both simply record the address and the role. And an existing member’s role cannot be edited. The role control in the member dialog looks live but does not save; the route that works is to invite the same address again with the new role. Restricting a colleague to particular Heads is likewise offered in the dialog but not applied.

“Several companies” means two different things. You can belong to more than one workspace and switch between them from the company switcher, and nothing crosses over: every record that belongs to a company is filtered to that company, and a read that reaches across companies is refused rather than quietly answered. But creating a second workspace from inside the app is not possible yet — that button is deliberately disabled rather than half-wired. If instead you run a group of GmbHs under a single workspace, Settings → Multi-entity links to an Entities page that records each legal entity and the ownership between them: the parent entity, its percentage share, co-owners from outside the group, and whether an entity is winding down. Any member can read that list; adding, editing and deleting an entity is Owner-only. One combined invoice across those entities is not built and is marked “Coming soon”.

Next: hand the four roles to the people who will use them in who can approve, and where, or see what a department actually does with this setup in finance.