Custom Workflow lets you build your own login screen and authentication logic, and Anonymous User Session issues guest sessions for people who never sign in at all.

Overview

Both are advanced identity provider types for situations the built-in methods can't cover. Custom Workflow hands authentication to an automation you write, paired with a no-code login screen you design — the supported way to put fields like a phone number on the sign-in page. Anonymous User Session issues sessions with no authentication at all, for public pages, embedded chatbots, or kiosks. For embedding UnifyApps behind your own backend-verified session instead, see External Session Configuration. Add either from Settings › Security › New Identity Provider.

Use Cases

• Phone-number sign-in: Collect a phone number (and an OTP field) on a custom login screen — the built-in methods always show a fixed Username field.

• Authenticating against an external system: Verify credentials against a legacy database, a magic-link token, or any system reachable from an automation.

• Public or embedded surfaces: Let anonymous visitors use a public app, embedded chatbot, or kiosk without any sign-in step.

• Guest-to-registered upgrade flows: Issue a short temporary guest session that's meant to be upgraded to a real account quickly.

Custom Workflow

How It Works

You supply an Automation that performs authentication, and you build a no-code login screen that collects whatever fields you want. The form configures:

• Button Label: the login-page button text (default "Continue with Custom Workflow login").

• Automation*: the authentication automation.

• Request Timeout: how long the platform waits for your automation, in seconds.

• Additional Settings: JIT Provisioning + JIT Provisioning User Criteria, Login Restriction + Login User Criteria Match, and the usual session controls.

Your automation receives the login submission — the form data your screen posted, plus request headers and query params. It must return authenticated (true/false), and when true, a userDetails object containing at least a username (plus optional email, name, custom attributes). It can also return returnTo (a post-login redirect), errorMessage (shown to the user on failure), and resetPassword (send them to set a password).

Note:

If your automation returns

authenticated: true

but no username, the login still fails — a username is required to resolve or create the account.

Building a Phone-Number Login

1. Create a Custom Workflow identity provider and point its Automation at an authentication workflow you build.

2. Build a custom login page (a no-code interface) that shows a Phone number field (and, say, an OTP field) and submits them.

3. In the automation, read the submitted phone number from the form data, verify it — look the user up, check a code, call an external service — and return an authenticated result whose userDetails uses the phone number (or a stable id) as the username.

4. Turn on JIT Provisioning if you want first-time phone numbers to create accounts automatically; use Login Restriction to gate who's allowed.

This is the supported way to collect a phone number on the sign-in screen — the built-in methods always show the fixed Username field.

Anonymous User Session

Anonymous User Session issues guest sessions for unauthenticated visitors. It's configured like External Session but adds a No Auth token type — a guest session with no token at all — so use it only for genuinely public surfaces. You can issue either a persistent guest session (default lifetime ~7 days) or a temporary session (default ~2 minutes) meant to be upgraded quickly. Guest sessions can be keyed to a stable id, such as a device id, so the same visitor is recognized across requests, and the cookie is set for cross-origin embedding. Scope it with Allowed request origins and login/JIT criteria where appropriate.

Notes

Both types shift trust away from a standard login form, so the surrounding guardrails matter more than usual:

• Treat a missing authenticated value from your Custom Workflow automation as a failure — the platform fails closed, but write your automation to be explicit about it anyway.

• Keep the authentication automation itself robust — it alone decides whether a login succeeds.

• Turn on JIT Provisioning on the Custom Workflow method only if first-time identities, like new phone numbers, should create accounts automatically.

• Reserve Anonymous / No Auth sessions for surfaces that are genuinely public — anyone can obtain a guest session.

• Restrict Anonymous sessions with Allowed request origins and keep temporary-session lifetimes short.