Accounts, teams, and users
Understand where each setting lives on Azion: your user profile, the account, the client accounts of a group, and the teams that grant permissions.
Everything you build on Azion lives inside an account, and every person who works on it signs in as a user of that account. What a person can see and change is decided by three things that fit inside one another: their own user profile, the account and its owner, and the teams the owner places them in. A Group account adds one more level, the client accounts of its affiliates, each with its own owner. This page covers the user profile, the account, client accounts, teams and permissions, and the personal tokens that reach the account from outside Azion Console.
User profile
A user profile holds what belongs to one person: first and last name, the timezone that sets the time displayed on pages such as Activity History, the email used to sign in, a phone number, and the password. The interface language is English and cannot be changed. When you change your email, Azion sends a confirmation to the new address, and the change applies only after you confirm it. From the next sign-in you use the new email, even through Social Login, and the former address becomes free for a new account.
Multi-Factor Authentication (MFA) has a personal side and an account side. When the account does not enforce MFA and your user has the permission, you can turn it on for your own sign-in. When the account already enforces it, the option is locked for you, because the account owner decided it for everyone. For the fields, refer to Your settings.
The account
The account is the container: it owns the resources you deploy, the users and teams that work on them, the billing profile, and the security controls that apply to every sign-in. Its profile carries the account ID, the account name, the company name and its unique identifier, and the billing emails, up to 256 characters separated by semicolons. The address fields are mandatory, because they belong to the billing account, and a change on the page is saved only when all of them are filled.
One user is the Account Owner. Only the owner can change the authentication settings and delete the account. Turning on Social Login lets every user of the account sign in with GitHub or Google. Enforcing MFA makes it mandatory for every user except the owner. The tradeoff is scope: enforcing MFA at the account protects everyone at once, while leaving it to each user protects only those who turn it on. After the owner deletes the account, Azion sends an email confirming the deletion and keeps the account information, and a new account can be created at any time.
Every action taken in the account by any user is recorded in the Activity History for the last 30 days, with the user who performed it, and older logs are available from the Support team. The same log can be streamed to your own tools through Data Stream. For the fields, refer to Account settings and Activity history.
Client accounts
An account of the Group type can create separate accounts, called Clients, for each affiliate in the group. Each client account has its own Account Owner, its own address and billing emails, and is managed independently under the group. Creating a client needs the Account Owner of the group or the permissions View client list and Change clients.
When the client is registered, its owner receives an activation email that stays valid for 14 days. If the account is not activated in that period, the owner is removed from the Platform. An Active Client switch on each client turns its operation on or off without deleting it. For the fields, refer to Accounts.
Teams and permissions
Permissions are granted to teams, never to a user directly. The Account Owner creates the teams and sets what each one can view or change; every other user is a non-owner whose access is the sum of the teams they belong to. Owners have access to every setting and every team without being placed in one. Permissions come in pairs: an Edit permission always requires the matching View permission, and some pairs require a third, such as View Bills for the billing permissions.
A user in more than one team receives the permissions of all of them, which is the tradeoff of the model: a wider set of teams means fewer blocked pages and more settings within reach. For example, a team with View Applications but not Edit Applications can audit every application configuration and change none, and a user who opens a page without the required permission receives a 403 Forbidden error page. Adding users needs the Account Owner or the View Users and Edit Users permissions, and each new user is created with a profile, a timezone, and the teams they belong to. For the full permission table, refer to Teams permissions; for adding and removing users, refer to Users management.
Personal tokens
A personal token is a string of characters that authenticates your user outside Azion Console, in the Azion API and the Azion CLI. You create it with a name, an optional description, and an expiration of 1, 7, 15, 30, or 90 days, 1 year, or a custom date. The token is shown once, when you create it, and cannot be seen, copied, or modified afterwards; the list shows only its scope, last modified date, and expiration date. Treat it like a password: a long-lived token is convenient for automation and needs the same care as the credential it replaces. For the fields, refer to Personal tokens.