One potential source of confusion for those who own or administer eagle.io accounts is how those accounts relate to the personal user profiles representing individuals who log into the platform.
Let's eliminate the confusion, first by defining some key terms. In eagle.io nomenclature, an account refers to a paid (or trial) account that has been created by an organization. Each account must define a single user as the account owner, and can also define a list of users to be administrators (the account owner automatically appears in the administrator list). There are many account-level settings and features which can be configured, but in essence an account can be summarized as an entity which represents the organization paying for the eagle.io service, which contains workspaces, and which is managed by an owner and administrators.
Notably, accounts are separate entities to users. A user profile in eagle.io represents a real person (or at least, a real unique email address), and exists independently of any account. That is, an account does not "own" any user profiles. The only direct relationship between user profiles and accounts is that of the account owner (i.e. the user profile who created the account) and the account administrators (the other user profiles shown in the administrators list). Importantly, there is no direct relationship between an account and the user profile of an end-user (i.e. a user who is not an account owner or administrator). Instead, this relationship exists between a workspace and an end-user profile; each workspace defines a list of end-user profiles that have some level of access to that workspace.
The term "user account" will be avoided in favor of user profile in this article.
How do user profiles get created? There are three scenarios where this happens (and the third has an API option).
First scenario: creating a new account trial
When signing up for a trial eagle.io account (which is the first step to a paid account) the email address used in the signup form will be used to create a new user profile, if the email address is not already in use by an existing user profile. This new user profile will be the owner of the new account (after appropriate verification of the email address).
Once the user finishes setting up their new profile and logs in for the first time, they will have full access to the account they just created.
Second scenario: creating a new administrator
If the account owner (or an account administrator) adds an email address to the administrators list, that email address will be used to create a new a user profile, if the email address is not already in use by an existing user profile.
The new user profile is not complete yet; a welcome email will be sent to the address, prompting the user to verify the address and complete their profile details:
Once the user finishes setting up their new profile and logs in for the first time, they will have administrator access to the account, and will therefore see all workspaces of the account listed in the workspaces tree.
Third scenario: granting workspace permissions
If the account owner (or an account administrator) adds an email address to a workspace users list, that email address will be used to create a new a user profile, if the email address is not already in use by an existing user profile.
As with administrators, the new user profile is not complete yet; a welcome email will be sent to the address, prompting the user to verify the address and complete their profile details. This will look exactly like the welcome email received by the new administrator:
Once the user finishes setting up their new profile and logs in for the first time, they will have workspace level access, meaning that in the workspaces tree, they will only be able to see the workspace to which they were given access.
Adding a new user to a workspace can also be done via the API. However, in this case a welcome email is not sent to the user; instead a profileActivateUrl will be returned by the API so the user profile can be finalized by navigating to the URL in a web browser. The end result is the same; when the new user logs in for the first time, they will only see the workspace that was shared with them. Of course, as soon as any additional workspaces are shared with that user, they will also be listed in the workspaces tree.
That covers our three scenarios that will result in creation of a new user profile. But what if we replayed those scenarios but this time using the email address of a user who already has a user profile? In such cases, the user in question would not have to set up their profile, because it would already exist. They would simply receive an email confirming the additional access. For example, if a user with an existing profile was added to the administrators list of an account, they would receive this email:
Next time this user logs in, they will have administrator access to the account, and will therefore see all workspaces of the account listed in the workspaces tree. This is in addition to any workspaces they could already see due to any access previously granted to their user profile; for example, they may already be an owner, or administrator, or workspace user of one or more existing accounts.
And if a user with an existing profile was added to the users list of a workspace, they would receive this email:
Next time this user logs in, they will have workspace level access, and will be able to see the new workspace listed in the workspaces tree. This is in addition to any workspaces they could already see due to any access previously granted to their user profile; for example, they may already be an owner, or administrator, or workspace user of one or more existing accounts.
Now we have covered the mechanics both of triggering new user profile creation, and adding various types of account or workspace access to new and existing user profiles. So, let's review the fundamental concept: user profiles can contain multiple different types of access, to multiple accounts and multiple workspaces, at the same time. You could be the owner of one account, while being the administrator of another two accounts, and also be on the workspace list of twenty additional workspaces spread over a dozen other accounts. None of those accounts "owns" your user profile. No other person (outside of eagle.io support staff) can be aware of the totality of access that your user profile has been granted.
Finally, there are a few extra considerations regarding user profiles.
- The same user profile cannot be re-used as the owner for more than one account. So if you are already the owner of an eagle.io account, you won't be able to use the same email address to request an additional trial account.
- Only the account owner can transfer ownership or close the account.
- Managed accounts have some additional rules: every administrator of the parent account automatically becomes an administrator of each managed account created by that parent. These administrators will be listed in the managed account administrators list with a type of "Account manager user", and cannot be deleted. Additional administrators can be added to or removed from a managed account using the normal procedure.
- User profiles are not deleted. If a previously granted level of access is removed from a user profile (for example, if that user is removed from the administrators list of an account), then the user will see fewer workspaces in their workspaces tree. If all previously granted access is removed, the user will still technically be able to log in, but will see a message indicating that no workspaces have been shared with them, and they will not be able to perform any actions within the system until such time as access to at least one workspace is granted.