English
Governance
An organisation is one Mankomail instance. Its administrators decide what members may do — which nodes they can use, which senders never enter workflows, whether email can leave the instance at all — and hold the secrets members never see: OAuth applications, AI provider keys, API keys. This page lists every control, where it lives and what it changes.
Roles
There are two roles:
| Role | Shown as | Can |
|---|---|---|
member | Member | connect their own mailboxes, build and publish their own workflows, edit their own address book, scope and settings |
admin | Administrator | everything a member can, plus the Administration page and the administrator-only sections of Connections |
An administrator is a member with more rights, not a separate kind of account: they can connect mailboxes and build workflows like anyone else, or manage the organisation without any mailbox. Each member's mailboxes, workflows and runs belong to them; administrator screens show counts (mailboxes, published workflows), not other members' content.
The Administration page
| Tab | What it controls |
|---|---|
| Members | accounts, roles, invitations, deactivation |
| Scope | the organisation rules: senders that never enter workflows, for everyone (Scope) |
| Nodes | which nodes members may use (node policy) |
| OAuth applications | the organisation's Google and Microsoft applications, needed to connect mailboxes and Google or Microsoft services |
| API keys | keys that let outside systems call the API |
| Business calendar | what "business day" means for the whole organisation: working days, opening hours, public holidays and closures, used by waits and deadlines counted in business time |
| Sending | the send kill switch and the hourly cap |
AI providers, their models and their costs are managed on the Connections page, in sections only administrators see (see AI models).
Members and invitations
Inviting someone
- Open Administration → Members.
- Under "Invitations", type the email address, choose the role (Member by default) and click Invite.
- Copy the link and send it yourself, by the channel of your choice: Mankomail does not send invitations by email. "This link is shown only once: it is not stored and cannot be displayed again."
- The invitee opens the link, chooses a name and a password, then signs in.
An invitation is valid for 7 days. Pending invitations are listed with their expiry and can be revoked; an expired invitation must be issued again.
Changing a role. Choose the new role in the member's row. The last active administrator's role cannot change: the instance must keep one.
Deactivating an account. "Deactivate" cuts off a member at once. The dialog lists what will happen, then what actually happened:
- their sessions are revoked: sign-out is immediate;
- their mailboxes are disconnected: syncing stops (their mirror is kept);
- their published workflows are unpublished: their triggers are disarmed.
"Reactivate" restores access, but the member reconnects their mailboxes and republishes their workflows themselves. You cannot deactivate your own account, nor the last active administrator.
Node policy
Administration → Nodes lists the whole node catalogue, grouped as in the editor, with each node's effect — "No external effect", "Writes outside", or "Sends an email" — and one of three states:
| State | Effect |
|---|---|
| Allowed (default) | every member can use the node |
| Administrators only | the node disappears from members' add panel; administrators can still use it |
| Forbidden | the node disappears from everyone's add panel |
Where the policy applies:
- In the editor: a forbidden node is not offered when adding a node.
- At publication: a workflow that contains a forbidden node — or a node restricted to administrators, for a member — is refused with
workflow.forbidden_node("This workflow contains a node your organisation forbids, or restricts to administrators."). Disabled nodes are not checked. - When installing a template or accepting an analyzer proposal that contains a forbidden node.
Never at run time. A workflow published before a node was forbidden keeps running: "Workflows already using it stay readable, but publishing them is refused." To stop such a workflow, unpublish it, or stop sending (below).
The policy is per node type and per role; there is no rule per AI provider other than the node types themselves (llm.anthropic, llm.openai…). Through the API: GET and PUT /api/v1/admin/node-policy. PUT is partial: only the node types listed change, with { "entries": [ { "nodeType": "http.request", "allowed": true, "restrictedToRole": "admin" } ] }. Setting allowed: true and restrictedToRole: null returns a node to the default.
The send kill switch
Administration → Sending — "What actually leaves this instance — and the switch that stops it all." — shows the effective state ("Sending is ON" or "Sending is OFF") and the two switches it depends on:
| Switch | Set by | Changes |
|---|---|---|
| Instance | the SEND_ENABLED setting of the server (true by default) | only by editing the configuration and restarting; read-only on this page |
| Organisation | an administrator, with Stop sending / Resume sending | at once, without restart |
A message only goes out if both are open. Reopening the organisation switch does nothing while the instance switch is closed ("The instance has stopped sending (SEND_ENABLED=false).").
What "stopped" means:
- Held back: real sends — replies, forwards, new messages — from workflows, from approval requests and from the webmail composer.
- Still running: drafts, filing, labels, flags, analyses — everything that never leaves the instance. Workflows keep running.
- On reopening, what was held goes out. Nothing is lost, nothing is sent twice.
Use it when something goes wrong: a workflow that answers the wrong people, a loop, a doubt about a template. Then pause or fix the workflow, and resume sending. Through the API: GET and PUT /api/v1/admin/send-settings with { "enabled": false }; the response says lockedByInstance when the instance switch is closed.
Stopping workflows
There is no switch that suspends every run of the organisation. The levers are:
| Lever | Who | Effect |
|---|---|---|
| Pause a workflow | its owner | no new run starts from incoming emails, schedules or polling triggers; runs in progress finish |
| Unpublish a workflow | its owner | every trigger is disarmed; runs in progress finish |
| Stop sending | an administrator | no email leaves the organisation; everything else keeps running |
| Deactivate a member | an administrator | unpublishes all their workflows and disconnects their mailboxes |
See Draft, published version and history for pausing and unpublishing.
Sending limits
| Setting | Default | Effect |
|---|---|---|
SEND_MAX_PER_HOUR | 100 | hourly cap on sends. Above it, messages wait their turn — they are not lost. Shown under "Hourly cap" on the Sending page |
SEND_MAX_BYTES | 25 MB | maximum size of a composed message, attachments included |
Both are instance settings (see Environment variables). Providers apply their own limits on top: Gmail and Microsoft 365 limit the number of messages and recipients per day.
AI models and their costs
AI providers are configured once for the whole organisation, by an administrator, on the Connections page. Members never see the keys: "AI providers are configured once for the whole organisation, by an administrator."
An administrator:
- adds a provider (Anthropic, OpenAI, Mistral AI, OpenRouter, Ollama, or an OpenAI-compatible API) with its key — never shown again — and, where needed, its server URL;
- lists the enabled models of each provider: a model that is not enabled is refused when a node uses it;
- chooses Which AI for which use: a default, and optionally a model for each use (classify, compose, extract, general use, mailbox analysis, workflow assistant);
- reads AI usage and costs: the calls and the estimated cost, by period, for workflow runs (test runs included), evaluations, the analyzer and the assistant.
The instance limits calls to LLM_MAX_REQUESTS_PER_MINUTE per provider (60 by default). There is no spending budget: watch the costs under AI usage and costs. Each provider is described under Integrations.
Access for outside systems
OAuth applications. Google and Microsoft mailboxes, drives and calendars connect through the organisation's own OAuth application, registered once in Administration → OAuth applications: the page gives the redirect URI to paste in the provider's console and a step-by-step guide. The client secret is never shown again. See Google and Microsoft.
API keys. Administration → API keys creates keys for machine access to the organisation — "a CRM closing a case, a management tool reporting a signed mandate". A key is shown only once ("Copy this key now"); only a fingerprint is stored. Each key is granted what it may do; today the only permission is "emit signals (wake or cancel a wait)". Send it in the Authorization: Bearer … header. Revoking is immediate and final. See the API reference.
Templates
Templates are workflows ready to install, shared with the whole organisation. An administrator builds a workflow, then Promote to template makes it available to members; templates can be edited, disabled ("invisible to members") or deleted from the Templates page. Installing a template containing a node the organisation forbids is refused.
The audit log
Sensitive actions are recorded in an audit log, with who acted (a member, the system, or an incoming webhook) and when, never with secrets or email content. It covers:
- sign-ins, failed sign-ins and sign-outs;
- invitations, role changes, password changes, deactivations and reactivations;
- changes to OAuth applications, AI providers, connections, API keys and the business calendar;
- approval decisions, signals emitted and waits resumed by hand;
- pausing, resuming and deleting workflows;
- shared address-book imports;
- disconnecting and deleting mailboxes.
Changes to the scope, the node policy and the send switch are not recorded in it. The log is read through the API only, by administrators: GET /api/v1/admin/audit, filtered by action, actor and date. Entries are kept 365 days by default (AUDIT_LOG_RETENTION_DAYS, at least 30).