Users & Spaces
A space is a separate work area with its own data and settings; a user is a login inside one. These two screens are how people get in and how a space is bounded.
Where to find it
| Screen | Where it lives | What it is for |
|---|---|---|
Users — /admin/users | Settings → Workspace & access → Users | the people in this space, and their invitations |
Spaces — /admin/spaces | Settings → Workspace & access → Spaces | the spaces you can reach, their ceilings, plans and domains |
Each page has a view permission of its own, and each action on it has its own narrower one. Opening a page you can only read says so: View only — to change users here you need the "Create users", "Enable or disable users", "Assign role groups" or "Reset passwords" permission in this space. The level-2 actions ask for your password first.
Users
Every user is backed by a contact
That is the model, and it explains the first choice when adding somebody: link an existing contact, or create one inline. Either way the contact gets the user role and a login. There is no such thing here as a login with nobody behind it.
The list shows the Contact, the Username (email), the user's Role groups, their Last login, and whether they are Enabled.
Inviting somebody by email
Invite by email… is the preferred way in, because no password is ever shared: the person receives a one-time link and sets their own.
| Field | What it does |
|---|---|
| an address already known as a login means that existing person joins with their own login; a new address creates an account here | |
| Rights on acceptance | the permission groups applied the moment they accept |
| Link valid until | when the link stops working |
| Username suffix for an existing user (optional) | for a person who already has a login: an ending for the username they get in this space |
| Message | optional, shown to them |
| E-mail locked | only this address may accept — a logged-in person cannot attach the invitation to a different account they already have |
Invitations are listed with their Status — Pending, Accepted, Expired or Revoked — and the controls on a row follow that status: Edit on a pending invitation, and Resend (which invalidates the previous link) and Revoke (the link stops working immediately) on a pending or an expired one. An accepted or revoked invitation carries no controls. There is no copy-link button on the row: the link is offered in the dialog that follows sending or resending, and only when e-mail delivery is not configured.
Role groups, and the ceiling you can feel from here
Assigning groups to a user shows two honest numbers: how many of the group's permissions apply here, and which of them are outside this space's ceiling. Groups outside the ceiling can still be assigned — the assignment is kept — but they resolve to nothing in this space, and the page says so rather than letting you believe you granted something.
Hover over the chip to see which permissions are outside. The note tells you where to fix it: this space's ceiling admits only … — a parent-space admin widens it under Admin → Spaces → this space → Ceiling.
For a person linked in from a parent space, the dialog also shows what they bring with them: the groups From their home space (carried over, above this ceiling), and what is Granted here. Their home rights apply in this space even above its ceiling — see Who Can See What.
Data groups: which contacts a login sees
Data groups on a user's row sets the two lists every contact fence reads — the contacts list, saved views, widgets, files, messages and the possible-duplicates review all answer with them. Sees only these groups: tick groups here and the login sees only contacts that are in at least one of them; leave it empty and nothing is held back on that account. Never sees these groups: tick groups here and the login never sees a contact that is in any of them, even one that is also in a group above; a contact in no group at all is not hidden by this list. A group ticked in one list leaves the other.
The action rides its own permission, Set which data groups a user sees (the Users manager bundle carries it), and the rules behind it are the ones that keep authority from leaking sideways or up: you can set the lists only for a login of this space, only with groups of this space, only with groups you can see yourself — the dialog offers only those, and a login's entries for groups outside your view are kept exactly as they are and counted in one line — never for yourself or for a login linked to you, and never so that the login ends up seeing more than you do: an empty Sees only list is refused when it would admit groups, or the contacts in no group, that neither you nor that login could see before. A list that is not a list of groups (a value the database was handed by something other than this screen) hides everything from that login; the dialog says so, and saving replaces it. Every save is audited with the lists before and after, by group name.
Resetting a password
Reset password emails a reset link, and the confirmation says the part people worry about: their current password keeps working until they redeem it. If the user's contact has no primary email address, the page says to add one first.
Impersonation
Impersonate lets an administrator act as another user of this space. The confirmation says what makes it acceptable: every action is audited with your identity attached, and a banner is shown throughout so you can stop.
For a user of a space you are not a member of, the Spaces screen offers Request access instead (open the space with Manage…, then its Users tab). You give a reason, and may propose a duration and a scope; the person must approve your request, and they pick the final duration and scope. Requests are tracked under Account → Access grants.
Spaces
The list is your reachable subtree: the space you are in and the spaces below it. Each row shows the space's Name, Description, Ceiling and whether it is Enabled; the space you are in is marked Current space, and a sandbox carries a Sandbox badge.
Manage… opens a space's details in tabs — Users, Seats, Billing, Usage, Ceiling, Domains, Integrations and Plan catalog — each shown only to someone who holds its permission. Enter space takes you into it; if you are not a member yet, the drawer says so: entering links you in first (an explicit, audited membership row).
Creating a space
A new space is created under the space you are in, with a permissive ceiling so nothing starts hidden. You pick an origin contact and a plan, and three things happen at once: the contact is shared into the new space as a live-synced copy, billing is provisioned on the plan, and that contact becomes the first user (a space admin) with an invitation.
If the origin contact already has a login of its own, that person is not given a second one: they are invited as the new space's admin (one person, one login), and they accept the invitation signed in with the login they already have — no new password. A disabled or deleted login is refused; you can supply a different username for the first user instead.
Optionally the space can start from a template set — a main template plus sub-templates. Preview the set and resolve every conflict before creating the space. See Templates.
The ceiling — the one concept to understand
The ceiling is the parent’s control over what this space can grant: everything a person holds here is cut to what the ceiling groups grant, super admins included. A person linked in from a space above is the exception: the rights from their home space ride above this ceiling, unless they tick “Bind to this space's ceiling” in the top bar or this space forces that view on linked visitors. A deny in this space still removes a right from everyone.
So a ceiling is not a default and not a suggestion. It is the outer boundary for everyone who belongs to the space. The one exception is a person linked in from a parent space: their home rights still apply here, unless they choose to bind themselves to the ceiling or the space forces it — see Who Can See What.
In the list, the Ceiling column reads Full menu when the ceiling admits every permission the space above it admits, Narrowed when it admits fewer, and MISSING — deny-all when it has none; hover a badge to read what it means. The groups themselves are on the space's Ceiling tab (Manage…), which also counts the result — Permissions this ceiling admits: and a number, each permission with the groups it comes via — and lists, under Not available in this space yet, the groups this ceiling does not fully cover, each with the permissions it is missing and — for an admin who may widen the ceiling — Add to this space’s ceiling. Seeing the counted list needs its own permission, View a space’s permission ceiling as a permission set.
To narrow a space: attach a hand-built group granting only the keys you want to admit, then remove the permissive default. Two refusals protect you from locking a space out of existence:
- a set that would leave the ceiling empty (deny-all) is refused;
- dropping the last group that admits user administration is refused, so a space always stays self-administrable.
A child you narrowed can always be re-widened.
If a group is assigned to members but sits outside the ceiling, the page says so: members keep the assignment, and its grants stop working here until the ceiling is widened — but any deny it carries still applies. To clear a deny, remove the membership, not the ceiling row.
Linking a person into a space
Link user… adds an existing person as a member of this space. You pick the Person from the people of the spaces you administer, the Permission groups they get here (from this space's ceiling), and optionally a Username suffix (it defaults to the space name). The note explains what kind of thing that is: a linked local user for an existing person — access is an auditable row, never ambient. No credentials are created; they sign in as themselves and reach the space from the space switcher. A person linked in from a space above this one also keeps their home rights here — see Who Can See What.
New user… does the other thing: creates a user that belongs to this space only, with its own contact and its own login, unconnected to any parent-space identity. They set their password through an emailed one-time link.
Orphan spaces
Spaces with no users or no owner are listed separately. Assign origin… does the same one-time provisioning a new space gets: shares the contact in as a live-synced copy, provisions billing on the chosen plan, and mints the first user. A space that already has users is left alone — its disposition is an operator's decision, and the row says so.
Custom domains
A space can be reached at your own address. Add a domain, mark it Verified, and set one as Primary. Routing is provisioned immediately; the certificate is ordered automatically on the next renewal pass, and the row shows whether it is issued, pending or expiring.
Sandboxes
A space can be cloned as a Sandbox for safe experimentation. Delete sandbox removes every row copied into it and deletes the space. The confirmation is blunt about the consequence: workflows authored in it are not promoted, and this cannot be undone — clone the live space again for a fresh sandbox.
Billing and the reseller chain
Each space's drawer carries its billing account, its subscriptions, its plan catalogue and (where granted) its reseller rights. Those are explained in Billing & Plans.