About Templates and Fields

Alation Cloud Service Applies to Alation Cloud Service instances of Alation

Customer Managed Applies to customer-managed instances of Alation

Catalog pages of Alation objects are built on templates. A template is a set of fields that are assembled into a page to deliver relevant information about a catalog object. For example, a table object template might include fields for the table title, description, owner, and tags. A column object template might include fields for the column title, data type, and description.

If you have the Catalog Admin or Server Admin role, you can customize certain catalog pages by customizing the underlying templates or creating new custom templates. When customizing or creating a template, you can add, remove, rearrange, and group various fields to meet the needs of your organization. You can also create your own custom fields to add to templates. The various types of fields are described in the Field Types section below.

Not all object types have a customizable template. For example, the template for a table object is customizable, but the template for a query object is not. Objects with a customizable template are shown in the Template Type Table table below.

Template Types

There are two types of template in Alation:

• Adjustable-order templates are templates that allow you to add and remove fields and rearrange the order of the fields. In addition, you can group fields together under a custom heading.

• Fixed-order templates have a fixed order of fields. You can add and remove fields from these templates, but you can’t rearrange the order of the fields or put fields into groups.

Some object types can have multiple templates. For example, you can create multiple templates for documents. If multiple document templates exist, users will choose which template to apply to a given document object when creating a new document in the catalog.

Other object types can only have one template that’s automatically applied to all objects of that type. An example of this is the data source object type—there’s a single data source template that applies to all data source objects.

Template Type Table

The following table shows the template type for each object type in Alation, along with whether the object type can have multiple templates. Some object types don’t have a customizable template. Such objects don’t appear in the table below.

Object Type	Template Type	# Templates Possible
API resource	Fixed-order	One
API resource folder	Fixed-order	One
API resource field	Fixed-order	One
Article	Fixed-order	Multiple
BI data source	Adjustable-order (in 2024.1.2+)	One
BI data source column	Adjustable-order (in 2024.1.2+)	One
BI folder	Adjustable-order (in 2024.1.2+)	One
BI report	Adjustable-order (in 2024.1.2+)	One
BI report column	Adjustable-order (in 2024.1.2+)	One
BI server	Adjustable-order (in 2024.1.2+)	One
Column	Adjustable-order	One
Data source	Adjustable-order	One
Dataflow	Fixed-order	One
Directory	Fixed-order	One
Document	Adjustable-order	Multiple
Domain	Adjustable-order	One
File system	Fixed-order	One
File	Fixed-order	One
Folder	Adjustable-order	Multiple, one per document hub
Policy (Business)	Adjustable-order	Multiple
Policy (Data)	Adjustable-order	One
Policy Group	Adjustable-order	One
NoSQL database	Fixed-order	One
NoSQL collection	Fixed-order	One
NoSQL attribute	Fixed-order	One
Schema	Adjustable-order	One
Table	Adjustable-order	Multiple, one per data source (in 2024.1.2+, if enabled)
Term	Adjustable-order	Multiple

Default Templates

When you first open the default catalog page of an object in the freshly installed Alation catalog, it has only default fields organized into two sections: a wider main section and a narrower sidebar on the right. Examples are shown below both for the new user experience and the classic user experience.

New user experience:

Classic user experience:

You can customize the number of fields and their layout by customizing the underlying template. The types of fields that can appear on a catalog page are described in the next section.

Field Types

Alation has three basic types of fields that can appear on a catalog page template:

• Built-in fields are editable fields provided by Alation. Examples of built-in fields include Title, Description, and Stewards.

• Object-defined fields are read-only fields that are associated with a particular object type. Examples include Sample Columns, Table Constraint, and Data Type.

• Custom fields are user-defined fields that can be added to templates.

A template always has some Alation-defined default fields that appear on the catalog page before any customizations are applied. Default fields can be any of the three basic types listed above.

Note that some fields, such as Description or Sample Content, always appear on the catalog page even if empty; however, some other fields are hidden from the catalog page unless the source database has the required type of data to fill them. Examples of fields that may be hidden if empty are the Source Comments, Table Constraints, and View SQL fields. Unlike the catalog page, the template always shows all fields available for the given object type to allow you to define their location.

When editing a template, you can group custom or object-defined fields together under a custom heading. This grouping is called a group of fields. The group can be moved from place to place within the template.

The three basic types of fields are described in more detail below.

Built-in Fields

Built-in fields are fields provided by Alation whose values can be edited by users with appropriate permissions. Some built-in fields can be removed from templates, while others cannot.

The following table lists some of the more common default built-in fields:

Field	Description
Title	Holds the page title.
Description	Holds the description of the object.
Stewards	Lists the currently assigned stewards.
Tags	Lists tags that are currently attached to the object.
Domains	Lists domains that are currently assigned to the object.

Object-defined Fields

Object-defined fields are fields that are automatically provided by Alation based on information or functionality associated with a particular object type. Object-defined fields are read-only. Their values are derived automatically from the object itself.

Some object-defined fields can only go in the main section of a template; others can only go in the right sidebar.

Object-defined fields can be removed from a template and re-added as part of a group of fields, if this functionality is enabled. See Enable Removability of Object-defined Fields.

The following table lists some of the more common default object-defined fields:

Field	Description	Applies To
Column Profile	If Profiling is performed, holds the samples of the data in the column.	Column
Data Type	Holds information on the data type of the column.	Column
Referenced By (group of fields)	A group of fields that contains the Backreferences, Relevant Articles, Data Policies, and Mentions fields. This will list articles, policies, documents, and other objects that reference the current object through object set fields, references, or @-mentions.	Data source, schema, table, column, domain, BI server, BI folder, BI data source, BI data source column, BI report, BI report column, document, folder, glossary, data policy, business policy, policy group
Properties	Lists the properties of the object.	Data source, schema, table, column, etc.
Published Queries	Lists published queries that use this table.	Table
Sample Columns	Lists the child columns of a table.	Table
Sample Content	Holds samples of the data in table columns. Will only have data if Profiling is performed for this table.	Table
Source Comments	When applicable to the database type and available in the source database, this field holds the comments added directly in the source database. Hidden from the page if empty.	Schema, table, column
Schemas	Lists schema objects extracted for the parent data source.	Data source
Subdomains	Lists subdomains of the current domain.	Domain
Table Constraint	When applicable and available in the source database, holds the table constraint expression. Hidden if empty.	Table
Tables	Lists table objects extracted for the parent schema.	Schema
Top Users	Lists top users as calculated during Query Log Ingestion (QLI) or added manually.	Schema, table, column
Upload Queries	Upload field to upload sql files to Alation.	Data source
View SQL	Depending on the source database type, will appear as “View SQL” or “Definition SQL” on the catalog page of a View object (which is a table sub-type in Alation). Hidden if empty.	Table

Custom Field Types

Custom fields are user-defined fields that can be added to and removed from templates. Custom fields can be used to capture additional metadata about objects in Alation. For example, you can create a custom field to capture the owner of a dataset, the date it was last updated, or the source of the data. For help working with custom fields, see Manage Custom Fields.

Custom fields are available in different types. Each type of custom field is designed to capture a specific type of information.

Date

Use this field type to select and display a specific date. If you want to create a date range, create two date fields, one for the start and one for the end date.

Multi-Select Picker

Use this field type to create a list where you can select multiple values.

Note

Multi-select picker fields work best when they have around 10 or fewer values. Adding many values can slow catalog page load times. You can add a maximum of 256 objects to a given multi-select picker using Alation APIs.

Object Set

Use this field type to create references (links) between catalog objects. Object sets offer a one-to-many relationship, where one catalog page can point to multiple target objects in the set. The target objects will automatically display a link back to the source object.

Note

Object set fields work best when they hold around 10 or fewer objects. Adding many objects can slow catalog page load times. You can add a maximum of 256 objects to a given object set using Alation APIs.

You can define which object types are permitted in the set. Object sets support the following object types:

• Articles

• Columns

• Data Sources

• Documents (starting in 2024.1, if Document Hubs are enabled)

• Folders (starting in 2024.1.3, if Document Hubs are enabled)

• Policies

• Schemas

• Tables

• Terms (if Document Hubs are not enabled)

• Users

People Set

Use this field type to select and display a list of users and groups. The profile pages for the selected users and groups will automatically display a link back to the source object. People sets can be used to give users permissions to custom fields.

Picker

Use this field type to create a list where you can select a single value.

Reference

Use this field type to create a reference (link) between two catalog objects. References offer a one-to-one relationship, where one catalog page can point to one target object in the reference. The target object will automatically display a link back to the source object.

You can define which object types are permitted in the reference. References support the same object types as Object Set fields.

Note

In 2023.3.4 and earlier, reference fields can only be placed in the right sidebar section of the template.

Rich Text

Use this field type for blocks of text with rich formatting.

Note

In 2024.1.3 and earlier, rich text fields can only be added in the main section of the catalog page.

Field Permissions

By default, both custom and built-in fields are viewable and editable by everyone. You can restrict users’ view and edit access to custom fields on a catalog page and restrict edit access to built-in fields.

A user with the Catalog Admin or Server Admin role can:

• Grant edit permission for built-in fields to groups or people sets.

• Grant view or edit permissions for a custom field to users that belong to a group or people set custom field. When viewing is restricted, the field is visible only to the groups and/or people sets to which the view permission is assigned. When editing is restricted, all users who can access the object can see the custom field, but only the users who belong to groups/people sets with the edit permission can edit the field.

Groups and people sets must be created before setting permissions.

Note

Permissions are applied on the field level but not on the specific data object level. If you set permissions for a field, the permissions apply to all templates where this field is added.

For help setting permissions for custom fields, see Manage Custom Fields.