User and Team Management

Users, teams, and their relationships live as nodes in the workspace's graph — so every operation is auditable, scriptable, and integrates cleanly with the rest of the platform.

This page is the reference for lifecycle: how users come in, how they get the right access, how access changes as roles change, and how they leave cleanly.

For the underlying authorization model see Access control model. For SSO setup see SSO providers.

Permission model in one paragraph

Curiosity uses Relationship-Based Access Control (ReBAC). A user's access is computed at query time from edges in the graph: which teams a user belongs to, which data nodes those teams are linked to, which user-specific restrictions apply. There is no static role-permission matrix to keep in sync with content — the graph is the matrix.

User and team types

Admin status, SSO group membership, and last-login info are properties on the _User node — inspectable like any other graph data.

Lifecycle

1. Invite or provision

There are three onboarding shapes:

var user = await graph.CreateUserAsync(
    userName:  "alice",
    email:     "alice@example.com",
    firstName: "Alice",
    lastName:  "Smith",
    isActive:  true);

CreateUserAsync is idempotent — re-running with the same email is a no-op.

2. Map SSO groups to teams

For SSO-provisioned users, groups arrive as claims in the SAML/OIDC response. Map them to workspace teams in Admin → SSO:

On every sign-in the workspace reconciles team membership against the claim — adding new memberships and removing dropped ones. There's no manual sync to schedule.

If your IdP doesn't expose groups, fall back to attribute-based mapping (department=Engineering → team Engineering).

3. Grant access

Default: a node has no explicit restrictions and is visible to all signed-in users. Grant narrower access via the graph:

graph.RestrictAccessToTeam(reportNode, marketingTeam);   // only marketing
graph.RestrictAccessToUser(reportNode, specificUser);    // only one person
graph.ClearPermissions(reportNode, exceptOwners: null);  // remove all, only system access

Permission grants are graph edges — they show up in audit logs and in the Permissions panel on the node's detail page.

4. Promote to admin

Admin is a property, not a team. Promote via the UI or programmatically:

// Equivalent to checking "Admin" in the user dialog.
graph.AddAdminToTeam(user, workspaceAdminTeam);

Treat admin as a separate identity. Many orgs require admins to have a second account (alice-admin@example.com) used only for admin tasks; the day-to-day account is a regular user.

5. Audit and review

Quarterly reviews catch creep:

The workspace's admin panel exposes these views; the underlying queries are also graph queries you can run yourself.

6. Deactivate

Three steps, in order:

1. Set isActive = false on the user node. Their session is invalidated on next request.
2. Remove SSO group claims (or disable the user in the IdP). Prevents re-activation by signing in again.
3. Transfer ownership of any nodes they own (see below).
4. (Optional) Delete the node after retention period. Keeping _User nodes around preserves audit trails — most orgs do.

7. Ownership transfer

When alice@example.com leaves and owned 200 nodes, transfer those edges in one query:

var alice = Node.GetUID("_User", "alice@example.com");
var bob   = Node.GetUID("_User", "bob@example.com");

// Replace every Owns edge from alice with one from bob.
await graph.QueryAsync(q => q
    .StartAt(alice)
    .Out("Owns")
    .Take(int.MaxValue)
    .Emit("N"));

// (apply re-linking in your connector loop)

The pattern: query → relink in a connector → commit. For files specifically, the SDK has helpers (RestrictAccessTo*) that handle the common shape.

Programmatic management

See C# SDK and Python SDK.

Least-privilege defaults

• Grant via team, not via user. Easier to revoke.
• Use the principle: a user gets access through one team per resource, never two. Multiple grant paths make revoke ambiguous.
• Admin accounts should be separate from day-to-day accounts.
• Token scopes for connectors should be writes-only on the relevant types — no admin scope. See Token scopes.
• Audit logs are graph data; redact carefully if exporting.

Lifecycle diagram

Common pitfalls

• Granting to users directly. Looks simple, becomes unmanageable. Always go through teams.
• Forgetting ownership transfer. Deactivated users still appear as owners on orphan nodes.
• SSO claim drift. A user changes departments at the IdP but the claim isn't refreshed until they sign in. Force re-sign-in periodically.
• No deactivation runbook. Every offboarded user is a security gap until you have a documented procedure.
• Mixing personal and admin accounts. Hard to audit "did Alice do this as admin or as user?"

Where to go next

• Access control model — ReBAC deep dive.
• SSO providers — IdP integrations.
• Permissions — per-node permission UI.
• C# SDK — programmatic user/team management.