Users & teams

A workspace belongs to an organization. People join as members with a role, share workflows and resources, and the owner controls billing and data-governance settings. This page covers the account itself, roles, SSO and SCIM, and how notifications are routed.

account ▸ profile

Registration & profile

Sign up with email and password, then verify your email — privileged actions stay locked until you do. Your profile holds your display name, avatar, locale and notification preferences.

Export & deletion

GET /account/export returns a machine-readable export of your account data. Deleting the account requires your current password, and what happens next depends on your role: a sole owner deletes the organization with it (a typed confirmation is required), while the owner of a multi-member organization must first transfer ownership to another member — or explicitly delete the entire organization.

See Privacy and the Data Processing Addendum for how data is handled, and sub-processors for who processes it.

roles ▸ one per member

Members & roles

Invite teammates by email. Each member has exactly one role:

Role	Can do
Owner	Everything, including billing, plan changes and deleting the organization. One owner per organization; ownership is transferable, and the previous owner becomes a member.
Admin	Manage members, workflows, resources, monitors and endpoints. No billing-destructive actions.
Member	Create and run workflows, monitors and automations within granted scopes.

Invitations and role changes can assign admin or member; ownership moves only through an explicit transfer.

sso ▸ domain-routed

SSO & domain verification

Single sign-on binds to a domain you prove you control: create a DNS TXT record at_writ-sso-verify.{domain} with the value the setup screen gives you. Once verified, sign-ins for that domain route to your identity provider. Two properties are worth knowing:

sso_enforced (optional): non-SSO logins for the domain are refused — password sign-in stops being an alternative door.
SSO discovery reveals routing only. Asking “how does this email sign in?” never discloses whether an account exists.

scim ▸ the roster, synced

SCIM provisioning

Organizations can provision members over SCIM 2.0 from an identity provider. Deprovisioning a user removes their membership, suspends the account if it is left with no membership at all, and immediately revokes any live sessions and tokens — offboarding in the IdP is offboarding in Writ, with nothing left signed in.

oauth ▸ capped

OAuth grants are capped

Access granted through an OAuth flow is capped at the operator role — however broad the requested scopes, an OAuth grant never carries admin. Administrative control stays with people who signed in as themselves.

notifications ▸ categories × channels

Notification preferences

Platform notifications are a grid: seven categories — security, billing,team, runs, agents, marketplace,support — across six channels: in_app, email,sms, whatsapp, signal, pushover. You choose per cell, with a deliberate exception: a few cells are locked always-on — security alerts, payment problems and team invites cannot be silenced.

org ▸ settings

Organization settings

Organization settings cover the workspace name and the defaultagent routing for runs. Writ runs on your own accounts, with your own credentials and data, on sites you are authorized to use — seeWhere it runs for exactly what executes where.

What next

Personas, secrets and agents: what your team shares.
Billing & usage: the one-pool model and who pays.
Authentication: API keys, scopes, rotation.