Team and roles
People on your account hold a role, and the role decides what they may do: which environment they land in, whether they can move money, whether they can refund and up to how much, and whether they can change the team itself. Roles are not the same thing as API key scopes: a role governs a person in a dashboard session, a scope governs a key in a server call.
Manage the team in the dashboard under Settings → Team. There is no API call for any of this, under any credential.
The roles
| Role | Starts in | May use | Team | Moves money | Refunds |
|---|---|---|---|---|---|
| Owner | live | test + live | Yes | Yes | Uncapped |
| Admin | live | test + live | Yes | Yes | Uncapped |
| Finance | live | live only | No | Yes | Uncapped |
| Developer | test | test + live | No | No | No |
| Support | live | test + live | No | No | Capped per refund |
| Viewer | test | test + live | No | No | No |
Read the columns literally, because two of them are easy to assume wrong:
- Moving money (settlements and payouts) and refunding are separate permissions. Support can return a customer's money without being able to move yours; Finance can do both. Support's refund cap, where set, is a per-refund amount; uncapped and "may not refund at all" are shown as two distinct states, not collapsed into one.
- Finance is live-only by design. A Finance member cannot operate in test mode.
Owner is not assignable. It is the account's own identity: the invite form never offers it, it cannot be granted to anyone, an owner cannot be re-roled, and an owner cannot be removed.
Managing the team
Everything below is in the dashboard, under Settings → Team.
The list shows every member with their role and status (invited, active or disabled), and when they were invited. An account's owner row exists from the moment the account does, so the list is never empty.
Invite someone by email, name and role. This needs a role that can manage the team (owner or admin) and a fresh two-factor code. The invited person's sign-in is created and ready before the dashboard tells you it worked, so a success means they can actually sign in, not merely that a row was added; the dashboard tells you whether the invitation email actually went out, and if it did not, the person still exists and needs another way in.
- Inviting someone whose invitation is still pending resends it.
- An email already active on the team, or belonging to a different TensorRail account, is refused: an identity belongs to one account, and inviting it here would move it out of the other.
Change a member: their name, role or status, with a fresh two-factor code. Three changes are always refused, all for the same reason: an account must not be able to lose or gain its owner by accident, or quietly escalate itself:
- changing your own role,
- changing the owner's role,
- assigning owner to anyone.
Remove a member, with a fresh two-factor code. The owner cannot be removed, and you cannot remove yourself. Removal takes the person off this account's roster; revoke any API keys they created separately (see API key management).
Related
- Account security: two-factor, sessions and the step-up these actions require.
- Authentication: scopes, which govern keys rather than people.
- API key management: creating and revoking the credentials a team member uses.
- Dashboard and account: the dashboard equivalents.
TensorRail, Limassol, Cyprus.