Tenant Management

Required Access Level

Creating and managing tenants globally: Super Admin.
Managing your own tenant: Admin.

What is a tenant?

A tenant represents a company or organization in Flowi Agentic. Each tenant's data is completely isolated: processes, tasks, bound users and settings belong to that tenant alone.

Listing tenants (Super Admin)

Go to Platform → Tenants to see every registered company, with status, creation date and the available actions. That sidebar group only appears for a Super Admin.

Tenant status

Status	Description
CREATING	Provisioning in progress (automatic, takes a few seconds)
ACTIVE	Operational — accepts users and data
SUSPENDED	Temporarily blocked — data preserved
DEACTIVATED	Deactivated — no access, data preserved
FAILED	Provisioning failed — check the logs

Creating a tenant (Super Admin)

1. Go to Platform → Tenants
2. Click New tenant
3. Fill in:
   • Slug — the company's unique identifier: 3 to 63 characters, lowercase letters, digits and _ only (e.g. company_abc). A hyphen is refused. It cannot be changed after creation.
   • Name — the company's display name
4. Click Create

The tenant is created with status CREATING. Provisioning is asynchronous — wait for the status to turn ACTIVE (usually a few seconds).

A tenant born without its processes ends up FAILED

Provisioning automatically installs the Global Templates marked for auto-provisioning. If any of them cannot be deployed, the tenant ends in FAILED and the error message names the templates that did not make it — instead of becoming an ACTIVE tenant missing the processes it was supposed to carry. Fix the global template and create the tenant again.

The same holds for decision tables (DMN) marked for auto-provisioning: one the engine refuses puts the tenant in FAILED, with its key in the message. An ACTIVE tenant missing a decision a process uses only shows up much later, when the first instance reaches the business rule and fails far from whoever created the tenant.

The slug is immutable

The slug is used as the database schema name and cannot be changed after creation. Choose carefully.

Mining patterns now

Autofill suggestions come from the daily count over the history, which runs overnight. Whoever has just loaded cases into a tenant (a demonstration, a pilot with imported history) or wants to check the learning does not have to wait for the next day. In the listing, the Mine patterns action on an active tenant redoes that count right away.

• The count runs in the background. The response only confirms it started, and the suggestions change within a few minutes.
• Only one mining run happens at a time across the platform. If the nightly run or another on-demand run is in progress, the screen says so. Try again when it finishes.
• It calls no AI and spends no token quota: these are counts over real decisions.
• The action only appears for active tenants, and only for the Super Admin.

Suspending and reactivating

• Suspend: blocks access for the tenant's users. Data is preserved.
• Reactivate: restores access as it was.

Use the matching option in the tenant's action menu.

Export and restore (Super Admin)

The tenant detail screen carries two end-of-lifecycle actions, gathered in the Tenant content export and restore (advanced) panel: generate the file of the company's schema, and restore a file generated earlier. That file is not a backup of the tenant — what it carries and what it leaves out is in Tenant content export, further down.

Download content export (.sql) runs pg_dump restricted to the tenant_<slug> schema and returns a plain-text .sql with no owner and no privileges (--no-owner --no-privileges). That is the file Upload and Restore (.sql) expects back.

Upload and Restore (.sql) does not run the uploaded file as it arrived. The dump is read end to end first and refused if it carries a construct that writes outside the tenant. The refusal names the construct and the line, so the mistake gets fixed instead of investigated:

Restore recusado: o dump contém alteração de search_path na linha 12 — SET search_path TO public

What is refused:

Construct	Why
SET search_path, or any set_config('search_path', …) other than the reset to empty that pg_dump itself writes	Redirects unqualified writes out of the company
CREATE SCHEMA for any schema other than the tenant being restored	Creates data outside the company
DROP SCHEMA, ALTER SCHEMA	Drops or renames a schema — public included
CREATE/ALTER/DROP ROLE, USER or GROUP, SET ROLE, SET SESSION AUTHORIZATION and role GRANT	Leaves database access behind that outlives the restore
COPY … FROM PROGRAM / COPY … TO PROGRAM	Runs a command on the database server
CREATE EXTENSION	An extension belongs to the whole cluster, not to the company's data
psql meta-commands (\!, \i, \connect, …)	\! is a shell and \i includes another file

What keeps working: every file the Download content export (.sql) button itself produced. The rows inside a COPY block are not inspected — a page, a prompt or a field whose text reads DROP SCHEMA public CASCADE; is company content, not a command, and the restore does not confuse the two. A function body ($$ … $$) is not inspected either, because defining a function is not running it.

The command runs bound to the tenant's schema (SET search_path TO "tenant_<slug>", passed outside the file), with ON_ERROR_STOP=1 and in a single transaction: either the whole dump went in or nothing did. A restore that dies halfway comes back as an error, carrying the part of psql's output that explains the failure — never as a success.

Restore a dump this product generated

The check refuses the constructs that turn a data restore into administration of the database. It is not a sandbox: a dump that names another schema explicitly (INSERT INTO public.…) is an ordinary SQL statement, indistinguishable from the company's own data. That is why restore stays Super Admin only, and why the guidance is to restore the file that came out of the Download content export (.sql) button rather than a .sql of unknown origin.

AI usage

The tenant's AI Usage tab shows, for the chosen period, who spent inside that customer and on which process step. The tables export to CSV.

The period is filtered by shortcut (7, 30 or 90 days, this month, last month) or by a free range. Mind a difference that looks like a bug and is not: the tenant's quota counts the billing cycle and does not follow that filter — it answers how much has been billed this cycle, while the tables answer how much was spent in the chosen period.

The detail of each column, and what a row with no person attributed means, is in AI Governance.

Members

The tenant's Members section controls which users have access to the company, and with which role.

Adding a member

1. Open the tenant's detail page (click the tenant name)
2. In the Members section, click Add member
3. Search for the user by name or e-mail
4. Pick the role:
   • Admin — administers the company: process catalogue, roles, document types, robots, API keys and webhooks
   • Manager — sees every instance and task in the company, follows the process step by step, and writes to the CMS and to the process documentation. In every other module behaves as a User
   • Modeler — designs, configures and publishes processes: BPMN/CMMN modeler and versions, forms, decision tables, process roles, process variables, document types, knowledge bases and AI agents, and the mail rule that starts the process. Uses the modeler copilot. Does not administer the company — people, robots, API keys, webhooks and mail inboxes stay with the Admin — and at runtime sees the same as a User
   • User — executes tasks, and only sees the instances they take part in
5. Click Add

The Modeler spends the company's AI quota

The modeler copilot and AI validation consume the company's tokens, so granting this role authorises spending by someone who is not an administrator. The governance report breaks consumption down per user, and a per-person ceiling exists — today it is set by the Super Admin under Platform → Users.

Removing a member

In the member list, click Remove on the user's row. The user loses access to the tenant immediately.

Process roles

Beyond the general role, each member can hold process roles — roles specific to a given process that determine which tasks they receive.

To assign one:

1. On the member's row, click Process Roles
2. Under Assign New Role, pick the role and the process it applies to
3. Click Assign

Tenant content export

The tenant detail screen has a Tenant content export and restore (advanced) panel. The Download content export (.sql) button produces a SQL file with the content of that tenant's schema.

This is not a backup

The file does not restore a tenant to a previous state. It carries only what lives in the tenant schema; everything operational lives in the shared schema and stays out.

What the file contains:

Content	Tables
CMS — collections, fields and records	cms_collections, cms_collection_fields, cms_records
Forms — definitions, versions and data sources	form_definitions, form_versions, form_data_sources
Attachments and documents	attachments
Tenant variables	tenant_variables
AI task failures	ai_task_failures
Test instances	test_instances
Vector store (RAG)	vector_store

What it does not contain:

• running process instances, tasks, jobs, timers and the whole history — the engine's ACT_* tables live in the shared schema, one single set for every tenant;
• AI agents, robots, runners, API keys, webhooks, notifications, published definitions, document types, tenant settings, AI quotas and the AI usage log — also in the shared schema, separated only by a tenant_id column.

The file itself opens with a header repeating that inventory, so it keeps explaining itself after it leaves the screen that produced it. A full platform backup is still a backup of the whole database, taken by infrastructure — not by this screen.

Data retention

Under Administration → Data retention, the tenant Admin (or the Super Admin with the tenant selected) decides how long the company keeps three things the platform deletes on its own, every night:

Table	What goes	What never goes
Process and case history	instances that ended longer ago than the window, with activities, tasks, variables and comments	a running instance
AI step reservations	the record of each attempt of an AI step, once finished	the reservation of an instance still running; AI usage billing does not change
Robot executions	finished executions, with their log	the latest execution of each robot

Deletion is permanent

Nothing is archived first. What leaves does not come back — not from the screen, not from support. If an audit obligation asks for longer, choose a longer window or turn the table off.

Each table has three choices:

• Installation default — whatever the operator configured applies (by default, off: nothing is deleted). If the operator changes the default later, the company follows it.
• Off — keep everything — nothing of that table is deleted for this company. When the installation sets a maximum, the option stays on the card but disabled: the table cannot be kept forever.
• Delete after N days — whatever is older than N days leaves the next night.

The number of days stays between the installation's minimum and maximum, shown on each table's card (by default, a minimum of 90 days for history, 7 for reservations and 30 for executions, no maximum). A value outside them is refused. If the operator changes the bounds later, the night adjusts the saved window to the new bound and the card warns that the choice is outside the bounds — save again to make it explicit.

While you edit, the card shows the preview: how many rows the next night would remove with that window. It is an estimate — each night removes up to a ceiling per table, and the rest leaves on the following nights. With no edit in progress, the preview shows the window the night actually uses: a saved choice left outside the bounds shows already adjusted to the bound, and Off under a maximum shows the maximum — the card only says nothing is deleted when nothing is.

Every change is recorded under Latest changes: who changed it, which table, from what to what, and when. Modelers, managers and users neither see the screen nor can change the window.

The installation operator can switch the per-company choice off (RETENTION_ALLOW_TENANT_CHOICES=false). The screen then says so at the top, the options are locked and the installation window applies to every company — a choice saved earlier is kept but ignored until the operator switches it back on.

What a tenant Admin sees

If you are an Admin but not a Super Admin, you do not see the list of all tenants: the Platform and Global catalogue groups do not even appear in your sidebar, and their screens do not open by URL. Neither does the tenant detail screen — members, process roles, content export: it is served by endpoints that require Super Admin, so the Company settings entry is not shown to you and the URL redirects to the Dashboard.

What a tenant admin administers today is what has a screen of its own: Process Catalog, Process Roles, Document Types, Robots, API Keys, Webhooks and Data retention. Changing your tenant's members is a request to the Super Admin.