People who sign in

These are your users — your colleagues or your customers. They are not platform accounts, they cannot reach the workbench, and signing in to your application is not signing in to Desifex.

One directory, every application#

They belong to the workspace, not to one application. Somebody who uses the booking system and the staff portal is one person with one password, not two accounts who both forget it.

So the list lives at Users in the main navigation, above every application — everybody who can sign in to anything you have had built, with a tick against each application they may open.

Each application also shows its own slice, under Settings › Access, once access is set to People sign in. Same people, one application's worth at a time.

Adding somebody#

Add someone on the Users page, by email address. A password is generated and shown once; tick the applications they should be able to open.

Adding somebody from an application's own settings instead does the same thing and grants that application — and emails them the password, if the application has email connected. The directory has no email of its own to send from, which is why that route is worth taking when there is one.

Somebody who already has an account in your workspace is granted the application rather than given a second account, and keeps the password they already had. Granting them one more application is no reason to lock them out of another.

Changing who may open what#

Open somebody on the Users page and tick or untick applications. It takes effect at once: a person you untick cannot sign in to that application from their next attempt.

While one login for every application is on there is nothing to tick — see below.

Resetting a password#

Reset their password generates a new one and shows it once. From an application's settings you can also set one directly, or have it emailed.

Either way the person is signed out everywhere, which is usually the reason somebody is on that screen.

Suspending and removing#

Suspend them keeps the account and stops it working, everywhere, at once. Let them back in undoes it.

Remove from workspace deletes the account itself, along with every application it could open. Owner-only. What the applications already stored about them stays — an order does not stop having been placed.

Taking somebody off one application without touching the rest is done from that application's Settings › Access, or by unticking it on the Users page.

One login across applications, or one per application#

A workspace setting, at the top of the Users page and repeated in each application's Settings › Access. One login for every application means an account works across every application in the workspace; a login per application means access is granted per application.

Turning it on grants nothing retroactively and asks nobody to re-register. It changes the question from is this person a member of this application to is this person in this workspace, so accounts that already exist simply start working.

A session still belongs to the application it was made for, even under one login. One application's cookie is not another's.

Custom data per person#

A small map of text you keep about each person and the application can read — a customer number, a plan, a branch, a region.

It arrives with every session lookup, so the application can use facts it never collected without keeping a second copy of your users.

Bounded on purpose: forty fields, five hundred characters each. This is a place for a customer number, not a document store.

Saving replaces the whole map rather than merging it — the screen shows every field at once, so a row you deleted actually goes.

Two-step sign-in#

Each person's own choice, made from inside your application rather than by you.

• Email codes and authenticator apps work today.
• SMS and passkeys are listed as coming rather than hidden.

An authenticator is not enrolled until a code from it is confirmed, so nobody locks themselves out of an application they never finished setting up. Codes are stored hashed, work once, and are limited to a handful of attempts.

What the application does not hold#

Your application stores no password hash and writes no session logic. It renders its own sign-in screens, in its own design system, and asks the platform.

That is why authentication here is worth trusting: it is one implementation, kept working in one place, rather than a new one written per application.