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

# Coalesce Quality options for dbt

> Customize how dbt resources appear in Coalesce Quality using meta configuration

<Note>
  This guide explains how to use dbt's `meta` configuration to customize how your dbt resources are displayed and categorized in Coalesce Quality.

  **Prerequisites:**

  * A working dbt Core or dbt Cloud integration with Coalesce Quality
  * Familiarity with dbt's [meta configuration](https://docs.getdbt.com/reference/resource-configs/meta)
</Note>

# Overview

Coalesce Quality reads custom metadata from your dbt project's `meta` configuration to enhance how resources are displayed and organized. By adding specific options to your dbt models and tests, you can:

* Categorize tests into specific Check categories
* Improve organization and filtering in the Coalesce Quality interface

# Check category

Use the `check_category` option to assign a dbt test to a specific Check category in Coalesce Quality. This is useful for organizing standalone dbt tests (generic or singular) into meaningful groups.

## Configuration

Add the `synq` configuration to your test's `meta` block:

```sql theme={null}
{{ config(
    meta = {
        'synq': {'check_category': 'e2e'}
    }
)
}}
```

## Example: Singular test

For a singular test file (e.g., `tests/e2e_order_flow.sql`):

```sql theme={null}
{{ config(
    meta = {
        'synq': {'check_category': 'e2e'}
    }
)
}}

-- Test that verifies the complete order flow from creation to fulfillment
SELECT order_id
FROM {{ ref('orders') }}
WHERE status = 'created'
  AND created_at < CURRENT_TIMESTAMP - INTERVAL '24 hours'
  AND fulfilled_at IS NULL
```

## Example: Generic test in schema.yml

For generic tests defined in your schema files:

```yaml theme={null}
models:
  - name: orders
    columns:
      - name: order_id
        tests:
          - unique:
              meta:
                synq:
                  check_category: 'data-quality'
          - not_null:
              meta:
                synq:
                  check_category: 'data-quality'
```

## Example: Custom generic test

For custom generic tests, add the config at the top of the test file:

```sql theme={null}
{% test custom_validation(model, column_name) %}

{{ config(
    meta = {
        'synq': {'check_category': 'validation'}
    }
)
}}

SELECT {{ column_name }}
FROM {{ model }}
WHERE {{ column_name }} IS NOT NULL
  AND NOT {{ column_name }} REGEXP '^[A-Z]{2}[0-9]{6}$'

{% endtest %}
```

# How it works

Coalesce Quality automatically categorizes dbt tests based on the test type and package (e.g., `dbt`, `dbt_expectations`, `dbt_utils`). However, for singular tests or custom generic tests, it may not be able to determine the appropriate category automatically.

Using `check_category` allows you to:

* Override the automatic categorization for any test
* Assign meaningful categories to singular tests that would otherwise be uncategorized
* Group related tests together for better filtering and analysis in Coalesce Quality

# Custom categories

You can use any category name that makes sense for your organization. Common examples:

| Category         | Description                                            |
| ---------------- | ------------------------------------------------------ |
| `e2e`            | End-to-end tests that validate complete workflows      |
| `data-quality`   | Tests for data completeness, accuracy, and consistency |
| `business-rules` | Tests that enforce business logic and constraints      |
| `reconciliation` | Tests that compare data across sources                 |
| `validation`     | Input validation and format checks                     |
| `sla`            | Service level agreement compliance tests               |

# Default categories

Coalesce Quality automatically assigns the following categories to known test types from `dbt`, `dbt_expectations`, `dbt_utils`, and other packages:

| Category           | Description                                          |
| ------------------ | ---------------------------------------------------- |
| `accepted_values`  | Tests that validate values are within an allowed set |
| `nullness`         | Tests for null or not-null constraints               |
| `unique`           | Uniqueness validation tests                          |
| `relationships`    | Referential integrity and foreign key tests          |
| `freshness`        | Data timeliness and recency tests                    |
| `row_count`        | Row count validation and volume tests                |
| `range_validation` | Tests that check values are within expected ranges   |
| `comparison`       | Tests comparing values between columns or tables     |
| `structure`        | Schema structure and column existence tests          |
| `match_regex`      | Pattern matching and regex validation tests          |

Setting `check_category` will override the default categorization for any test.

# Best practices

1. **Use custom categories** to group tests by business domain or testing strategy
2. **Be consistent** with category names across your project
3. **Document your categories** so team members understand what each category represents