General settings — workspace name, policy toggles, and plan my-workspace on Pro plan
Identity, session policy, and billing in one place.

Workspace Management

General

The General tab in Workspace Manager is where you set workspace identity, billing plan, and the acceptAnonymous access policy.

Workspace Manager General tab showing workspace name, billing plan selection, and Accept anonymous users toggle
General tab — workspace name, billing plan, and Accept anonymous users.

What is a Workspace?

A workspace is your own private universe inside secureFlows.

Think of it as a locked room for your app and its users. Everything that happens inside — every user, every saved session, every piece of stored data — stays inside that room. Nothing leaks out, and nothing from anyone else's app leaks in.

When you build something with AI tools or no-code automations, you're often moving fast and connecting a lot of moving parts. A workspace is what keeps that speed safe: it's the boundary that guarantees your users' data can never mix with another developer's users, even if you're both running on the same secureFlows infrastructure.

One workspace, many users — each sealed off.

But isolation doesn't stop at the workspace boundary — it goes all the way down to the individual user. Inside a single workspace, every user's data is also sealed off from every other user in that same workspace. Two people using the same app, in the same workspace, still can never see each other's data. One workspace can safely hold thousands of users, each with their own fully private space, and none of them can reach into anyone else's.

In plain terms:

  • One workspace = one isolated home for one app (or one product).
  • Every session, every user, every saved preference lives inside a workspace — and stays there.
  • Inside that workspace, each user is also isolated from every other user — your data and mine never touch, even though we're both "in" the same app.
  • You set the rules for your workspace (like how long data should be kept, or whether open self-signup is allowed).
  • You (the owner) and your team (admins) are the only ones who can manage what happens inside it — and even then, access to user data is role-controlled and logged, not a free-for-all.
User A and User B never share data.

You create a workspace once, at the very start — it's a one-time setup step, not something your app code needs to think about every time it runs. After that, your app just quietly uses it in the background, every time a user logs in or saves something.

Why it matters: without workspaces, isolation would depend on developers writing careful code every time — both between apps, and between users within the same app. With workspaces, isolation is just how the system works at every level, and it's not something you can accidentally misconfigure.

What does "Accept Anonymous" mean?

Most apps want everyone to be able to sign up and start using them. You build something, you want people to find it, sign in, and go — without anyone having to manually approve each person first.

That open, anyone-can-join behavior is what acceptAnonymous controls — and it's on by default, because it's what most apps need.

If instead you want to keep your app private — usable only by a specific, pre-approved set of people — you turn acceptAnonymous off. That switches your workspace to invite-only: from that point on, only people an admin has explicitly invited can authenticate and use the app.

Default open · opt-in to closed.

A quick note on the name: "anonymous" here doesn't mean users skip logging in. Everyone still authenticates, always. It just means they weren't a known, pre-invited identity beforehand — they showed up on their own and were still let in.

In plain terms:

  • On (default): anyone can authenticate and get their own private, isolated data space — open self-signup, no invite required.
  • Off (opt-in): only pre-invited users can authenticate and use the app — choose this when you need a closed, private app.

Why you'd leave it on: the common case — public-facing apps, consumer products, anything where you want people to be able to just show up and start using it.

Why you'd turn it off: internal tools, B2B products, or anything where access needs to be tightly controlled by an admin from day one. Send invites from the Invites tab.

It's a single switch, set per workspace, and your app code doesn't need to handle the distinction — secureFlows enforces it automatically based on the workspace setting.

Set once in General — your app code stays simple.