Administration

A deployment of the workflow engine has one operator-facing surface beyond the editor itself: the Admin app. It’s where an operator manages who else can administer the deployment, and where OAuth2-based integrations from the ActivePieces catalog get switched on.

Roles

Every account is a regular user by default. An admin account can additionally open the Admin app and everything below — same login, same session, no separate credentials.

An admin can promote any other user to admin, or demote an admin back to a regular user, from the Users page.
An admin can’t change their own role — this avoids a deployment accidentally locking itself out of admin access.
A role change takes effect immediately — no re-login required, just a page refresh for the affected account.

The first admin

On a local or self-hosted stack running with the default seed, the built-in admin/admin account is already an admin — nothing to configure.

On a deployment with self-service signup (the hosted product), sign up normally first, then turn that account into an admin one of two ways:

List the username in the backend’s ADMIN_USERNAMES setting (comma-separated for more than one) and restart the backend once — every listed user is promoted on boot.

Or set the role directly in the database:

UPDATE users SET role = ‘admin’ WHERE username = ‘…’;

Further admins after the first one don’t need either step — just promote them from the Users page.

User management

A self-hosted deployment doesn’t let strangers sign themselves up by default. Accounts are created by an admin:

Create a user — on the Users page click “Create user”, enter a username and confirm. A random password is generated and shown once in a dialog (with a Copy button); hand it to the person. It is never stored in readable form and can’t be shown again.
Reset a password — click “Reset password” on a user’s row and confirm. The old password stops working immediately and a new generated one is shown once, the same way. There is no e-mail: forgotten passwords are always reset by an admin.
Change your own password — any signed-in user can use the “Change password” button (project list header, and the Admin app header) and enter the current password plus a new one of at least 8 characters.

Default-password warning. A fresh install seeds an admin/admin account. While that account still has the password admin, the project list and every Admin page show a warning banner with a “Change password” button; it disappears as soon as the password is changed. Change it before exposing the instance to the internet.

E-mail. The backend can send mail over plain SMTP — e-mail confirmation, password reset, the beta-application flow below and account-activation mails all depend on it. Without it every one of those simply does nothing (no error), passwords are reset by an admin as described above, and only the off/open signup modes make sense.

SMTP_URL — smtp://user:password@host:587 or smtps://user:password@host:465. Unset = mail not configured.
MAIL_FROM — the sender address (default noreply@localhost).
CLIENT_PUBLIC_URL — the public URL of the client app; every link in a mail (confirm e-mail, reset password) points at it. Falls back to the origin of BACKEND_PUBLIC_URL.

Public signup is controlled by these backend settings:

SIGNUP_MODE — off (default: the signup endpoint answers 403 and the login page shows no “Create an account” link), open (anyone registers with a username and password; an optional e-mail can be given and is confirmed via a link, but nothing is blocked until it is — a small “e-mail not confirmed” banner with a “send again” button is all), or application (a closed beta: the form asks for an e-mail, a company name and what automation the applicant is interested in — no password; see “Applications and activation” below). The older SELF_SERVICE_SIGNUP=true still works and means open. The local Docker Compose stack runs open.
TERMS_URL — optional. When set, signup shows a required “I accept the terms” checkbox linking to this URL, the backend rejects a signup without acceptance, and the acceptance time is recorded on the account.
CAPTCHA_PROVIDER — none (default) recaptcha (Google reCAPTCHA v2 checkbox) or smartcaptcha (Yandex SmartCaptcha), with CAPTCHA_SITE_KEY (client key) and CAPTCHA_SECRET (server key) registered for your domain with the vendor. The captcha guards signup and “Forgot password?”; if the vendor can’t be reached the request fails with 503 rather than passing.

With mail configured, the login page also offers “Forgot password?”: the user enters their e-mail and, if an activated account with that confirmed e-mail exists, receives a one-hour reset link. The response is the same either way, so the form can’t be used to find out whether an address is registered.

Applications and activation

In SIGNUP_MODE=application nobody creates their own account. A visitor submits an application (e-mail, company, the automation they’re interested in, the captcha and the terms checkbox), is told to follow the link in the e-mail, and must confirm the address — an unconfirmed application is never shown as ready. Once the e-mail is confirmed, every admin with an e-mail address gets a “new application” mail, and the applicant sees “Awaiting activation” when they try to sign in.

On the Users page an application shows its e-mail, company and an Activated column (“no”, or an “e-mail not confirmed” tag while the link hasn’t been followed). The “only pending activation” switch filters the table down to applications waiting for you; “Details” opens the full card (e-mail, status, company, interest, signup source, the registration/confirmation/activation dates).
Activate generates the account’s password (the same generator “Create user” uses), marks the account active and e-mails “your beta account is activated” with the login (the e-mail address) and that password, plus the advice to change it. If the mail can’t be sent (mail not configured or the SMTP server refused), the password is shown to you once in a dialog instead — hand it over yourself.
Until activation, signing in answers “your account is awaiting activation” — not “wrong password”. An account created by an admin with “Create user” is active immediately, as before; an optional e-mail can be given there and counts as confirmed.

User support

Every signed-in user has a Support button (project list, Runs and Tasks pages, and the editor toolbar) that opens a text chat with the deployment’s administrators; a badge on it counts unread replies. There is one thread per user, text only, no attachments.

In the Admin app the User support page lists the threads on the left (newest activity first, with an unread count per thread and a total on the menu entry) and the selected conversation on the right; type a reply and press Enter to send (Shift+Enter inserts a line break). Opening a thread marks the user’s messages as read. The lists refresh by polling every few seconds — there is no push channel.

With SMTP configured (see “E-mail” above), administrators also get an e-mail when a user writes (every admin with an e-mail address, or the addresses in SUPPORT_NOTIFY_EMAILS if that variable is set), and a user whose e-mail is confirmed gets one when an administrator replies — at most one e-mail per conversation per direction every 10 minutes, with a link back to the app.

Two settings harden what a user’s project can make the server connect to (all outbound connections to tenant-supplied addresses — “Sync structure”, model lists, and the like):

EGRESS_ALLOW_PRIVATE / EGRESS_ALLOWED_CIDRS — by default the backend refuses to connect to loopback, private (RFC 1918, CGNAT), link-local (including the cloud metadata address) and other reserved addresses, and never follows redirects. If your databases or model servers live on an internal network, set EGRESS_ALLOWED_CIDRS (for example 10.0.0.0/8,172.18.0.0/16), or EGRESS_ALLOW_PRIVATE=true to lift the restriction entirely (single-tenant self-hosting only; the local Docker Compose stacks do this).
ENABLE_SQLITE_INTEGRATION — false by default. The SQLite integration opens a file path chosen by the user, so it is not available unless you set this to true (a single-tenant installation or development).

Admin app

Open /admin on the same host as the workflow editor (a signed-in admin also sees an “Admin” link from the project list page). It has three pages:

Users — every account, with a role switch per row.
OAuth credentials — the platform’s OAuth2 clients for amoCRM and ActivePieces integrations, see below.
AI agent — the app-wide configuration for the editor’s AI editing agent, see below.

Per-user limits

The Limits button on a Users row opens that account’s quotas: maximum size of one file, maximum total size of a project’s files, the file lifetimes, and the maximum number of published versions running at the same time per project (default 3, or whatever the deployment’s MAX_CONCURRENT_PROD_VERSIONS setting says). An empty field means “use the deployment default”; a filled one overrides it for that account’s projects only.

Viewing a user’s projects

An admin can look into any user’s projects — for example to help with a support question — without being able to change anything. On the Users page click a user’s project count (or open “Details”): the card lists the user’s projects, and Open shows one in the editor in a new tab.

The project opens read-only: a “Read-only · owner: …” tag in the toolbar, no “+ Add”, no context menus or drag-and-drop in the project tree, and schemes can’t be edited. Nothing is saved automatically.
Available: every document and folder, the integrations list (secret values are masked, as for the owner), version history and comparisons (no “name the current version”, rename or restore), the generated code, the project’s runs with their run journal (no “Terminate”), JSON export and PDF.
Not available: the Dev/Prod menus (build, run, debug, publish), the AI agent and magic insert, the project’s files and tasks, and the run-journal settings.
The restriction is enforced by the backend, not only hidden in the interface: an admin may call only the project’s read routes, every write answers 404 exactly as for any other non-owner.

OAuth credentials — enabling OAuth2 integrations

amoCRM and the integrations from the ActivePieces catalog that authenticate via OAuth2 — Google Sheets, Gmail, Google Drive, Slack, and others — use one OAuth2 client per integration, owned by the deployment, configured once here. Users never paste a client ID or secret themselves; they just click “Connect”.

An integration with no configured client is disabled: it doesn’t appear in “add integration”, nor in the editor’s action picker, at all.

To enable one:

Open OAuth credentials in the Admin app and find the integration — it shows status “Disabled”.
Click “Configure”. The table and the dialog show the redirect URL to register in the vendor’s app — https://<your backend host>/oauth2/callback/<integration id>.
Paste the vendor’s Client ID and Client secret.
Save. The status switches to “Enabled”, and the integration becomes usable in every project.

Deleting a configured credential disables the integration again — existing connections for that vendor stop being able to connect or refresh.

Worked example — Google:

In
Google Cloud Console
, create an OAuth 2.0 Client ID of type “Web application”.
Add an authorized redirect URI of the form https://<your backend host>/oauth2/callback/<integration id>. The integration id is shown in the OAuth credentials table’s “Vendor” column — for Google Sheets it’s activepieces-google-sheets. For the hosted product, the backend host is api.workflow.falang.ru, so the redirect URI is https://api.workflow.falang.ru/oauth2/callback/activepieces-google-sheets.
One Google Cloud OAuth client can carry several redirect URIs — add one per Google integration you enable (Gmail, Google Drive, Google Calendar, Google Forms, …) rather than creating a separate client for each.
Paste that client’s Client ID and Client secret into the Admin app as described above.

What users see

Once an integration is enabled, it appears in the project’s Integrations editor vendor list like any other. Its credential form only asks for a Name (plus any vendor-specific non-secret fields) and a “Connect” button, which opens the vendor’s own consent popup — no client ID or secret field at all.

amoCRM example: in an amoCRM technical account, create an external integration with the redirect URL https://<your backend host>/oauth2/callback/amocrm (for the hosted product, https://api.workflow.falang.ru/oauth2/callback/amocrm) and the “Account data access” permission. Then paste its “Integration ID” as the Client ID and its “Secret key” as the Client secret into the amoCRM row.

Диадок still uses its own client ID/secret fields, entered per credential.

AI agent

How to use the agent, including its clarifying questions, is described on the AI agent page.

The editor’s AI agent (natural-language edits to a function document — click Agent in the toolbar to open its panel in the right-hand sidebar, next to History; only one of the two is shown at a time) needs one app-wide OpenAI-compatible endpoint before it can do anything. Nobody configures this per project; an admin sets it up once for the whole deployment on the AI agent page:

The agent isn’t limited to whichever document happens to be open — it can read and edit other documents in the project too, and create new function or trigger documents, as well as object-structure documents (the interfaces that describe your data’s shape — types only, never storage). It even works in a brand-new project with no documents at all yet: just describe what to build, and it creates the documents it needs as it goes.

Base URL — the vendor’s OpenAI-compatible API root, e.g. https://api.openai.com/v1 or any compatible provider.
Model — a plain model name, e.g. gpt-4o-mini.
API key — the vendor’s API key, stored encrypted with the deployment’s CREDENTIALS_ENCRYPTION_KEY.
Agent interface — how the agent edits documents: JSON files (the default and recommended one — it reads and writes whole documents and checks the project before finishing) or Node tools (one node per step; kept as a fallback).

Until this is configured, every user’s agent chat panel shows a “not configured, ask an administrator” notice instead of a send button — the agent simply isn’t usable yet. Editing the settings later leaves the API key field empty on purpose: submitting with it empty keeps the currently stored key, only the Base URL/Model change. “Reset” removes all four values and disables the agent for everyone again. Users never see these settings — not even which model the agent runs on: the editor only learns whether the agent is configured and which interface it uses.

This is a separate concept from the per-project “OpenAI” integration credential used by call-ai-text/ call-ai-choice nodes inside a workflow — that credential is unaffected and still configured per project, same as any other integration.

Project templates

“New project” offers a template picker: a template is a snapshot of a whole project (folders, documents, the integrations document with every credential’s secret fields blanked) that a new project is created from — the same format the project export/import feature uses. Templates live in the database and are managed from the Admin app’s Project templates page; a fresh deployment seeds exactly one, “Blank project”, so the picker is never empty. Picking no template creates an empty project, exactly as before.

Create — name, description, and one of your own projects as the source. The snapshot is taken at that moment; later edits to the source project don’t change the template until you click Refresh from project. “Editing” a template therefore means: edit the source project in the normal editor, then refresh.
Enable / Disable — a disabled template stays in the admin table but is hidden from the picker. The order in the picker follows the template’s sort order, then its name.
Upload JSON / Download — replace a template’s content with an export file produced by the project export feature (validated the same way an import is), or download the current content as one. Uploading detaches the template from its source project.
Delete — removes the template; projects already created from it are unaffected.