Overview
The Resonate On-demand Clean Room is a Snowflake Native Application that enables secure, privacy-compliant data enrichment directly within your organization's own Snowflake environment. It allows agencies and brands to enrich first-party customer data with Resonate's proprietary behavioral, demographic, and psychographic attributes — without transferring files, waiting days for delivery, or exposing sensitive data to either party.
Resonate acts as the data provider. You, as the client, act as the consumer. The clean room architecture ensures:
- Your customer IDs and raw data are never seen by Resonate
- Resonate's full attribute dataset is never exposed to you
- Enrichment results are delivered directly into your Snowflake environment (no matter which environment you use) within hours
This guide covers everything your engineering team needs to get started: prerequisites, environment setup, job invocation, output schema, and error handling. If you are an existing Resonate Append customer, see Section 7 for a dedicated transition guide.
Note: This guide is written for engineering and implementation teams. For business context on use cases and value, see your Resonate Customer Success contact.
Why Use the On-demand Clean Room
The clean room solution is designed for agencies and brands that need a faster, more secure, and operationally simpler alternative to traditional file-based data append. Key advantages include:
Speed
- Enrichment jobs complete in hours, not days.
- On a large enough warehouse, such as a 4x-large, even an input size of nearly 100 million records completes in less than 30 minutes.
Privacy & Security
- Customer IDs remain in your Snowflake environment — Resonate never sees them
- Resonate's underlying dataset is never exposed to the consumer
- HEM, MAID, and IP are accepted as inputs (email addresses must be hashed)
- Sensitive attributes are automatically redacted as required by law
Operational Simplicity
- No file transfers, no SFTP setup, no manual handoffs
- Enrichment runs on-demand via SQL — on any cadence you choose
- Results are delivered as Snowflake tables inside your installed native app for immediate use
- Compatible with all Snowflake cloud provider/US region combinations
Common Use Cases
- Enrich a CRM or CDP customer list for audience segmentation
- Identify high-value targets for multi-channel campaign planning
- Blend enriched attributes with internal data sources for analytics
- Feed enriched segments into activation platforms (e.g., Ignite)
Prerequisites
Before getting started, confirm the following requirements are met on your Snowflake account:
| Requirement | Detail |
|---|---|
| Active Snowflake account | Any supported cloud provider and US region combination is supported. |
| Installation permissions | Your account must have permissions to accept a private Snowflake invite or install Marketplace listings. |
| Active compute warehouse | A running virtual warehouse is required to execute enrichment jobs. An x-large or greater warehouse is recommended for most job sizes. |
| Hashed identifier data | Your input table must contain at least one supported ID type: HEM (SHA-256, SHA-1, or MD5), MAID (IDFA/GAID), or IPv4 address. |
Important: Unhashed or plaintext PII (e.g., raw email addresses, names) cannot be submitted as input. The input validation will fail if enough unhashed PII is detected such that the percentage of valid IDs falls below threshold. The append job will not match such identifiers.
Onboarding & Access
Access to the Resonate On-demand Clean Room is provisioned by Resonate — it is not self-serve through Snowflake Marketplace at this point in time.
Step 1: Receive Your Invite
Resonate will send a direct invite to your Snowflake account. Once you accept the invite, the Resonate enrichment application will become visible in your environment. You will receive confirmation instructions from your Resonate Customer Success contact.
Step 2: Validate Your Environment
Resonate will provide a QuickStart guide Resonate Snowflake Clean Room Enrichment Setup Guide containing SQL snippets to validate your environment. Run the provided SQL to confirm:
- Your account has the required roles and permissions
- Your compute warehouse is configured and active
- End-to-end connectivity to the enrichment service is working
If required roles or permissions are missing, Snowflake will return standard SQL error messages. Refer to the QuickStart documentation to resolve them.
Step 3: Role Provisioning
An administrator in your Snowflake account must ensure your user role has the following privileges that are required to use the enrichment application.
- You must be able to grant the app read access to the database, schema, and table where your input data lives. To act on each of those three objects you must fulfill one of the following:
- Be ACCOUNTADMIN
- Have OWNERSHIP of the object
- Have the same privilege you are trying to grant to the app (USAGE on database/schema, SELECT on table) and have been delegated authority "WITH GRANT OPTION" for the privilege
- You must be able to call the procedures provided by the application, which are exposed to the consumer through the application role "app_user". This requires you to fulfill all of the following:
- Have OWNERSHIP or USAGE on the application (automatic if you are the one who installed the application)
- app_user has been granted to you (automatic if you are the one who installed the application)
- Have USAGE on the warehouse you wish to use
Input Requirements
Enrichment is invoked by calling a stored procedure or SQL command against an input table in your Snowflake environment. Your input table must conform to the following requirements.
Supported Identifier Types
The enrichment service accepts the following identifier types. At least one must be present in your input table:
| ID Type | Accepted Formats | Notes |
|---|---|---|
| HEM (Hashed Email) | SHA-256, SHA-1, MD5 | Only one HEM type is allowed per input file. |
| MAID | IDFA (iOS), GAID (Android) | |
| IPv4 Address | Standard IPv4 format | IPv6 is not supported. |
Example File Formatting for Snowflake Input Column Headers:
Waterfall Matching Logic
When multiple identifier types are present in your input table, the enrichment service applies waterfall matching in the following priority order:
- HEM (highest priority)
- MAID
- IP address (lowest priority / fallback)
If a record matches on HEM, Resonate will not attempt MAID or IP matching for that record. If HEM does not yield a match, the service falls back to MAID, then IP. The MATCHED_ID_TYPE field in your output will indicate which identifier was used for each customer record.
Running an Enrichment Job
All tables created by the application go into the schema INST.
All procedures defined by the application live in the schema CORE.
Here is an example of how to use the application. At the top right the selected database is the name you gave to the clean room application at the time of installation.
- Before you call any procedures, grant the application access to your input table, which requires USAGE on the database and schema and SELECT on the table.
- If this is your first time using the application, call
core.health_checkto see if the application can reach the necessary tables at Resonate. If the status says healthy, then you are good to proceed. Otherwise, take note of which tables are reported as not accessible, and inform your contact at Resonate. - Call
core.run_validation(your input table)to determine if it is healthy enough for enrichment. This run will produce a row_level_validation table for your input, which assesses each of your rows for validity, and add one row to the validation_summary table, which assigns a pass/fail status to your input and provides the metrics that explain the decision. If passed, proceed to run the enrichment. Otherwise, try to fix the problems highlighted by the metrics, and contact Resonate if you need assistance or if you believe your input is actually valid and was incorrectly flagged as failed. - Call
core.run_append(your input table)to perform the enrichment. This in turn internally callscore.enrich_ids(your input table),core.generate_key_definitions(enriched output table), andcore.generate_summary(enriched output table)to produce the three deliverable tables described within this document: enriched_ids, key_definitions, and summary. These are suffixed with both your input table name and the current timestamp, so that rerunning the same input will produce a new set of tables. You could call any of those three procedures independently, such as after a transient resource failure where the enrichment already succeeded but the supplementary tables had not been created yet, but in general you only need to call run_append. - If you wish to drop any tables from the application, you can call
drop_tablefor a single table,drop_prefix/drop_suffixfor all tables with a given prefix/suffix, ordrop_all_outputfor a complete wipeout. Ignore the procedure _override_dataset_view, as that is internally used by Resonate during tests.
Job Status & Visibility
There is no separate job status UI in Phase 1. Use Snowflake's built-in tools to monitor enrichment jobs:
- Snowflake Query History — view whether your job is running, complete, or errored
- Snowflake Task Logs — review execution details
- If a job fails, error details will appear in the SQL error output
Output Schema
When enrichment completes, three tables are placed directly into your Snowflake environment within the application:
- Append Output Table — enriched results for matched records
- Key Definitions File — maps survey_value_keys to human-readable attribute names and descriptions
- Summary Table — fill rate, sensitive attribute flag
Append Output Table Schema
The output uses a rectangular (narrow and tall) format optimized for Snowflake. Each row represents one customer-attribute combination.
| Column Name | Type | Nullable | Description |
|---|---|---|---|
| CUSTOMER_ID | String | No | Your internal customer identifier (matches input table). Resonate never sees this value. |
| MATCHED_ID_TYPE | String | No | The identifier type that successfully matched in the waterfall. Values: hem, maid, ip. |
| SURVEY_VALUE_KEY | String | No | The Resonate survey_value_key for this attribute. Join to the KEY_DEFINITIONS table using this field to get attribute names and metadata. |
| PREDICTION | Boolean | Yes | TRUE if the customer has this attribute, or NULL if the prediction was redacted due to sensitive data requirements. |
Sample Output Data
| CUSTOMER_ID | MATCHED_ID_TYPE | SURVEY_VALUE_KEY | PREDICTION |
|---|---|---|---|
| CUST_001 | hem | 12345 | TRUE |
| CUST_001 | hem | 12346 | NULL |
| CUST_001 | hem | 99999 | NULL |
| CUST_002 | hem | 12345 | TRUE |
| CUST_003 | maid | 12345 | TRUE |
| CUST_004 | ip | 12345 | TRUE |
Key Observations About the Output Format
- Each row represents a single customer-attribute combination — an unrestricted customer with 500 attributes will have 500 rows
- MATCHED_ID_TYPE shows which identifier was used for the waterfall match — useful for understanding match quality
- NULL in PREDICTION indicates a sensitive attribute that was legally redacted for a restricted customer — it does not mean no data was found
- For a restricted customer, every sensitive attribute that you purchased will appear in the output with a NULL prediction, while nonsensitive attributes appear if TRUE as usual
- CUSTOMER_ID enables you to join enrichment results back to your source data
- SURVEY_VALUE_KEY joins to the KEY_DEFINITIONS table to retrieve attribute names and descriptions
Joining to Key Definitions
To get human-readable attribute names alongside your enriched data, join the output table to the KEY_DEFINITIONS table:
SELECT o.CUSTOMER_ID, o.MATCHED_ID_TYPE, o.PREDICTION,
k.ATTRIBUTE_NAME, k.ATTRIBUTE_VALUE_NAME
FROM YOUR_OUTPUT_TABLE o
JOIN KEY_DEFINITIONS k
ON o.SURVEY_VALUE_KEY = k.SURVEY_VALUE_KEY;Summary Table
Alongside the append output, every job produces a summary table containing for every attribute:
- The number of customers that have the attribute
- The above count as a percentage of matched customers
- Whether or not the attribute is sensitive data
Error Handling
Every consumer-facing procedure (core.run_validation, core.run_append) returns a structured JSON response — not a raw Snowflake error. Always inspect the response's status, message, and hint fields to understand what happened and what to do next.
Response Shape
On success, run_append returns:
{
"status": "OK",
"enriched_table": "resonate_cleanroom_enrichment_app.inst.enriched_ids_abc123",
"key_definitions_table": "resonate_cleanroom_enrichment_app.inst.key_definitions_abc123",
"summary_table": "resonate_cleanroom_enrichment_app.inst.summary_abc123"
}On failure, run_append returns:
{
"status": "ERROR",
"message": "Enrichment failed: Input table row count (250000000) exceeded the maximum allowed (200,000,000).",
"enriched_table": null,
"key_definitions_table": null,
"summary_table": null,
"errors": {
"enrichment": "Input table row count (250000000) exceeded the maximum allowed (200,000,000).",
"key_definitions": null,
"summary": null
},
"hint": "Reduce the input table to 200,000,000 rows or fewer and retry."
}run_validation returns the same basic shape (status, message, hint) plus row_level_validation_table on success.
If you're calling from a SnowSQL or Snowsight worksheet, the full JSON appears as a single cell in the results grid — click into the cell to expand it, or use TRY_PARSE_JSON(result):status::STRING to extract individual fields.
How to Read a Failure
-
status—"OK"means the job completed fully."ERROR"means at least one step failed. Forrun_append, the three*_tablefields indicate which outputs were still produced before the failure; any non-null value is a real table you can still query. -
message— a human-readable summary. For validation-time failures the message is specific. For failures deep inside the pipeline, the message is intentionally generic to avoid exposing internal implementation details. The detailed Snowflake error is captured in Resonate's event table for support. -
hint— suggested next step. Depending on the failure it may contain ready-to-paste SQL or aninvocation_id/job_id. When contacting Resonate support about a failure, always include the ID from thehint. -
errors(present onrun_appendfailures only) — breaks out per-step error text. Useful for distinguishing between a full failure and a partial failure where enrichment succeeded but the key-definitions or summary table could not be produced.
Common Error Conditions
| Error condition | What you'll see | What to do |
|---|---|---|
| The app can't read your input table (missing grants) |
status = "ERROR", message starts with "Cannot access table …", hint contains three ready-to-paste GRANT statements |
Run the three GRANT statements from the hint as a role with authority to grant them; then retry. |
| The input table is missing the required CUSTOMER_ID column |
status = "ERROR", message says "Table … is missing the required CUSTOMER_ID column." |
Add a CUSTOMER_ID column; then retry. |
| The input table exceeds 200,000,000 rows |
status = "ERROR", message quotes both the actual row count and the 200M limit |
Reduce the input to 200M rows or fewer, then retry. |
| Validation completes but the file is below the quality threshold | run_validation returns status = "OK", but summary table shows file_status = "REJECTED" | Query the row-level validation table to see which rows are invalid, clean the data, and rerun. |
| run_append produced the enriched table but couldn't build key definitions or summary |
status = "ERROR", enriched_table non-null, hint contains an invocation_id |
The enriched output is valid. Retry run_append. If failure recurs, contact support with the invocation_id. |
| run_append fails with a generic "Enrichment failed unexpectedly" |
status = "ERROR", no specific reason in message, hint contains an invocation_id |
Confirm the input table exists, is accessible, and contains valid data; then retry. If it still fails, contact support with the invocation_id. |
| The CALL itself errors before any JSON is returned | Raw Snowflake error such as "Insufficient privileges to operate on PROCEDURE" | Your calling role needs USAGE on the application, the app_user application role, and USAGE on a warehouse. See Step 3: Role Provisioning. |
| Output contains NULL values in the PREDICTION column | This is not an error | NULL predictions are sensitive attributes redacted for compliance on restricted records. |
Where Error Detail Is Recorded
- Structured JSON response (primary surface) — returned by every procedure call.
- App event table (secondary surface, for Resonate support) — every call emits telemetry keyed by invocation_id or job_id. Support uses this to diagnose failures where the consumer-facing message is intentionally generic.
- Snowflake Query History — useful for confirming the CALL executed, how long it took, and which warehouse ran it. It does not contain the procedure's structured JSON response body.
Contacting Support
If the hint doesn't resolve the issue, email customersupport@resonate.com with:
- Your client ID
- The procedure you called and the input table you passed
- The full JSON response returned by the procedure — in particular the status, message, hint, and any invocation_id or job_id
- The approximate time you ran the call
The invocation_id / job_id is the single most useful piece of information — it lets support locate the raw error log for your specific run instantly.
Privacy & Compliance
The On-demand Clean Room is architected to enforce privacy for both Resonate and the client:
- Only hashed email addresses are accepted as input — unhashed PII will not pass validation
- Resonate never sees your CUSTOMER_IDs or the contents of your input table
- You never see Resonate's full underlying dataset — only attributes for records that matched your inputs
- Sensitive attributes are automatically redacted and appear as NULL in outputs
Compute Costs
Enrichment jobs run on your Snowflake compute warehouse and are billed by Snowflake directly — not by Resonate. These are standard Snowflake virtual warehouse credits billed per second of usage.
For example, an enrichment job on 16K records using a 3x-large warehouse ran for about 3 minutes and consumed 3.09 credits, which costs $6.18 for a standard account. If your organization has pre-purchased Snowflake capacity, these jobs draw from your existing committed spend, which may effectively reduce marginal cost to near zero.
For questions about Snowflake billing, work with your Snowflake account team to understand current credit burn and available capacity.
Guide for Existing Resonate Append Customers
If you are currently using Resonate's file-based Data Append service, this section explains your options, what changes between the two products, and what — if anything — you need to do.
Key Point: No action is required if you want to continue using your current Resonate Append setup. The clean room is a separate, opt-in offering. Your existing file-based Append workflow will not be affected.
Option A: Adopt the Clean Room Instead of File-Based Append
You may choose to migrate fully from file-based Append to clean room delivery. This means Resonate will no longer deliver enrichment files to your Box, SFTP, or AWS location — instead, results will be written directly into your Snowflake environment.
Benefits of migrating:
- Results in hours instead of weeks
- No file transfer or ingestion pipeline to maintain
- Run enrichment on any cadence — not limited to monthly batches
- Simpler data governance with no files leaving Snowflake
To migrate, work with your Resonate Customer Success contact to initiate onboarding and confirm your Snowflake environment prerequisites (see Section 3).
Option B: Add the Clean Room Alongside File-Based Append
You may also choose to use both delivery methods. For example, you might continue receiving monthly file-based Append for archival purposes while also using the clean room for on-demand, real-time enrichment runs during campaign planning.
Contact your Resonate Customer Success contact to discuss how to configure this arrangement.
What Changes If You Use the Clean Room
The following is a summary of the key differences between file-based Append and the clean room offering that your engineering team should be aware of:
| Area | File-Based Append | Clean Room |
|---|---|---|
| Delivery method | Files delivered to Box, SFTP, or AWS | Results written directly to your Snowflake tables |
| Turnaround time | Days | Minutes or hours |
| Delivery cadence | Monthly (by default) | On-demand — any cadence you choose |
| Output schema | Pivoted format (wide) | Rectangular format (narrow and tall) — see Section 6 |
| Key Definitions File | Delivered as a separate file | Available as a Snowflake table to JOIN directly |
| Summary Report | Delivered as a separate file | Available as a Snowflake table alongside output |
| Supported ID types | HEM, MAID, IP, Zip11, Name/Address | HEM, MAID, IP |
| Data stays in your environment? | No — input files sent to Resonate | Yes — Resonate never sees your data |
Output Schema Changes
The most significant technical change for existing Append customers is the output format. The clean room uses a rectangular (narrow and tall) schema rather than the pivoted (wide) format used in file-based Append.
Why the new format:
- The pivoted format used by file-based Append is not Snowflake-friendly for large attribute sets
- The rectangular format is optimized for Snowflake querying and scales efficiently regardless of attribute count
- Joining to the KEY_DEFINITIONS table is simpler — join on SURVEY_VALUE_KEY rather than unpivoting column names
- CUSTOMER_ID in every row makes it straightforward to join back to your source data
If you have downstream pipelines or reporting built on the Append output schema, those will need to be updated to consume the new rectangular format before switching to clean room delivery. The Key Definitions Table remains unchanged, while the Summary Table provides the information described in the "Summary Table" section.
The Clean Room Output Format:
Standard Output File Format for Append File Transfer:
Pivoted Output File Format:
Address Match Limitation
The current clean room offering does not support name/address-based matching. If your Append use cases depend on address match (using Resonate's Smarty-driven matching), file-based Append remains the appropriate solution for those records. You can continue using file-based Append for address-matched records while using the clean room for HEM, MAID, and IP matching.
Prerequisites for Existing Append Customers
If you are an existing Append customer adopting the clean room, confirm:
- You have an active Snowflake account (any cloud provider/US region combination is supported)
- You have permissions to accept a Snowflake invite and run enrichment jobs
- You have reviewed and updated any downstream pipelines that consume the Append output to support the new rectangular schema
Input Table Formatting Guidelines
Before invoking an enrichment job, your input data must be loaded into a Snowflake table in your own environment. This section describes the required table structure, column specifications, data formatting rules, and validation checks your engineering team should perform before submitting a job.
Note: Resonate never sees your raw input table; only the installed application reads it. Formatting your table correctly is required for the enrichment procedure to execute successfully.
Required Input Table Structure
Your input table must contain a CUSTOMER_ID column and at least one supported identifier column. Additional identifier columns are optional but recommended to maximize match rates through waterfall matching.
| Column Name | Type | Required | Description |
|---|---|---|---|
| CUSTOMER_ID | VARCHAR | Yes | Your internal customer identifier. Used to join enrichment output back to your source data. Resonate never sees this value. Must be unique per row. |
| HEM | VARCHAR | No* | Hashed email address |
| HEM_TYPE | VARCHAR | No* | The type of hash used (HEMSHA256, HEMSHA1, or HEMMD5) |
| MAID | VARCHAR | No* | Mobile Advertising ID. Accepted formats: IDFA (iOS) or GAID (Android). Should be lowercase and formatted as a standard UUID string. |
| IP_ADDRESS | VARCHAR | No* | IPv4 address in standard dotted-decimal notation (e.g., 192.168.1.1). IPv6 addresses are not accepted. |
*At least one identifier column (HEM, MAID, or IP_ADDRESS) is required. Including multiple identifier types is strongly recommended to maximize match coverage through waterfall matching.
Column Formatting Rules by Identifier Type
HEM (Hashed Email Address)
- Accepted hash algorithms: SHA-256, SHA-1, MD5
- Hash values must be lowercase hexadecimal strings
- SHA-256 produces 64-character strings; SHA-1 produces 40-character strings; MD5 produces 32-character strings
- Email addresses must be normalized before hashing: lowercase, trimmed of whitespace
- NULL values in the HEM column are permitted — the waterfall will fall through to the next identifier
Example valid HEM values (MD5):
d8578edf8458ce06fbc5bb76a58c5ca4
5d41402abc4b2a76b9719d911017c592MAID (Mobile Advertising ID)
- Accepted formats: IDFA (Apple iOS) and GAID (Google Android)
- Must be formatted as a standard UUID string: 8-4-4-4-12 character groups separated by hyphens
- Values should be lowercase
- Do not include braces, spaces, or other non-standard characters
- NULL values are permitted — the waterfall will fall through to the next identifier
Example valid MAID value:
3b4c1a2d-5e6f-7890-abcd-ef1234567890IP_ADDRESS (IPv4)
- Standard dotted-decimal IPv4 notation only (e.g., 203.0.113.45)
- IPv6 addresses are not accepted and will not match anything
- Only residential IPs will return enrichment results — commercial and non-residential IPs will not match
- IPs originating outside the US will not return results
- Must be a valid public IP address — private/internal IP ranges (e.g., 192.168.x.x, 10.x.x.x) will not match
- NULL values are permitted — records with no matching IP will simply not match on this fallback
Example valid IPv4 values:
203.0.113.45
198.51.100.22General Table Requirements
- All columns must be VARCHAR / STRING type — do not use integer, float, or other data types for identifier columns
- One row per customer — CUSTOMER_ID must be unique within the input table
- Empty string values ('') should be converted to NULL before submitting — empty strings may cause unexpected behavior
- Column names must match exactly as specified above — the enrichment procedure references columns by name
- Column names are case-insensitive in Snowflake, but using the exact casing shown is recommended for clarity
- There is no maximum column count — additional columns beyond the required set will be ignored by the enrichment procedure
Null Handling & Partial Records
Records with NULLs in one or more identifier columns are fully supported. The waterfall matching logic will attempt each non-NULL identifier in priority order:
- A record with only a MAID (no HEM) will skip HEM matching and proceed directly to MAID matching
- A record with only an IP address will skip HEM, MAID matching and attempt IP matching only
- A record with no valid identifiers in any column will not match and will not appear in the output
There is no penalty for NULL identifiers — they simply reduce the available fallback options for that record.
Pre-Submission Validation Checklist
Before invoking an enrichment job, run these checks against your input table:
| Check | How to Validate in Snowflake |
|---|---|
| CUSTOMER_ID is unique with no NULLs | SELECT COUNT(*) vs. COUNT(DISTINCT CUSTOMER_ID) — they should match. Also check COUNT(*) WHERE CUSTOMER_ID IS NULL = 0. |
| No unhashed email addresses in HEM column | Scan for values containing '@' |
| No IPv6 addresses in IP_ADDRESS column | Check for values containing ':' |
| MAID values are valid UUID format | Check LENGTH(MAID) = 36 |
| At least one identifier column is non-NULL per row | Flag any rows where HEM IS NULL AND MAID IS NULL AND IP_ADDRESS IS NULL — these records will not match. |
Support
For implementation assistance, onboarding questions, or attribute mapping help, contact Resonate support:
Email: customersupport@resonate.com
When contacting support, include: your client ID (provided by Resonate), a description of the issue, and any relevant Snowflake error codes or job IDs.
Appendix: Quick Reference
Supported ID Types at a Glance
| ID Type | Waterfall Priority | Accepted Formats | MATCHED_ID_TYPE Value in Output |
|---|---|---|---|
| HEM | 1 (highest) | SHA-256, SHA-1, MD5 | hem |
| MAID | 2 | IDFA, GAID | maid |
| IPv4 | 3 (lowest) | Standard IPv4 | ip |
Output PREDICTION Field Values
| Value | Meaning |
|---|---|
| TRUE | Resonate predicts this attribute applies to this customer |
| NULL | Attribute was redacted for compliance — does not indicate a missing match |
Onboarding Checklist
- Confirm you have an active Snowflake account
- Confirm you have permissions to accept invites and install apps
- Confirm you have an active compute warehouse
- Prepare your input table with at least one supported ID type
- Accept the Snowflake invite from Resonate
- Run the health check and input table validation to confirm readiness
- Invoke your first enrichment job
- Validate output by joining to KEY_DEFINITIONS
Comments
0 comments
Please sign in to leave a comment.