---
title: "Issue Tracking Custom Fields"
slug: "issue-tracking-custom-fields"
updated: 2026-10-19T21:09:03Z
published: 2026-10-19T21:09:03Z
canonical: "docs.validatar.com/issue-tracking-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.

# Issue Tracking Custom Fields

## Overview

Two field sets, both with a section named **Issue Tracking**, connect Validatar tests and catalog objects to the issues an issue-management integration raises. They are shared: the [Jira integration](/docs/jira-integration) uses them today, and the integrations that follow use the same fields, so a test keeps its routing if your team moves to another issue tool.

| Marketplace item | Adds | Used for |
| --- | --- | --- |
| [Issue Tracking - Project Custom Fields](https://admin.cloud.validatar.com/marketplace/81) | 12 fields on every test | Where a test's issues go, and the issue it has open now |
| [Issue Tracking - Catalog Custom Fields](https://admin.cloud.validatar.com/marketplace/82) | 5 fields on tables, 2 on columns | The open issues raised by the tests linked to each table and column |

Neither set is required for issues to be opened and resolved. Without the test fields, a test cannot route its issues or show its open issue; without the catalog fields, the reconciliation sweep has nowhere to write open issues on tables and columns.

## Test fields

The **Issue Tracking - Project Custom Fields** set adds these to the Test object type. People fill in the first seven. The integration writes the other five; leave them alone.

| Field | Reference key | Type | Purpose |
| --- | --- | --- | --- |
| Issue Tracking | `issue_tracking` | Dropdown: On, Off | Off stops the integration opening, commenting on or resolving issues for this test, from its actions and from the sweep. Blank follows the data source |
| Issue Project | `issue_project` | Short text | The project, queue or list this test's issues go to, such as a Jira project key. Blank uses the data source's default |
| Issue Type | `issue_type` | Short text | The issue type to create, such as `Task`. Blank uses the data source's default |
| Issue Assignee | `issue_assignee` | Short text | The email address of the person new issues are assigned to. Blank leaves them unassigned |
| Issue Priority | `issue_priority` | Short text | The priority for new issues, by name as the issue tool shows it, such as `High` |
| Issue Labels | `issue_labels` | Short text | Extra labels for new issues, comma-separated |
| Issue Field Values | `issue_field_values` | Paragraph | A JSON object of field names to values for new issues, such as `{"DQ Severity": "Critical"}` |
| Issue System | `issue_system` | Short text | Written by the integration: the issue tool holding the test's issue, such as `Jira Cloud` |
| Issue Key | `issue_key` | Short text | Written by the integration: the open issue's key |
| Issue URL | `issue_url` | Short text | Written by the integration: a link to the open issue |
| Issue Status | `issue_status` | Short text | Written by the integration: the issue's status, a running count such as `Pending: 2 of 3 failures`, or `Resolved` |
| Issue Last Synced | `issue_last_synced` | Short text | Written by the integration: when these fields were last refreshed, in UTC |

The routing fields take effect on the next issue the test opens. An issue that is already open keeps its project and fields.

The written fields are a copy for people reading the test. The issue tool is the record: the integration looks up each test's issue in the tool before every decision, so an out-of-date **Issue Key** cannot cause a wrong action. The reconciliation sweep corrects it, and the [Jira Health Checks](/docs/jira-health-checks) report any that point at a closed issue.

## Catalog fields

The **Issue Tracking - Catalog Custom Fields** set adds an **Issue Tracking** section at Table and Column level. The reconciliation sweep writes them for every table and column linked to a test in its scope, and clears them when the last open issue is resolved.

| Level | Field | Reference key | Type | Holds |
| --- | --- | --- | --- | --- |
| Table | Open Issues | `issue_open_keys` | Tag list | The keys of open issues raised by tests linked to the table |
| Table | Open Issue Count | `issue_open_count` | Short text | How many are open |
| Table | Oldest Open Issue | `issue_oldest_open` | Date | When the oldest was raised |
| Table | Highest Open Priority | `issue_highest_priority` | Short text | The highest priority among them |
| Table | Last Issue Opened | `issue_last_opened` | Date | When the newest was raised |
| Column | Open Column Issues | `issue_column_open_keys` | Tag list | The keys of open issues raised by tests linked to the column |
| Column | Open Column Issue Count | `issue_column_open_count` | Short text | How many are open |

Counts are short text because Validatar custom fields have no number type. Column fields carry `column` in their keys because a reference key must be unique across catalog levels.

A test linked to a table and one of its columns reports its issue on both.

## Import the fields

You need the Global Custom Metadata Admin role, or Global Admin. The catalog set also needs Govern Edition.

**Test fields**

1. In Validatar, open **Marketplace** and find **Issue Tracking - 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 section to the object type that is open.
4. Choose **Import All**, then **Save**.

**Catalog fields**

1. Open **Marketplace**, find **Issue Tracking - Catalog Custom Fields**, choose **Get**, then **Import Directly**. Validatar opens **Settings > Catalog Custom Fields** with the panel on the right.
2. Open the **Table** level, pick Table in the panel's list, choose **Import All** once, then **Save**.
3. Do the same for the **Column** level.

> **Warning:** Choose **Import All** once per level. A second **Import All** adds the same fields again, and **Save** then refuses with "Please fix the errors on this page". If that happens, leave the page without saving, reload it and import again.

To create the fields by hand instead, use the section name, field names, reference keys and types above. The reference keys must match exactly, because the integration finds the fields by key.

## Related

- [Jira Integration](/docs/jira-integration)
- [Open and Resolve Jira Issues from Test Results](/docs/open-and-resolve-jira-issues-from-test-results)
- [Jira Cloud Data Source Template](/docs/jira-cloud-data-source-template)
- [Jira Catalog Custom Fields](/docs/jira-catalog-custom-fields)
- [Configuring Custom Fields](/docs/config-custom-fields)