Confluye
Getting Started

Getting Started

Sign in, join or create a workspace, build a simple workflow, and run it.

This guide walks you from sign-in to your first successful workflow run.

Prerequisites

  • A Confluye account you can sign in with (see Create an account).
  • Access to a workspace (create one from the workspace switcher, or accept an invitation).
  • To use AI agent blocks, connect a model provider with your own key — see BYOK.
  • To call the API, create an API key as Admin or Owner.

Create an account

Passwords must be at least 12 characters.

How you get an account:

PathWhat happens
Email and password (when the deployment enables it — see below)Register at /sign-up with a name, email, and password. You get no session until you verify the address: Confluye emails a verification link, and the link returns you to sign-in to enter normally.
Organization invitationAn organization Owner or Admin invites admin or member through Better Auth. After acceptance, a workspace Owner or Admin can assign that existing organization member a workspace role.
Google (when FLUXUS_AUTH_GOOGLE_CLIENT_ID and FLUXUS_AUTH_GOOGLE_CLIENT_SECRET are set)Sign-up is allowed. Google must confirm a verified email.
GitHub (when GitHub OAuth is configured)Sign-up is allowed, but only when GitHub reports a verified primary email. Identities without one are refused.
Microsoft (when Microsoft OAuth is configured)Sign-up is allowed when the signed ID token identifies a consumer account or confirms the email with verified_primary_email / xms_edov.
Enterprise SSO/SCIMOrganization-level identity. See Enterprise.
Platform bootstrapDeployments can provision a first Owner with FLUXUS_BOOTSTRAP_OWNER_EMAIL / FLUXUS_BOOTSTRAP_OWNER_PASSWORD. That is not a self-serve invite.

After sign-in, the session is organization-first. It contains the active organization and organization memberships but does not silently select or create a workspace. Choose an available workspace explicitly; organization-visible workspaces may appear as read-only access without creating a workspace membership.

Is email and password registration open here?

It is a per-deployment decision and off by default. It is in force only where FLUXUS_ENABLE_PASSWORD_REGISTRATION=true and an authentication email transport is configured — a deployment that cannot send a verification email never opens registration. Both values are read at startup, so changing either needs a restart. Where registration is closed, /sign-up shows a page saying so and links back to sign-in; it is never a 404 and never a form whose submission would fail.

A verification link is good for one hour. If it lapses, ask for a new one from the sign-in screen — the registration itself is still yours for 24 hours from when you signed up, and asking again does not shorten or extend that. You can request up to four verification emails in total for one registration, which is a limit on how much mail an address nobody has proved they own can be made to receive.

After 24 hours an unverified registration is cleared and the address goes back to being unclaimed. Nothing is lost: register it again. In the last hour before that, asking for a new link quietly sends none, because a link sent then would still be clickable after the registration had already been cleared.

You never have to wait that out for an address that is yours. An unverified registration is not a claim on an address — only opening the emailed link proves anything — so registering the address yourself replaces the waiting registration with your own, and signing in with Google, GitHub, or Microsoft, or accepting an organization invitation sent to the address, does the same. In each case you get a fresh account of your own, with your own password or your own provider, and any verification link that was already issued for the registration you replaced stops working. Nobody can attach a provider to a registration they have not verified.

If you submit the registration form twice for the same address, only the newest email works. Use the most recent one, or ask for another from the sign-in screen.

Sign in and recover access

Sign in at /sign-in. After sign-in you land on /confluye; if you belong to more than one workspace, choose one (Choose a workspace / Enter workspace). Deep links that require a session redirect to /sign-in?returnTo=…, and that destination is kept if you create an account instead of signing in: it travels through /sign-up and the verification email, so clicking the link in your mailbox and then signing in lands you on the page you originally asked for rather than the default one.

  • You registered but never verified. Sign-in is refused and the screen says the address needs verification, with a control to send a new link.
  • You forgot your password. Request a link at /forgot-password. The screen's confirmation is identical for every address — registered or not — so it never reveals who has an account. What arrives in your mailbox depends on your account.
  • Your account signs in with Google, GitHub, Microsoft, or enterprise SSO. You have no Confluye password to reset, so recovery does not offer one. The email you receive points you at the provider that owns your sign-in; recover it there and use the matching button on the sign-in page.

Create or join a workspace

Everything you build lives in a workspace. Use the workspace switcher to search, browse, switch (no full reload), or create a workspace.

Creating a workspace from the switcher or POST /api/workspaces requires a signed-in session and an explicit { name, organizationId, visibility } body. visibility must be private or organization, and the creator must already belong to the selected organization. The creator becomes workspace Owner.

Invite teammates to the organization first, then assign existing organization members from Settings → General (Access). Workspace assignment roles are member, admin, and viewer. Details and the session vs API vs tRPC permission split: Organizations and workspaces and Roles and permissions.

Build your first workflow

  1. 1

    Add a trigger

    On the canvas, add a trigger block from the Toolbar — for example a Manual trigger to run on demand, a Schedule trigger for cron, or a Webhook trigger for inbound calls.

  2. 2

    Add an action

    Add an action block. Use the "+" after the trigger, or drag from the Toolbar. An AI Agent block is a good first step; connect it to a model provider.

  3. 3

    Connect and configure

    Wire the trigger's output handle to the action's input handle. Double-click a node to configure it, referencing upstream outputs with expressions.

  4. 4

    Add an output

    End the graph with an Output (or Response) block so the workflow has a reachable result.

The Workflow Copilot can build or edit this graph for you from a plain description.

Run and inspect

Click Run in the Editor panel to execute the workflow, or Dry run to simulate it without side effects. Watch each node's live status on the canvas, open the node inspector to see inputs and outputs, and follow the logs terminal at the bottom. When you are happy with it, deploy the workflow to activate its triggers.

Next steps