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.
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.

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.
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.- Process
- UI Flow
- Reusable UI template
Open the process and go to Permissions.
- Add Anonymous to the role list (only available when the role is on the version).
- The role’s row shows
VIEW,SELF_ASSIGN, andEXECUTEpre-populated. ToggleVIEWorEXECUTEas needed. All other operations are greyed out. - Adding Anonymous is additive — it does not affect other roles on the process.
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 viaAccess-Control-Expose-Headers; the exposed-header list is controlled by theAPPLICATION_CORS_EXPOSEDHEADERSenv 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
processInstanceUuidcannot read or act on it. - Lifetime: fire-and-forget. Closing the browser ends the session. There is no resume mechanism in 5.9.0.
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)
- 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 theauthToken parameter:
authTokenpresent (non-null) → renderer runs in authenticated mode. All outgoing requests carry the bearer token. If the token expires mid-flow the renderer surfaces401errors (existing behaviour).authTokenabsent (null/undefined) → renderer runs in anonymous mode. The renderer omits theAuthorizationheader and usesX-Fx-Anonymous-Session-Idinstead.
Container apps
A container app that hosts both public and authenticated routes must guarantee that public routes do not pass anAuthorization 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 withauthToken={null} - Private route (e.g.
/private/...) → mount renderer withauthToken={accessToken} - Clear any stored bearer when the user navigates from
/privateto/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 includeX-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 types —
CHAT_WORKFLOW_RESPONSE,CHAT_FILE_UPLOAD - Internal runtime endpoints — anything under
/rtm/api/runtime-internal/wks/.../app-version/...(includingprocess-resource-id/.../start/testandstart/email-trigger) - Languages —
/cms/api/languagesis not exposed for anonymous in 5.9.0
Error responses
CORS requirements
Two headers must be in the gateway’sAccess-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). - Subprocesses —
data-model-pathscalls 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.
Related resources
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.
