Users & Groups
Assigned Groups and Self-Service Plans, memberships, admin actions, and how fast a revocation takes effect.
Users & Groups
Access > Users & Groups is the directory. The Users tab lists every end user; the Groups tab lists every group with a type badge and member count.
Adding a user
Add user on the Users tab creates an end user from an email address before they ever sign in - the same pre-provisioned identity a group page invite creates. Give a name if you know it, tick any Assigned Groups they should start in, and choose whether to send the invite email and which Portal its sign-in link points at. The email names the group when there is one and otherwise simply invites them to your workspace. Their first sign-in with that address lands on this identity with everything already assigned.
Two kinds of group
| Assigned Group | Self-Service Plan | |
|---|---|---|
| Who is in it | Whoever you add | Whoever subscribes to (or joins) the plan |
| Where it is managed | Groups tab (create, rename, add and remove members) | Self-Service Plans (price, credits, trial); the group is read-only here |
| Credits for a run | Your organization's credits | The plan's own allowance, per subscriber |
| Typical use | Employees, consultants, a beta cohort, one customer you invoice yourself | Customers who buy, and free "libraries" anyone can join |
Both kinds do the same job: they are assigned to assets on the asset's Assignments tab. A user who is in a plan and an Assigned Group sees the union of everything both reach.
The Create button on the Groups tab makes an Assigned Group. Self-Service Plans appear in the same list with a Plan badge and link to the plan; their membership is written by billing, so it cannot be edited here.
A group of one
To give a single person access to something, put them in a group - a group of one is fine. Assignment is always by group, so every access decision shows up in the same list, and taking it away later is one removal.
A group record
- Members - editable for an Assigned Group; for a Self-Service Plan, the live subscribers with their subscription status.
- Assigned to - derived, read-only: every asset this group can reach, linking to each asset's Assignments tab.
- Portals - which doors admit the group.
Signing in grants nothing
A Portal never adds people to a group on its own. Someone reaches an asset only because an admin put them in a group assigned to it, or because they picked a plan on an attached Storefront. To give "everyone who signs in here" a starter kit, put the kit on a $0 default plan of the Portal's Storefront.
Admin actions
On any end user:
- Comp a plan - put the user in a plan's group without a Stripe subscription: full plan access and credit allowance. Blocked while the user has a live paid subscription on that plan (cancel it in Stripe first).
- Adjust credits - grant (or claw back) bonus credits on one of their subscriptions without touching the plan.
- Revoke / restore access - see the timing below. Their data is kept.
- Delete - for erasure requests: revokes immediately, cancels any Stripe subscription, and removes the identity from your directory.
Every admin action is recorded in the audit trail under Monitor > Activity > Admin activity, visible to your organization's owners and admins.
How fast does a revocation take effect?
Revoking a user blocks sign-in and session refresh immediately. A session that is already open keeps working until its current token expires, and tokens live for at most 4 hours. So the revocation SLA is:
- New sign-ins: blocked at once.
- Open sessions: closed within 4 hours at most, and at the next page load in practice (the experience refreshes its token on load, which is refused for a revoked user).
- Restoring the user re-opens both.
The same 4-hour bound applies to removing someone from a group: the assets disappear from their experience within the hour they next refresh, and always within 4 hours. Deleting a user takes effect the same way as revoking.
Migration note for existing sellers
If you were selling plans before the Access section arrived, nothing changes about a subscriber's billing: one subscription and one credit pool per plan, regardless of how many Storefronts offer it or how many Portals admit it. One visible change: a subscription now counts at every Portal that admits the plan's group, not only the Portal where it was bought. If you kept a plan private to one Portal, set that Portal's admission list explicitly.
If you are on the previous layout
Workspaces that have not been switched over still see Monitor > Users (directory plus a Groups tab) and, on each user, individual allow/deny exceptions. There, access is the sum of a Portal's default products, the user's plans, group grants, and per-user exceptions - with a deny always winning. That layered model is retired by the Access section: every rule becomes a group assignment on the asset, and there is no deny.