> For the complete documentation index, see [llms.txt](https://docs.zingg.ai/zingg/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zingg.ai/zingg/running-zingg/pass-through.md).

# Pass Through

Exclude specific records from matching while still including them in the Zingg output with their own Zingg ID.

{% hint style="info" icon="right-long" %}
Enterprise only. Pass Through excludes specific records from the matching process while still including them in the output. Each Pass Through record receives its own unique Zingg ID.
{% endhint %}

Not all records in your dataset should participate in matching. Some records are partially populated, corrupted, bot-generated, or have attributes that should not influence cluster formation, but they still need to appear in the output for governance, compliance, or audit purposes.

`Pass Through` lets you define a filter expression for these records. Records that meet the pass through condition are excluded from matching, linking, and incremental processes. They are\
carried through to the output unchanged, and each receives its own unique `Zingg ID`.

### When to use Pass Through

<details>

<summary><strong>Use case 1: Bot-generated records</strong></summary>

Some datasets contain records created by bots or automated processes rather than real entities. These records are identifiable by a synthetic email pattern, a placeholder name, or a specific marker field.

Including these items in the matching process inflates the sizes of the clusters and degrades the accuracy of the results. `Pass Through` lets you exclude them by defining a filter expression on the identifying field.

Example: Exclude all records where the email field contains "`@bot`." or where a marker field equals "`AUTOMATED`".

These records still appear in the output with their own `Zingg ID`s so they can be traced and audited.

</details>

<details>

<summary><strong>Use case 2: Corrupted or spam records</strong></summary>

Some records are corrupted, incomplete, or contain spam data that would produce false matches if included in the matching process. Common examples: records with all fields blank except an ID, records with placeholder values like "`TEST`" or "`NULL`", or records flagged by an upstream data quality check.

`Pass Through` lets you filter these records out of matching while keeping them in the output for auditing purposes. The audit trail shows which records were treated as `Pass Through` and why.

</details>

<details>

<summary><strong>Use case 3: Attribute exclusion</strong></summary>

Occasionally a specific attribute value should prevent a record from influencing cluster formation, even if the record itself is valid. For example, a gender field that should not factor into matching, or a record status flag that indicates the record is archived or inactive.

`Pass Through` lets you filter by any field expression. Records matching the condition are excluded from matching entirely, even if their other fields would produce a valid match.

</details>

### How to configure Pass Through

`Pass Through` is not a separate phase; it is a filter expression you set on your `args` object in [Configure Zingg](/zingg/running-zingg/configure-zingg.md), before running any phase. Records matching the expression are excluded from matching, linking, and incremental runs automatically.

{% tabs %}
{% tab title="Enterprise" %}

#### Python

Set the pass through expression on your args.

```python
args.setPassthroughExpr("fname = 'matilda'")
```

#### JSON

```json
{ "passthroughExpr" : "fname = 'matilda'" }
```

For nullable fields, ensure the negative of your expression correctly identifies non-passthrough records:

```json
{ "passthroughExpr" : "is_deceased = true AND is_deceased IS NOT NULL" }
```

Zingg internally applies the negation of `passthroughExpr` to filter which records participate in matching. If you apply the condition to a nullable field without the null guard, records with null values in that field may behave unexpectedly.
{% endtab %}

{% tab title="Enterprise Snowflake" %}

#### JSON

```json
{ "passthroughExpr" : "fname = 'matilda'" }
```

For nullable fields, ensure the negative of your expression correctly identifies non-passthrough records:

```json
{ "passthroughExpr" : "is_deceased = true AND is_deceased IS NOT NULL" }
```

Zingg internally applies the negation of `passthroughExpr` to filter which records participate in matching. If you apply the condition to a nullable field without the null guard, records with null values in that field may behave unexpectedly.
{% endtab %}
{% endtabs %}

### Pass Through records in the output

`Pass Through` records appear in the match output alongside normally matched records. The key difference:

* Normally matched records share a `Zingg ID` with other records in their cluster.
* `Pass Through` records each receiving their own unique `Zingg ID`. They are not grouped with any other record. They are traceable and auditable but do not contribute to or inherit any entity cluster.

{% hint style="success" icon="right-long" %}
**Read more**:

* Pass Through concept in the glossary - [Concepts glossary](/zingg/frequently-asked-questions/concept-glossary.md)
* Configure Zingg where Pass Through is set up - [Configure Zingg](/zingg/running-zingg/configure-zingg.md)
  {% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.zingg.ai/zingg/running-zingg/pass-through.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.