Alation user roles and licence types describe how a person who uses the Alation catalog is counted. Alation uses roles to control what each user can do and licence types to determine which roles can be assigned.[1] A user’s role therefore decides which seat the user consumes, and the Named User definition in the Master Cloud Software License and Services Agreement ties each seat to an identified employee or contractor.[2] From August 18, 2026, Alation states that documentation for Alation Cloud Service moved to a new documentation site, while the older site continues to cover customer-managed deployments.[3] Catalog proof: Creator licence.
Editions
There are three licence levels. The documentation describes them as follows.[1]
| Licence type | Roles that consume it | Availability |
|---|---|---|
| Creator | Server Admin, Catalog Admin, Data Source Admin, Steward, Composer | Alation Cloud Service and customer-managed |
| Explorer | Explorer | Alation Cloud Service |
| Viewer | Viewer | Alation Cloud Service and customer-managed |
The classic documentation adds that the Explorer licence is available from Alation version 2023.1 on Alation Cloud Service deployments on the cloud-native architecture.[4] The Alation Cloud Service documentation lists “Source Admin” as the role name in its task sections, while the licence-type table and the Licenses page use “Data Source Admin”; both lines describe roles that require the Creator licence.[1][5] Catalog proof: Creator licence is required for content-creating roles.
Roles and what they can do
The documentation groups the roles by function, and every group states its licence requirement.[1]
- Server Admin (Creator). Full, global administrative access: system settings and Admin Settings pages, installing connectors, registering data sources and BI servers, managing users, roles and groups, catalog customisation, running queries on any data source, and managing all data sources. Server Admins are the only role that can manage system-wide settings and view licence consumption.[1]
- Catalog Admin (Creator). Manages and customises the catalog without Admin Settings access: creates and edits catalog objects, manages workflows and catalog sets, acts as Data Source Admin for sources they manage, manages groups and customisation, and uses Compose.[1]
- Source Admin or Data Source Admin (Creator). Focuses on data sources: creating and editing documents and folders, scheduling metadata extraction for managed sources, adding or removing Stewards and granting access. This role cannot manage groups, catalog customisation or Admin Settings.[1]
- Steward and Composer (Creator). Authors who create and edit documents and folders, edit fields, use Compose, upload data dictionaries and use most Stewardship and Governance features.[1]
- Explorer (Explorer). Uses the catalog much as a Viewer does, with the added ability to run query forms and to use the Query API with some limits. Explorers cannot create or edit catalog content.[1]
- Viewer (Viewer). Read-only: searches and browses permitted objects, participates in conversations, views and stars catalog sets and downloads data dictionaries. Viewers cannot use Compose, Alation Analytics or Analytical Stewardship features, cannot create or edit objects, cannot run table or column profiles and cannot be Data Source Admins.[1]
The key licensing consequence is that a user who needs to edit anything, write queries in Compose or administer a source is a Creator seat, which is the most restricted of the three types. The Viewer role cannot be assigned as an article reviewer, so promoting a Viewer to give edit access changes the licence consumed.[1] Catalog proof: Viewers cannot use Compose or Analytical Stewardship; Explorer licence is available on Alation Cloud Service only.
Metrics and counting
Seats follow the role
The Users page states that when a specific role is assigned to a user, the corresponding licence seat is consumed; when the role changes, the previously assigned seat is released, the seat for the new role is consumed, and the licence dashboard is recalculated.[6] A suspended user cannot log in and their seat is freed, and reactivation restores access with a specific role.[6] All new users are assigned the Viewer licence and role by default, and a Server Admin can change the default role for new accounts.[1][6] Catalog proof: Assigning a role consumes a licence seat; Suspending a user frees the seat; New users are Viewers by default.
Directory sync and bulk changes
Signup moderation can require a Server Admin’s approval before an account is active; bulk activation of pending requests assigns the Viewer role.[6] When SCIM sync is enabled, SCIM governs user lifecycle and group membership, but roles are not carried in the SCIM payload: roles for SCIM-linked users come from mapping SCIM-synced groups to Alation roles through custom groups. Users created before SCIM was enabled or outside it, for example through CSV import or manual creation, are non-SCIM-linked and must be suspended manually, which releases their seat.[6] A licence reconciliation should therefore compare the Licensed Users table with the identity provider groups that drive role mapping. Bulk upload through the Users page processes up to 25 user entries per file for creation or update.[6]
System users
OAuth client applications have system users, each created automatically with its client application and used only to determine which Alation APIs the application may call. The role of a system user is changed by editing the client application, and the system user is suspended if the client application is deleted.[6] The pages reviewed do not say whether system users consume a licence seat, so a customer that depends on API integrations should confirm that point with Alation.
Licence reporting
Server Admins use the Licenses page (Admin Settings, User Management) on Alation Cloud Service to see licence consumption. It reports contract expiration date, days left and licence creation date; a Standard card with purchased, used and available data objects (Unlimited when there is no cap; deleted objects are not counted); the count of purchased suggested descriptions; Data Quality objects; Data Products usage including monthly chat messages; Curation Automation packs and AI actions; and Licensed Users with purchased, used and available Creator, Explorer and Viewer seats, with a Creator breakdown by role.[5] If Data Quality has not been purchased the section reads “Data Quality (Not Purchased)”.[5] Catalog proof: Only Server Admins can view licence consumption; Standard licence counts data objects and excludes deleted ones; Data Products licence counts products and monthly chat messages.
Grace seats
The licence may include a grace number of seats of each type. A counter showing “0 left” means the soft limit of purchased seats has been reached while grace seats remain, and “Limit Reached” appears only when all seats including grace seats are assigned.[5][4] The documents do not state the size of the grace allowance, how long it may be used or whether use of grace seats is billed, so it should be read from the licence itself and the Order. Catalog proof: Grace seats.
Virtualization and partitioning
The role and licence documentation does not address virtual machines, cores or instances. The only instance-based wording is in the customer-managed addendum, which allows one each of production, backup, test and development instances up to the licensed Named Users.[7] Because a Named User is identified by a unique email address and may not be shared, running several Alation instances for one organisation does not by itself multiply the Named User count in the documents reviewed.[2]
Cloud, customer-managed and licence files
The Creator and Viewer licences apply to both deployment types; the Explorer licence is limited to Alation Cloud Service.[1] On customer-managed instances, a Server Admin can upload a new licence file to update the licence, which Alation validates, and the file is obtained for each instance from the Customer Portal.[4][8] The upload option does not apply to Alation Cloud Service.[5] Catalog proof: Licence file is replaced from the Customer Portal on customer-managed instances.
Programs
The seat programs in the documents are the grace seats above, seat reassignment under the MSA (a Named User subscription may move to a replacement user under the same term) and, for the ACU model, a separate pool that is not counted by seat.[2][9] Alation describes the ACU model as replacing “seats, per-table subscriptions, or separate product tiers” for AI products, so the Creator, Explorer and Viewer seats remain the measure for the core catalog only.[9] Catalog proof: Named User subscriptions may be reassigned.
Audit considerations
For cloud customers the MSA lets Alation review use against the limits in the Order and charge excess use at then-current list prices; the customer-managed addendum adds a quarterly Named User audit; and the federal addendum adds a signed compliance certification and an audit of Named Users, connectors, apps and objects.[2][7][10] The Licenses page and the Licensed Users table are the customer’s own evidence for those reviews. Seats consumed by dormant accounts, by users whose role was raised temporarily and not lowered, and by non-SCIM-linked accounts after a directory rollout are the common sources of difference between the entitlement and the count.[6]
Out of scope
This article does not cover the roles used inside individual products, such as Data Products App roles, Marketplace roles or AI Governance roles, which are separate from the Creator, Explorer and Viewer licence mapping, and it does not cover the API access matrix by role.[5] Pricing per seat is not published in the documents reviewed.