Users & Groups
Assigned Groups and Self-Service Plans, memberships, admin actions, and how fast a revocation takes effect.
Users & Groups
The Assign section of the sidebar is the directory. Users lists every end user; Groups lists every group with its member (or subscriber) count and how many assignments it has, and a Self-Service badge on plans.
Adding a user
Add user on the Users page 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 page (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 New group button on the Groups page makes an Assigned Group. Self-Service Plans appear in the same list with a Self-Service badge and their price; 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 Subscribers with their subscription status.
- Assigned to - derived, read-only: every asset this group can reach, linking to each asset's Assignments tab.
- Description, plus when the group was created and last updated.
Which Portals admit a group is set on each Portal's Access page.
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 (shown as Comp a tier) - put the user in a plan's group without a Stripe subscription: full plan access and credit allowance, excluded from revenue. 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 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.
Removing someone from a group, or removing an assignment, is faster: access is checked on every request, so the assets disappear on their next request. 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 Users on its own in the sidebar (plus Assign > Access and Assign > Groups where groups are enabled) 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.