Contains Email Check Examples
Three real-world scenarios that show how the Contains Email check is typically used in production: validating a customer contact column, checking a notification recipient list with a filter, and auditing a legacy column mid-cleanup. The first two run at 100% coverage and report Record Anomalies; the third lowers coverage and reports a Shape Anomaly instead.
The situation: The customers table stores the address used for transactional mail in contact_email. Rows where the column holds a phone number, a placeholder, or a note instead of an address silently break every downstream notification.
Check configuration
| Field | Value |
|---|---|
| Rule | Contains Email |
| Field | contact_email |
| Filter | (none) |
| Custom Anomaly Description | Off |
| Coverage | 100% |
| Owner | (check creator) |
| Anomaly Assignee | (CRM Data team) |
| Description | Customer contact email must hold an email address. |
| Tags | contact, format |
| Additional Metadata | jira: DATA-7001 |
| Status | Active |
Payload
{
"description": "Customer contact email must hold an email address.",
"rule": "containsEmail",
"fields": ["contact_email"],
"container_id": 145,
"coverage": 1,
"filter": null,
"properties": {},
"tags": ["contact", "format"],
"additional_metadata": {"jira": "DATA-7001"},
"anomaly_message_field": null,
"template_id": null,
"status": "Active",
"owner_id": 7,
"default_anomaly_assignee_id": 12
}
Sample Data
| customer_id | contact_email | country |
|---|---|---|
| C-001 | ana@example.com | BR |
| C-002 | +55 11 99999-0000 | BR |
| C-003 | support@example.org | PT |
| C-004 | (null) | ES |
What gets flagged
Customer C-002 has a phone number where the address should be. C-004 is NULL and passes without firing an anomaly. Coverage is 100%, so the failing row is reported as a Record Anomaly.
Record Anomaly
The field 'contact_email' has value '+55 11 99999-0000', which does not contain an email address
Flowchart
graph TD
A["No filter, evaluate all rows"] --> B["Read contact_email as text"]
B --> C{"Is value NULL?"}
C -->|Yes| D["Row passes"]
C -->|No| E{"Does it contain<br/>an email address?"}
E -->|Yes| D
E -->|No| F["Flag row.<br/>Record Anomaly per failing row."]
Equivalent SQL
The situation: The notification_targets table holds one row per delivery channel. Only rows on the email channel must carry an address in target; rows for SMS or push hold phone numbers and device tokens and are out of scope.
Check configuration
| Field | Value |
|---|---|
| Rule | Contains Email |
| Field | target |
| Filter | channel = 'email' |
| Custom Anomaly Description | Off |
| Coverage | 100% |
| Owner | (check creator) |
| Anomaly Assignee | (Messaging Platform) |
| Description | Email-channel targets must hold an email address. |
| Tags | messaging, format |
| Additional Metadata | jira: DATA-7042 |
| Status | Active |
Payload
{
"description": "Email-channel targets must hold an email address.",
"rule": "containsEmail",
"fields": ["target"],
"container_id": 512,
"coverage": 1,
"filter": "channel = 'email'",
"properties": {},
"tags": ["messaging", "format"],
"additional_metadata": {"jira": "DATA-7042"},
"anomaly_message_field": null,
"template_id": null,
"status": "Active",
"owner_id": 7,
"default_anomaly_assignee_id": 29
}
Sample Data (filtered to channel = 'email')
| target_id | channel | target |
|---|---|---|
| T-501 | ops@example.com | |
| T-502 | unknown | |
| T-503 | billing@example.com |
Why the filter matters
The filter runs before the evaluation, so SMS and push targets are never tested for an email address. Only email-channel rows are evaluated.
What gets flagged
T-502 holds the placeholder unknown, which contains no address, so it is the only row reported. Coverage is 100%, so the failure is reported as a Record Anomaly, and the message ends with the filter that scoped the evaluation.
Record Anomaly
The field 'target' has value 'unknown', which does not contain an email address [filter: channel = 'email']
Flowchart
graph TD
A["Apply filter: channel = 'email'"] --> B["Read target as text"]
B --> C{"Does it contain<br/>an email address?"}
C -->|Yes| D["Row passes"]
C -->|No| E["Flag row.<br/>Anomaly message ends with<br/>[filter: channel = 'email']"]
Equivalent SQL
The situation: A legacy user_contact column mixes addresses with old free-text notes. A cleanup job is rewriting the bad rows, and a small fraction is expected to remain broken until it finishes, so the check tolerates up to 0.5% failures.
Check configuration
| Field | Value |
|---|---|
| Rule | Contains Email |
| Field | user_contact |
| Filter | (none) |
| Custom Anomaly Description | Off |
| Coverage | 99.5% |
| Owner | (check creator) |
| Anomaly Assignee | (Legacy Migration team) |
| Description | Legacy contact column must hold an email address. |
| Tags | legacy, format |
| Additional Metadata | jira: DATA-7108 |
| Status | Active |
Payload
{
"description": "Legacy contact column must hold an email address.",
"rule": "containsEmail",
"fields": ["user_contact"],
"container_id": 733,
"coverage": 0.995,
"filter": null,
"properties": {},
"tags": ["legacy", "format"],
"additional_metadata": {"jira": "DATA-7108"},
"anomaly_message_field": null,
"template_id": null,
"status": "Active",
"owner_id": 7,
"default_anomaly_assignee_id": 41
}
Sample Data
| user_id | user_contact | migrated |
|---|---|---|
| U-01 | maria@example.com | true |
| U-02 | call the office | false |
| U-03 | n/a | false |
| U-04 | (null) | false |
What gets flagged
Users U-02 and U-03 still hold free-text notes. U-04 is NULL, so it passes without firing an anomaly but still counts in the scanned total. Only 50% of the rows pass, which is below the 99.5% coverage threshold, so the check reports a single Shape Anomaly for the dataset with a sample of the offending rows. Coverage below 100% does not produce Record Anomalies.
Shape Anomaly
For the field 'user_contact', 50.000% of 4 records (2) do not contain email addresses
Flowchart
graph TD
A["No filter, evaluate all rows"] --> B["Read user_contact as text"]
B --> C{"Is value NULL?"}
C -->|Yes| D["Row passes"]
C -->|No| E{"Does it contain<br/>an email address?"}
E -->|Yes| D
E -->|No| F["Flag row.<br/>Passing rate falls below the 99.5%<br/>coverage, so one Shape Anomaly is reported."]
Equivalent SQL
See Also
-
How It Works
The complete reference: definition, field scope, pattern matching, NULL handling, arrays, filter behavior, and coverage.
-
Anomaly Reporting
The anomaly messages the check produces, what the numbers mean, Source Records highlighting, and Custom Anomaly Description.
-
Best Practices
Guidelines for scoping the check, pairing rules, and keeping the signal clean.
-
Permissions
The team permission each action needs: view, create, edit, archive, restore, and delete.