---
title: "Alation Project Custom Fields"
slug: "alation-project-custom-fields"
updated: 2026-10-13T17:54:33Z
published: 2026-10-13T17:54:33Z
canonical: "docs.validatar.com/alation-project-custom-fields"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.validatar.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Alation Project Custom Fields

## Overview

The **Alation - Project Custom Fields** set adds an **Alation Publishing** section to every Validatar test. Test owners use it to choose which tests the [Alation Data Source Template](/docs/alation-data-source-template) publishes to Alation Data Health, how each one is named there, what a failure shows as, and which Alation object the result lands on.

**Marketplace:** [Alation - Project Custom Fields](https://admin.cloud.validatar.com/marketplace/77)

These are project custom fields, so they appear on tests in every project. The fields that hold Alation metadata in the Validatar catalog are a separate set, [Alation Catalog Custom Fields](/docs/alation-catalog-custom-fields). Both are part of the [Alation Integration](/docs/alation-integration).

Import this set before you publish tests to Alation. The publish test also writes to two of these fields, and those writes fail when the fields do not exist.

## Fields

All six fields sit in one section, **Alation Publishing**, on the Test object type.

| Field | Reference key | Type | Purpose |
| --- | --- | --- | --- |
| Publish to Alation | `alation_publish` | Dropdown: Yes, No | Opts the test in or out |
| Alation Rule Name | `alation_rule_name` | Short text | The rule name Data Health shows for the test. Blank uses `Validatar:` followed by the test's name |
| Alation Rule Key | `alation_rule_key` | Short text | An optional stable key for the rule. Blank uses the **Rule Key Prefix**, then `.test.` and the test's id, for example `validatar.test.1993` |
| Alation Failure Status | `alation_failure_status` | Dropdown: Alert, Warning | What a failure shows as. Blank means Alert |
| Alation Object Key | `alation_object_key` | Short text | The Alation object the result lands on. The publish test fills it with the table's key; set a column's key to show a column-level test on that column |
| Alation Object Type | `alation_object_type` | Dropdown: Table, Column | Whether **Alation Object Key** names a table or a column. Blank means Table |

## How publishing uses the fields

Individual test results are published only when the Alation data source's **Publish Scope** is **Trust + Dimensions + Tests**. At the narrower scopes these fields change nothing.

**Publish Tests** on the Alation data source decides what a blank **Publish to Alation** means:

- **Opted-in tests** publishes only tests set to Yes.
- **All tests** publishes every test on a matched table unless it is set to No.

A passing test shows as Good. A test that errors shows as Warning whatever **Alation Failure Status** says, because an error means the test could not run, not that the data failed.

The publish test fills **Alation Object Key** and sets **Alation Object Type** to Table the first time it publishes a test with **Dry Run** off. It never replaces a key that is already there, so a column you set by hand stays. The **Push Test Result to Alation** test action reads these fields to find where the result goes.

Set **Alation Rule Key** when a test may be rebuilt under a new id and should keep its rule in Alation. Data Health identifies a rule by its key, so a changed key starts a new rule, and Validatar does not remove the old one.

## Import the fields

You need the Global Custom Metadata Admin role, or Global Admin.

**From the marketplace (recommended)**

1. In Validatar, open **Marketplace** and find **Alation - Project Custom Fields**.
2. Choose **Get**, then **Import Directly**. Validatar opens **Settings > Project Custom Fields** with an **Import Custom Fields** panel on the right.
3. In the list of object types on the left, open **Test**. **Import All** adds the panel's sections to the object type that is open, so make sure it is Test.
4. Choose **Import All**, then **Save**.
5. Check that the Test page now has an **Alation Publishing** section with the six fields above.

**From the downloaded file**

1. Choose **Get**, then **Download XML**.
2. In **Settings > Project Custom Fields**, open **Test**, choose **Import**, select the file and choose **Next**.
3. Choose **Import All**, then **Save**.

> **Note:** Choose **Import All** once. A second **Import All** adds the section again, and the page will not save until you remove the copy.

If you created these fields by hand before this set existed, keep yours: the template finds the fields by reference key, so a hand-made set with the same keys works the same way.

## Related

- [Alation Integration](/docs/alation-integration)
- [Alation Data Source Template](/docs/alation-data-source-template)
- [Alation Catalog Custom Fields](/docs/alation-catalog-custom-fields)

> **Note:** The field set has been imported from the marketplace into a Validatar instance, and the template's Validatar client has written and read all six fields on a test there. In a run inside Validatar, the publish step filled **Alation Object Key** and **Alation Object Type** on the opted-in tests, and the test action used them to publish each result. It has not yet been used against a live Alation environment, so expect small adjustments after your first live run.