Users, application access, and API keys

Pipelogiq separates human dashboard sessions from application API keys. A person's role controls which dashboard operations they can perform; application memberships control which workflow data they can access. An application key authorizes SDK and worker calls for its owning application.

Create a dashboard account

As an administrator, open Settings → Users, choose the create action, and enter the person's profile, email, initial password, role, active status, and assigned applications. Save and deliver the initial password through your organization's chosen secure channel.

Pipelogiq does not send invitation or password-reset emails. Passwords must have at least 12 Unicode characters and fit bcrypt's 72-byte UTF-8 limit. Each person can change their own password under Account, using the current password.

These are built-in roles. Custom roles and arbitrary permission sets are not provided. Use Viewer for investigations, Operator for people authorized to change workflow outcomes, and Admin for access/configuration owners.

Application membership

An account with no applications can sign in but has no pipeline or schedule data. Admin status does not bypass workflow-data membership. Administrators can assign existing applications in the user editor; that picker contains application names and IDs, not API key secrets.

An out-of-scope workflow commonly returns 404 instead of confirming that another application's record exists. When a colleague cannot open a shared run link, check their active account and application membership first.

Application keys, pipeline IDs, and queue prefixes are different identifiers. The queue prefix is derived from the numeric application ID and returned by worker bootstrap. Use the bootstrap response rather than guessing it from the application display name.

Change or revoke access

Edit the user to change membership/role or deactivate the account. Deactivation retains its history; permanent account deletion is not the normal management operation. Account changes and administrator password resets revoke the target user's sessions. The user must sign in again.

Administrators cannot deactivate themselves or change their own role through normal user management. The server also protects the last active administrator. Keep a recoverable administrator account and coordinate ADMIN_EMAIL bootstrap configuration with account management.

Logout revokes the account's sessions. Changing your own password retains the current HTTP session while revoking others. Do not share an account when people need independent access and audit attribution.

Create and rotate an application API key

1. Open Settings → API keys as an administrator with access to the application.
2. Create a key for an existing application, or use the new-application option.
3. Name the key so its purpose is recognizable and set expiry when appropriate.
4. Copy the full key from the creation result into your secret manager. Later listings show metadata and a prefix, not the original key.
5. Configure the application/worker with the key and verify it can bootstrap or create the intended run.

To rotate, create another key, deploy consumers with it, confirm new requests work, and disable the previous key. Disabling is effective for subsequent API-key validation. Do not disable first if it would interrupt workers before their replacement credentials are deployed.

Keys are application-scoped credentials, not dashboard users with Viewer/Operator roles. Do not distribute a worker key to business viewers. Do not embed keys in browser code, URLs, screenshots, or pipeline keywords.

The bootstrap application key is first-start provisioning. Changing BOOTSTRAP_API_KEY after that application already exists does not rotate its key. Use the dashboard key lifecycle instead.

First administrator and recovery

For a fresh database, configure ADMIN_EMAIL. Leaving ADMIN_PASSWORD_HASH empty generates a password once and prints it in the local API startup log. It is not regenerated for an existing account.

A deployment owner can provide a valid bcrypt ADMIN_PASSWORD_HASH to replace that configured administrator's credentials during controlled recovery. Treat it as a persistent bootstrap override: leaving it configured can reapply the configured password on future starts. Remove the override after recovery if subsequent password changes should be managed through the UI. Never use the historical demo password hashes.

Human activity audit

Administrators open Settings → Audit and filter by action, acting user, and outcome. Expand entries for selected operation details, including individual bulk results. Outcomes distinguish successful, failed, denied, rate-limited, and partial operations.

The activity log records authenticated dashboard mutations and public authentication outcomes. Ordinary reads and refreshes do not create entries. A failed login's submitted email is an attempted identity, not proof that the account owner acted.

Worker/SDK API-key operations and automatic scheduler execution have their own pipeline, schedule, and worker history. They are not attributed to a human dashboard user. Audit storage is best effort: an audit-write failure is logged without undoing the business operation. It is not a transactional compliance ledger.

Community and commercial features

Local accounts, built-in roles, application scoping, API keys, and the ordinary activity audit are available in Community. Licence status appears in Settings, but catalogue entries can describe future or partially integrated capabilities. This guide relies on the local-account path. Do not assume OIDC login, Slack approval flows, or a complete compliance export is available simply because a feature name is listed.