User Management

Required Access Level

Super Admin — only users with the SUPER_ADMIN role can create and manage global users.

Reaching user management

Go to Global (Super Admin) → Users in the sidebar.

User list

The screen shows every user registered on the platform, with:

• Full name
• E-mail
• Status (Active / Inactive)
• Creation date

Use the pagination at the bottom to move between pages (20 users per page).

Creating a new user

1. Click New user
2. Fill in the fields:
   • First name and Last name
   • E-mail — this is the user's login (it must be unique on the platform)
   • Initial password — at least 8 characters. The 72-byte limit described in My Profile is checked when a password is changed, not here: creation accepts up to 100 characters and only the first 72 bytes end up counting at login. Stay under 72 bytes — accented letters and emoji take more than one byte each.
3. Click Create user

Communicating the password

The system does not send a confirmation e-mail automatically. Tell the user their credentials through another channel and ask them to change the password on first access.

Deactivating a user

In the list, click Deactivate on the user's row. The user loses access immediately, but their data and activity history are preserved.

There is no reactivation

No screen and no endpoint give a deactivated user their access back — editing the user changes only the first and last name. Reactivating requires intervention in the database by whoever operates the installation. Confirm the deactivation before applying it.

The roles you assign

The role is chosen when the membership is created, under Tenants → Members, and can be changed later on that same screen or in the user detail. There are four, from the smallest reach to the largest:

Role	What it reaches	What it does not reach
User	Starts processes, opens and completes their own tasks, fills in forms.	Everything else.
Manager	The User's reach, plus monitoring the instances of the whole company and editing the CMS and the knowledge bases.	Designing a process; administering the company.
Modeller	Designs, configures and publishes processes: catalogue, modeller, forms, decision tables, process roles, document types, AI agents, knowledge bases, CMS, the e-mail trigger rule (under the process's Configuration tab) and the e-mail deliveries. Uses the modeller copilot.	Robots and runners, API Keys, webhooks, mail inboxes and the company's people. They also do not see the whole company's instances: at runtime they see what a User sees.
Administrator	Everything the Modeller reaches, plus robots and runners, API Keys, webhooks, mail inboxes and company-wide monitoring.	Nothing inside the company; administering the platform is still the Super Admin's job.

Modeller is the role for whoever designs, and nothing else

Before it existed, anyone who needed the modeller had to become an Administrator — and the keys, the robots, the webhooks and the company's members came along with it. If the person designs processes and does not administer the organisation, their role is Modeller.

A Modeller spends the company's AI quota

The modeller copilot consumes tokens from the company's plan. Whoever gets the role can spend that balance without being an administrator. The consumption shows up per person under AI governance, and each person can be given their own ceiling in the user detail.

Company members remain an Administrator matter. Assigning a role is administering people: neither the Modeller nor the Manager reaches that screen.

Binding a user to a company

Creating a user does not bind them to any company automatically. For the user to reach a specific company's data, they must be added as a member of that tenant.

The role is chosen on that membership — Admin, Manager, Modeler or User. The Modeler designs, configures and publishes processes without administering the company, and is the only non-administrative role that spends the company's AI quota, through the modeler copilot.

See how in: Tenants → Members

Corporate sign-in (SSO)

Required Access Level

Super Admin — the configuration lives under Global (Super Admin) → Single Sign-On.

SSO is configured for the whole installation, not per company. That is not a limitation: a user is a platform entity and a company is an association they hold, so whoever authenticates cannot be picked by the company the person visits afterwards.

Registering a provider

1. Click Add provider
2. Fill in:
   • Name — shown on the login button (e.g. Entra ID)
   • Issuer — the platform reads {issuer}/.well-known/openid-configuration
   • Client ID and Client secret — from the application registration at the provider
   • Email domains — comma separated; the login screen uses them to decide between asking for a password and handing over to the provider
   • Auto-provisioning — when on, an unknown user is created on first sign-in
3. Save it disabled, use the test button to confirm the provider answers, and only then enable it

A domain belongs to one provider only

If acme.com were accepted by two connections, signing in would become a coin flip between them. The second registration is refused.

Secure the way back in before enabling

The platform requires at least one active Super Admin who can still sign in with a password, and refuses to enable a connection when there is none. A wrong issuer or an expired client secret locks everyone out, and without that user there is no way back that does not involve database access.

What SSO does not do

Signing in through a provider never links anyone to a company. A user created by auto-provisioning signs in and sees an empty company list until someone links them — the same link described in Tenants → Members. Roles do not come from the provider either: directory groups do not become Flowi roles.