Applivery has different types of users that has been created to help you better manage access to resources, apps and devices in a more granular ways as well as having visibility over the usage of your Apps across your organization. Although there’s a quick user guide about how you can start inviting people to your workspace we recommend you to take a look to this document that deep dives more on each user type and how they are created.
Types of users #
There are 8 types of users in Applivery, divided in 2 categories:
Collaborators #
Role
Description
Owner
Super-administrator of your workspace. There's just one per workspace.
Admin
Manages only Developers.
Administrative permissions over Apps, Devices or Workspaces.
Full access to all resources except Billing.
Editor
Upload of builds.
Managed devices.
Basic administrative permissions.
Read-only access to: Distribution, Settings.
No access to: Billing. Can't remove devices.
Viewer
Read-only permissions for all resources.
No access to: Billing, People, Settings.
Unassigned
No access to any resources.
Can have roles at app level.
Employees #
Origin
Description
Dashboard
Employees that have been invited from the dashboard. They receive an email to register their employee's account and then access the App Store.
SSO
Employees that are automatically created when logging in into your App Store using a Single Sign-On.
SDK
Named employees (with at leas a known email address) that have been programatically created using the bindUser() method of the Applivery SDK.
SDK temporal
Unknown users automatically created by the Applivery SDK to identify the device. They are unique across your workspace based on the device id and expire after 30 days on inactivity within your Apps.
Activity trace #
The Activity Trace system provides per-user tracking of last login and last action timestamps across the Dashboard, SDK, and Enterprise Store. Logins update both fields, while other activities update last action as appropriate.
These timestamps are exposed via the API and can be used to sort users in the People section.
In this section, Collaborators and Employees are displayed together, but they are treated as separate user groups.
When you apply sorting, the system first lists Collaborators who have a recorded last activity, followed by Collaborators without any registered activity. After that, Employees with last activity are shown, and finally Employees with no activity.
This logic applies in both ascending and descending order, as the sorting is always structured in blocks by user type. Users with no activity are consistently placed at the end of their respective block.
Dashboard #
On login: Every manual Dashboard sign-in updates:
lastLogin.dashboard.lastAction.dashboard(login counts as an action).
On refresh token issuance: Occurs periodically whenever a user renews its access token:
lastLogin.dashboard.lastAction.dashboard.
Store #
On login: Every manual Store sign-in updates:
lastLogin.store.lastAction.store.
SDK #
On login: Usually once per device/session, since the SDK handles persistent authentication:
lastLogin.sdk.lastAction.sdk.
General behavior #
The system maintains separate last login timestamps for each source—Dashboard, SDK, and Store—and exposes both last login and last action in the user/employee API responses.
The last action timestamp is updated only if the action occurs at least one minute after the previous one and is not already being updated as part of a login event.
Special considerations #
- De-duplication logic: Last action ignores repeated actions occurring within one minute.
- Login = action: Any login updates both last login and last action.
- Refresh token flow: Dashboard refresh tokens trigger both timestamps.
- Multi-source timing: When activity comes from multiple sources, only the most recent timestamp is retained.