Skip to main content
A runtime app can be configured for unauthenticated end users. Anonymous users start processes and UI flows from a public link, with no login required.

Overview

Anonymous runtime access lets an app serve users who have no FlowX identity. A typical use case is a public form, a quote calculator, or an appointment booking page reachable from a marketing site. Two independent gates must both be open for a request to be served anonymously:
1

The app must be shared publicly

In the Share modal, General access is set to Everyone with the link. Apps default to Only invited users and groups.
2

The resource must allow the Anonymous role

The specific process or UI flow being started must have the Anonymous role assigned in its Permissions tab.
If either gate is closed, the runtime returns 403 Forbidden with a detail of Anonymous access not enabled for this application (the app is not publicly shared) or Anonymous access not enabled for this build (the resource does not carry the Anonymous role). Mixed-access is supported — the same app can serve authenticated users with their assigned roles and anonymous users with the Anonymous role.
Public-access toggle in the Share modal

The Anonymous role

Anonymous is a built-in, system-level role. It represents any user who arrives without a valid authentication token.
SELF_ASSIGN is required because starting a process needs both EXECUTE and SELF_ASSIGN. The role auto-populates the three operations and locks SELF_ASSIGN so the role always behaves consistently across processes.

Make an app publicly accessible

1

Add the Anonymous role to the project

Open the project’s Version settings → End User Roles, then add Anonymous to the available roles.Until the role is on the version, the Share modal’s general-access dropdown stays disabled.
2

Open the Share modal

From the project header, click Share.
3

Set General access to Everyone with the link

Under Who has access → General access, switch from Only invited users and groups to Everyone with the link.
Switching back to Only invited users and groups at any point closes the public gate immediately. Existing anonymous sessions in flight will start returning 403 Anonymous access not enabled for this application on their next request.
4

Save and copy the share link

Save the Share modal. The runtime app is now reachable to anyone with the URL — subject to the per-resource role check below.

Configure anonymous on a resource

The Anonymous role must be explicitly assigned to each process, UI flow, or reusable UI template you want runnable without authentication.
Open the process and go to Permissions.
  1. Add Anonymous to the role list (only available when the role is on the version).
  2. The role’s row shows VIEW, SELF_ASSIGN, and EXECUTE pre-populated. Toggle VIEW or EXECUTE as needed. All other operations are greyed out.
  3. Adding Anonymous is additive — it does not affect other roles on the process.
Anonymous can also be added to a swimlane. The component hide/disable rules below depend on this assignment.

Component visibility for anonymous users

UI Designer hide/disable rules support the Anonymous role in the Role condition type. The role must already be assigned at the right scope: Common patterns:
  • Hide for anonymous — show a “Sign in to continue” CTA only when the user is anonymous; hide an action button (e.g. “Save to account”) for anonymous users.
  • Disable for anonymous — keep a field visible but read-only; the same field becomes editable for authenticated users.

Runtime behaviour scenarios


The anonymous session

Anonymous traffic is isolated using a session ID — there is no user identity to bind state to.
  • Header: X-Fx-Anonymous-Session-Id
  • Issued by: the backend, on the first anonymous request that doesn’t already carry one. The new session ID comes back in the response header X-Fx-Anonymous-Session-Id (exposed via Access-Control-Expose-Headers; the exposed-header list is controlled by the APPLICATION_CORS_EXPOSEDHEADERS env var, which carries this header by default).
  • Maintained by: the SDK / container app. After receiving the session ID, the client must include it on every subsequent anonymous request.
  • Scope: one anonymous session can only access the process and UI flow instances it created. Another session that knows the processInstanceUuid cannot read or act on it.
  • Lifetime: fire-and-forget. Closing the browser ends the session. There is no resume mechanism in 5.9.0.
Tokens take precedence over anonymous mode. If the client sends an Authorization: Bearer … header, the backend treats the request as authenticated and ignores the anonymous session ID. There is no fallback to anonymous when a bearer token is invalid or expired — the request returns 401.A common bug: a user logs in on /private, then opens /public in the same browser. The persisted bearer is attached to public-route requests and the backend returns the authenticated user’s data. Container apps must scrub the Authorization header on public routes — see SDK behaviour below.

Public build, public assets

Once a runtime build is published with the Anonymous role and the app is shared publicly, the build is considered public. All assets inside it are reachable anonymously — except UI flows and processes that have not been explicitly opened to the Anonymous role. Public assets in a public build:
  • Enumerations/rtm/api/runtime/app/{appId}/build/{buildId}/rt/enumeration/...
  • Substitution tags/rtm/api/runtime/app/{appId}/build/{buildId}/rt/substitutiontag
  • Media files/rtm/api/runtime/app/{appId}/build/{buildId}/rt/mediafile
  • Themes/cms/api/wks/{workspaceId}/themes/uuid/{themeId}/platform/{platform}/compiled (globally unauthenticated)
  • Fonts/cms/api/fonts (globally unauthenticated)
Restricted assets (require authentication and a role grant):
  • UI flows not configured with Anonymous
  • Processes not configured with Anonymous
  • Chat, task manager, and view-scoped endpoints — see Restricted endpoints below

SDK and container app behaviour

Renderer initialization

Process and UI flow renderer components decide their mode at initialization from the authToken parameter:
  • authToken present (non-null) → renderer runs in authenticated mode. All outgoing requests carry the bearer token. If the token expires mid-flow the renderer surfaces 401 errors (existing behaviour).
  • authToken absent (null/undefined) → renderer runs in anonymous mode. The renderer omits the Authorization header and uses X-Fx-Anonymous-Session-Id instead.
The mode is locked at init. Switching authToken from null to a value after the renderer has started will not flip it into authenticated mode, and vice versa. If you need both modes in the same container app, mount separate renderer instances on separate routes (e.g. /public and /private).

Container apps

A container app that hosts both public and authenticated routes must guarantee that public routes do not pass an Authorization header to the renderer. The renderer uses an isolated HTTP client at runtime, so whatever the container does for its own pages does not automatically leak in — but if the container reads a token from localStorage and supplies it to the renderer, the token-precedence rule above applies and anonymous mode is silently bypassed. The recommended pattern:
  • Public route (e.g. /public/...) → mount renderer with authToken={null}
  • Private route (e.g. /private/...) → mount renderer with authToken={accessToken}
  • Clear any stored bearer when the user navigates from /private to /public.

Platform support


What anonymous users can call

Anonymous traffic is allowed on a curated set of runtime endpoints. The full reference is the SDK endpoint table — the summary below is grouped by capability. Endpoints flagged session ID required must include X-Fx-Anonymous-Session-Id; the backend rejects requests where the session ID does not match the entity it refers to (403 Anonymous session not found for entity).

Allowed

Restricted endpoints

The following are never served anonymously, regardless of the public gates:
  • Task manager — every /rtm/api/runtime/app/.../view/... and /task/api/tasks/... endpoint
  • Chat/rtm/api/runtime/wks/.../conversations, chat-workflow start, chat-session upload (postponed past 5.9.0)
  • View-based SSE/api/events/view/{viewId}
  • Generic SSE other typesCHAT_WORKFLOW_RESPONSE, CHAT_FILE_UPLOAD
  • Internal runtime endpoints — anything under /rtm/api/runtime-internal/wks/.../app-version/... (including process-resource-id/.../start/test and start/email-trigger)
  • Languages/cms/api/languages is not exposed for anonymous in 5.9.0

Error responses


CORS requirements

Two headers must be in the gateway’s Access-Control-Allow-Headers allow-list and Access-Control-Expose-Headers response list:
Fx-BuildId is required on SSE connections so the backend can route the stream to the correct build when no user identity is present. The default FlowX commons-security-lib CORS configuration includes both headers from 5.9.0. If you override CORS in your deployment, make sure these are preserved.

Limitations (5.9.0)

  • Fire-and-forget sessions — closing the browser ends the session. No resumption.
  • No task assignment to anonymous users. Anonymous can start and act on a process they own via the session ID; they cannot be assigned an existing task.
  • Mode is locked at renderer init — see Renderer initialization.
  • No anonymous chat in 5.9.0.
  • No anonymous languages endpoint (/cms/api/languages).
  • Subprocessesdata-model-paths calls for subprocesses are gated by the same session-ID check as the root process instance.
  • Anonymous role cannot be removed or renamed. It can only be added to or removed from a project’s End User Roles.

Swimlanes

Configuring swimlane roles, including Anonymous, for process steps.

Business filters

Other role-driven runtime filtering.

Roles & permissions matrix

Full list of system and end-user roles, with allowed operations.

Web SDK renderer

authToken initialization rules and container-app patterns.
Last modified on June 10, 2026