Features

This page lists what BPMS does today. Each feature works on the BPMS 3.x database, so it uses the users, roles, and tenants that 3.x already holds.

Users sign in with their BPMS 3.x username and password; nobody needs a new account.
Passwords are upgraded to Argon2id on the first successful sign-in, and passwords stored by 3.x with BCrypt keep working.
A user whose credentials expired in 3.x must change the password before doing anything else.
A user is locked after too many failed attempts, as in 3.x, and the attempt that locks the user also closes all of the user's sessions.
Sign-in attempts are rate-limited per client address and per account.
Every failed sign-in gets the same answer, so the response never reveals whether a user exists.

Sessions

Signing in opens a session and returns an opaque token; the server stores only a hash of it, never the token itself.
A session lasts 9 hours, and a user keeps at most 3 sessions; a new sign-in closes the oldest. These are the 3.x values, configurable per deployment and per tenant.
Users can change their password and sign out; after signing out, the token no longer works.

Each tenant (a company or business group) sees only its own data; the tenant comes from the user's session.
The internal tenant number is never published; clients see an opaque public token.
Permissions use the authority codes of BPMS 3.x and its rule: holding a code also grants its parent codes, so a 3.x role keeps the same access.
Users with the view-roles authority can list the roles of their tenant, paged and sorted by name or id.
Users with the edit-roles authority can grant and revoke authority codes on a role, but only codes they hold themselves.
Every refused call and every change of a role's authorities is recorded in the audit log, with the user, the tenant, and the request id.

The process models of a tenant are organized in a tree of folders and models, the same tree BPMS 3.x shows.
The tree can be listed, and its nodes created, renamed, moved to another folder, and deleted, with the 3.x authorities of the process designer.
The tree keeps the 3.x rules: a model is never a parent, a folder never moves into itself, and a node in use or shared is not deleted.
Every change is recorded in the audit log.

The API is described by an OpenAPI document, served by the platform with an interactive Swagger UI.
Every error has the same shape (RFC 9457 problem details) with a stable code that clients can rely on, and every response carries a request id that ties it to the server logs.
Every request and answer in the contract has an example, and Postman and other clients import the API directly from a running installation.

The application connection is read-only: PostgreSQL rejects every write it attempts.
Writes go through separate connections limited to the tables each part of the platform declares, so nothing else in the 3.x database can be changed.
Schema changes are additive, and against a 3.x database they run only as an explicit migration step, so a restart never changes the schema a running 3.x uses.

One container image runs as the HTTP server, as a background worker, or as a one-off migration.
A new installation, with no BPMS 3.x data, creates its first tenant and administrator by itself.
The whole configuration comes from environment variables.
Liveness and readiness probes answer on the main port; the management endpoints stay on an internal port that is never published.
The platform reports itself not ready, and sign-in answers that it is not available yet, while the database lacks the BPMS 3.x user tables.
The image runs as a non-root user and pins its base images.