Companies — your colleagues, who opens which dashboard, and how they sign in

A company is a list of people and a sign-in rule. You create it, invite colleagues by e-mail, and from then on a situational dashboard can belong to the company and open only for the members you pick — no e-mail lists to keep, and every reader signs in the way the company requires. Everybody's account, plan and own dashboards stay their own.

1. What a company is, and is not

An access boundary inside one installation. Who may open which company dashboard, and whether members sign in with a password or with a one-time code as well. That is all it decides.
Not a data boundary. The operator of the installation still sees everything on its disks, as before. A customer who needs the data itself walled off runs their own installation — the platform works offline in one docker compose.
Not an owner of accounts. You join a company; it does not create you. Leaving it costs you nothing but the company's dashboards. Your plan, your Coins, your personal dashboards and your API keys are untouched.

2. Creating one and inviting people

Open Company in the bar (it appears once you have a company or an invitation). With neither, open Account: its Company block has a Create a company button. Creating a company takes a coin plan (Pro or Max); members may be on any plan, Free included.
Invite colleagues: one e-mail per line, and a role — Member or Administrator. An invitation lasts thirty days.
The colleague signs in with that e-mail (it must be verified by the sign-in service) and sees "⟨Company⟩ invited you — Accept · Decline". Only on Accept do they join. Nobody is put under a company's sign-in rule without saying yes.

Roles.

	Member	Administrator
Use the platform on their own plan	yes	yes
See the member list	yes, unless the company hides it	yes
Publish a blueprint into the company	yes	yes
Open a company dashboard	when picked, or when it is open to everyone	always
Manage every company blueprint — access, on/off, delete	—	yes
Invite, change roles, disable, remove members	—	yes
The sign-in rule, the company's name	—	yes
Transfer ownership, delete the company	—	the owner only

The owner is the person who created the company (or was handed it). There is exactly one, always an administrator, and the owner's membership cannot be changed or removed — transfer ownership first. One person is in one company at a time.

Disabling a member keeps the row and removes every access at once; removing deletes it. Either way the person's own things are untouched.

3. Company blueprints

A situational blueprint is personal or the company's.

A personal blueprint works as it always did: you and the e-mails you list open its dashboards.
Publishing a finished HTML dashboard offers Owner: Personal / ⟨Company⟩. A personal blueprint can also be moved into the company from its card on the Account page; its e-mail list is dropped when it moves.

On a company blueprint the e-mail list is gone. Instead, its card has Who may open the dashboards: a switch Everyone in ⟨Company⟩, or a picker over the member directory — by name or e-mail, the picked ones as chips. Administrators and the blueprint's creator may always open them. Readers come only from the directory, which is what keeps the company's sign-in rule over every one of them.

An administrator sees every company blueprint on the Account page and on the Company page, a colleague's included, and may change its access, switch it off or delete it. Delivering rows into a blueprint — from the ERP with a key, or from a file on the card — stays the creator's.

Deleting a company does not delete its blueprints: each goes back to its creator as a personal one, with no readers, and the dashboards already drawn live out their day.

The company page has a Sign-in setting:

Password — as every account signs in today.
Password + one-time code, once a day — every member is asked for a code from their authenticator app the first time they sign in each day; somebody who has none yet is asked to set one up. The rule covers the member's whole session, not only the company's dashboards: a member who opens anything on the site with a password-only session is sent to sign in again.

To switch it on, the administrator must first have signed in with a second factor themselves — the page takes care of that — so nobody can lock a company behind a rule the installation is not set up for.

If your people sign in with Google (or another sign-in service rather than a password here), the code rule is met only if the operator of the installation has set that service up to ask for it. Where that is not done, switching the rule on would leave those members unable to sign in at all — so try it with one such account before you turn it on for everybody. On dashgen.de Google is set up to ask for the code; a member with no code yet is shown how to set one up at the first sign-in. Accounts with a password here are not affected.

Lost your phone? The operator of the installation removes the code from your account in the sign-in service's console and you set it up again at the next sign-in. On dashgen.de, write to us.

5. The API key and a company blueprint

An API key is not a person: it is not asked for a code. That is safe because of one rule:

Through a key, on a company blueprint
`PUT …/instances/{reference}` — deliver rows, get the link	works, as for a personal blueprint
`?format=html` — get the drawn file back	refused, `403 api-key-read-refused`, before anything is charged — unless an administrator let the integration in (below)
`GET /api/v1/situational/instances/{id}/html` — open a drawn dashboard	not found, with the same exception
the contract	without its example rows
status, the list of deliveries, deleting a delivery	works — none of them carries data

So by default a key writes and never reads a company blueprint. A key that leaks can deliver rows (paid, visible in your Coin history) and delete deliveries; it cannot read a single row. The people who open the dashboards are members, signed in under the company's rule. A personal blueprint is unchanged: its key may still fetch the file.

For your ERP nothing changes: store the link and the expiry it gets back, open the link in the system browser, send again when it has expired.

Letting the integration fetch the file. When the ERP should show the dashboard in its own window — 1C's HTML field, a WebView2 in Business Central — it needs the file, not the link. A company administrator can allow that for one blueprint at a time: on the blueprint's card, Let the integration fetch the file…, then confirm. From then on the creator's key gets the file with ?format=html and fetches it again for free — see Getting the file instead of a link on the situational dashboards page — with no sign-in and no second factor. That is the point of the switch, and its cost: whoever holds the key reads every dashboard that blueprint draws.

Only an administrator sees the switch; the blueprint's creator as such does not, and a key can never set it.
The card says who switched it on and when; the Company page marks every blueprint where it is on.
Switching it off takes effect on the next call. Moving a personal blueprint into the company always starts with it off.
The contract still comes to the key without its example rows: those are the sample the design was drawn on, not a delivery.
Readers in the browser are unaffected: they still sign in under the company's rule.

6. What a reader can still do

An opened dashboard is one self-contained HTML file with its rows inside. A member with access can save it or forward it, and nothing in the browser prevents that. The guarantee is nobody off the list opens it on the server, not the data never leaves the company's people. Pick readers accordingly.

7. Limits

	Default
Members per company	500
Open invitations at a time	200
Members a blueprint can be opened to (beyond everyone)	500
Invitation lifetime	30 days
Companies per person	1