Your account and your organization
Your profile
Account → Profile. Your name and email, as they appear to everyone else in the organization.
Email verification
New accounts verify their email address. Until verification completes, some deployments restrict what you can do. The verification link is sent when you sign up and can be resent.
Signing in
Which sign-in methods exist is decided by whoever operates your PlatformSmith deployment — password, Google, GitHub, or a combination. A deployment can also disable signup entirely, making it invite-only.
Linking a Google or GitHub identity
You can link an identity to an existing account so you can sign in either way. Linking is authenticated-only by design: you sign in first, then link.
That order is deliberate and is not a limitation. If arriving from an identity provider could silently attach to an existing account, anyone who could prove control of an email address could take over the account using it. So there is no "sign in with Google and we will find your account" path — you authenticate as yourself, then add the identity from Account → Identities.
Linking GitHub as a sign-in identity does not let agents reach your repositories. That is a separate Git connection on the organization.
Personal integrations
Account → My integrations holds credentials that are yours: your own model key, your own subscription token. They follow your account and are used ahead of the organization's shared ones for things you do. → Integrations
Inviting members
An owner or admin invites people by email. Accepting an invitation adds the person to the existing organization — it creates nothing for them, so a new member sees your workspaces and projects, not an empty account. → You were invited
What each role can do
Five roles, granted at organization scope or at a single workspace:
| Role | Scope | Short version |
|---|---|---|
| owner | organization | Everything. The last owner cannot be removed |
| admin | organization | The same as owner today |
| member | organization | Read across the organization, create workspaces, manage their own personal integrations. Cannot launch anything |
| workspace-admin | one workspace | Full control of that workspace, including its members and tokens |
| workspace-editor | one workspace | Work inside it — projects, runtimes, sessions, playbooks. Read-only on environments and secrets |
The full table, with the two things people most often get wrong, is on Security and tenancy.
Anyone with a role in a workspace has it over every project and environment in that workspace. To separate who can see what, use separate workspaces. → Why
Personal access tokens
A personal access token lets a script or a tool call the API as you, with your permissions. Mint one from your account settings.
Treat a token as a password: it is shown once, it acts as you, and anyone holding it can do anything you can. Delete tokens you are no longer using. → API and automation
Leaving or removing someone
Removing a member revokes their access immediately. Their personal integrations and tokens go with them; company integrations, and everything they created in a workspace, stay.