Administration
This section is intended for administrators of the platform — users with the Admin or Super Admin role. The modeling pages (process catalog, decision tables, document types, process roles) also apply to the Modeler, who designs, configures and publishes processes without administering the tenant.
Where the administrative items are
The sidebar groups items by subject, and administrative work does not sit in a single group — modeling, robots, integrations and the global panel have groups of their own. Which groups and items you see depends on your role:
| Sidebar group | Items | Visible for |
|---|---|---|
| Processes | Instances · Tasks · Monitor | Monitor: Admin, Manager & Super Admin |
| Content | CMS · Knowledge Bases | Admin, Modeler, Manager & Super Admin |
| Automation | Robots · Runners | Admin & Super Admin |
| Integration | API Keys · Webhooks · Mail Inboxes | Admin & Super Admin |
| Modeling | Process Catalog · Decision Tables · Roles · Document Types · Mail Deliveries | Admin, Modeler & Super Admin |
| Modeling | Settings | Super Admin |
| Global (Super Admin) | Tenants · Users · Global Templates · Global CMS · Global Knowledge Bases · DMN Templates · Java Delegates · AI Settings · AI Governance · S3 Storage · E-mail Settings · Licence | Super Admin |
Where to look for what has no item of its own
- Settings opens the tenant's detail page — members, process roles, content export — and is Super Admin only: every endpoint the screen calls requires that role. A tenant admin does not see the entry, because seeing it would mean a permission error on every tab.
- Process Catalog is the item that holds each process's configuration.
- Agents is not a menu item. AI agents live inside each process, on the definition's AI Agents tab — alongside variables, business key, attachments, knowledge bases and self-learning.
Responsibilities by role
Super Admin
Has full access to the platform. Responsibilities:
- Create and manage companies (tenants)
- Create global platform users
- Publish global process definitions (BPMN/CMMN)
- Maintain base DMN templates
- Configure the platform's e-mail delivery (see below)
- Monitor overall platform health
Admin (of the tenant)
Manages their own company. Responsibilities:
- Bind users to their tenant and assign roles
- Configure decision tables (DMN)
- Manage forms and CMS content
- Configure automation robots
- Create API Keys and Webhooks for integrations
Licence
Global (Super Admin) → Licence shows the installed licence, who it was issued to, how long it is valid and how much of the limit is in use.
The licence is a signed file, verified on your own server. There is no licence server and nothing is checked over the internet: the signature already proves the origin, and a check that reached out would make your operation depend on someone else's availability — unacceptable at a customer that restricts outbound network access.
What happens when it expires is worth understanding, because it is not what people usually expect:
| Situation | What happens |
|---|---|
| Valid | Nothing |
| No licence | Everything works; the screen says none is installed |
| Expired, inside the 30-day grace | Everything works, with a warning |
| Expired past grace | Everything still works. The screen shows expired |
The platform blocks nothing because of the licence — not creating a company, not creating a user, not running a process. Companies and users are unlimited: the licence covers the software, not capacity.
Put that way so it does not read as an oversight: what it does is state who the installation belongs to and until when, visibly and unforgeably. Enforcement is contractual, not technical.
If the licence shows as invalid it was edited after being issued, or signed by another key — ask whoever issued it for a new one.
E-mail Settings
E-mail delivery is platform-global, not per company: a user belongs to the platform and the company link is an association, so a password reset would have no way to choose between one company and another.
Global (Super Admin) → E-mail Settings holds the SMTP server, port, user, password, sender address and the Platform address — that last one builds the links inside the messages; without it an e-mail would point nowhere, so the request fails instead of sending a broken link. The password is stored encrypted and never comes back to the screen: the field shows a mask, and leaving it untouched keeps the current one.
Send test delivers a message to the sender address itself and shows the server's own error when it fails, rather than only saying that it did.
What you are typing is not overwritten while you edit. The screen reloads the server's values on its own (when you come back to the tab, for instance), and until 2026-09-02 that reload wiped the field being edited — step away to copy the password and you came back to the old value restored. The reload now updates what is behind the screen and leaves your editing alone; saving puts the screen back to following the server. The same holds for Storage Settings, a company's AI quota and the tenant configuration JSON.
When a message does not arrive, the screen says so: a warning shows how many were given up on and the reason the server returned. They were retried eight times and are not resent — fix the cause and ask the user to request the e-mail again. Records older than 30 days are discarded automatically.
Two things depend on this and sit still without it:
- Forgot my password, on the sign-in screen.
- Inviting a new user: creating someone without a password sends them a link to choose their own. You can type a password at creation instead — no e-mail is sent then.
If SMTP is down the message is not lost: it waits in a queue and is retried with growing gaps, up to eight attempts. The user's request never fails because of it.
A delivery interrupted halfway is not resent
If the platform restarts exactly between handing the message to the server and closing the queue entry, nobody can tell whether it arrived. It then shows up in the failures list with the reason spelled out, and is not tried again: a resend could put a second live reset link in someone's inbox. Ask the user to request the e-mail again.
Starting a process from an e-mail
Unlike delivery, the inbox belongs to your company, not to the platform: you point it at the IMAP server you already use. That is so because, in an installation inside your own network, there is no mailbox of ours to receive anything — and because forwarding business mail through a third party's domain is the first thing a security review refuses.
Each inbox holds the server, port, TLS, user, folder and how often it is read. The password is not kept there: what is stored is the name of a Tenant Variable, written as ${var.name}, read only at connection time. No screen and no API response ever returns the password — a screen that can show an IMAP password is a screen that leaks one. Test connection opens the mailbox and shows the server's own error when it fails, without processing any message.
What each message becomes is decided by rules, in the order you set: a rule matches on recipient, sender or subject (contained text or a regular expression) and names the process to start. The first match wins. There is no AI classification here, deliberately: a misclassification would open the wrong process silently.
The started process receives six variables — emailFrom, emailTo, emailSubject, emailBody, emailDate and emailMessageId. The body arrives as text: an HTML message is converted, never rendered, and it is cut at 32 thousand characters — a long thread forwarded into the process arrives truncated. Attachments go to the instance, up to 10 files and 25 MB in total per message; whatever exceeds that is recorded in the reason, not silently dropped.
A reply carrying the [FLOW-…] mark in its subject, or answering a message the platform already knows, becomes a comment on the instance it answers instead of opening another — that is what keeps a five-message conversation from turning into five processes.
Everything that arrives becomes a row in the deliveries list, with its outcome: started, appended to an instance, refused or failed.
A refused message stays unread
When no rule matches, nothing is started and the message stays unread in the mailbox, with the reason recorded. Create the rule that was missing and the next read picks it up. The same holds for one that failed: if the process did not exist and you published it, the message is tried again.
The same message never starts two processes
Reading is at-least-once: the platform can start the instance and go down before marking the message read. Each message's Message-ID is unique per company, so reading the same message twice does not open a second purchase order.
Each role in detail, with what the backend and the frontend check, is in Roles & Permissions.
Starting a process from an e-mail — the screens
The E-mail Settings above are outbound. Inbound is a different thing and lives under Automation, per company: Flowi reads an IMAP mailbox of yours and starts a process from what arrives. Three screens.
Mail Inboxes
The mailbox itself: name, host, port, folder, username, how often to read it, and whether it is active. TLS is on by default — turning it off is a deliberate act, the screen warns that without it the password and every message travel in the clear, and the inbox is then flagged No TLS in the list.
The password does not pass through this screen
There is no password field. What you enter is a reference to a tenant variable — the same ${var.name} form the robots' secret parameters already use. Flowi stores the reference and resolves the password only when it connects; the screen never receives nor shows the password, not even after it is saved.
Every row shows the last poll and, when the last attempt failed, the error the server returned — an inbox that never polled says so, instead of looking healthy. Test connection connects and answers right away, without processing any message.
Rules
Opening an inbox takes you to its rules. A rule matches on recipient, sender or subject (containing a text, or as a regular expression) and names which process to start — the key and whether it is BPMN or CMMN — optionally with a business key template where the e-mail variables are available.
Order matters: rules are evaluated top to bottom and the first one that matches wins — the ones below it never run. The screen numbers the rules by that position and offers arrows to move them up and down; a rule with no criteria at all matches everything and is flagged as such, because it silences every rule after it. A new rule joins the end of the queue, so it does not jump ahead of what is already there.
Mail Deliveries
Every message read becomes a row here, with what happened to it: it Started a process, Appended to an existing instance (when it is a reply to a message the platform itself sent), was Refused, or Failed — with the reason, and a link to the instance when there is one.
The case this screen exists to solve is Refused: no rule matched, so nothing was started and the message is still unread in the mailbox, on purpose. Filter by Refused, look at the sender and subject nobody routed, and use Create the missing rule — the rules screen opens with those two fields already filled in. Once the rule exists, the next poll picks up the message that was left behind.
Quick Navigation
| I want to... | Go to | Where it is in the sidebar |
|---|---|---|
| Create a user | Users | Global (Super Admin) |
| Create a company | Tenants | Global (Super Admin) |
| Bind a user to a company | Tenants → Members | Global (Super Admin) |
| Configure e-mail delivery | E-mail Settings | Global (Super Admin) |
| Manage my tenant's members | Tenants → Members | Global (Super Admin) — today only the Super Admin manages members |
| Configure a process (variables, agents, attachments) | Definitions | Modeling → Process Catalog |
| Configure automation | Robots | Automation |
| Start a process from an e-mail | Mail Inboxes | Automation |
| See why an e-mail started nothing | Mail Deliveries | Automation |
| Integrate an external system | API Keys or Webhooks | Integration |
| Configure an AI agent | AI Agents | Modeling → Process Catalog → the process → AI Agents tab (there is no menu item) |
| Upload documents for the agent to consult | Knowledge Bases | Content |
| See and cap AI spend | AI Governance | Global (Super Admin) |
| Store an integration credential | Tenant Variables | Modeling |
| Classify a process's attachments | Document Types | Modeling |
| Publish a process to every tenant | Global Templates | Global (Super Admin) |
| Change my own password or picture | My Profile | user menu |