DATA OPS
Reverse-ETL Multi-Destination Coverage Check
Verifies that a single warehouse audience landed completely across multiple destinations (Salesforce, HubSpot.
How it runs
The automated pipeline, trigger to output.
- TriggerSchedule fires after multi-destination sync
- ActionRead canonical audience IDs from BigQueryBigQuery
- ActionCheck audience coverage in SalesforceSalesforce
- ActionCheck audience coverage in HubSpotHubSpot
- ActionCheck audience coverage in IntercomIntercom
- LogicMerge per-destination coverage gaps
- OutputPublish consolidated report to NotionNotion
What it does
When one warehouse audience fans out to several SaaS destinations, partial landing in any one of them quietly breaks cross-tool consistency. This workflow takes the canonical source set from BigQuery and checks coverage against each destination in turn, then produces a single consolidated report showing exactly which IDs are missing from Salesforce, HubSpot, and Intercom respectively.
When to use it
Use it when the same audience is synced to multiple destinations and they must stay aligned, for example a product-qualified-lead segment pushed to CRM, marketing, and support tools at once. It answers "is this audience whole everywhere?" in one place instead of three separate checks.
How it works
- 1A schedule fires after the multi-destination sync window.
- 2Read the canonical audience IDs from BigQuery.
- 3Check Salesforce for which audience IDs are present.
- 4Check HubSpot for the same audience IDs.
- 5Check Intercom for the same audience IDs.
- 6Merge the three coverage results into a per-destination gap report.
- 7Publish the consolidated coverage report to a Notion page.
Set it up
What you configure once, before turning it on.
- 1Connect BigQueryDatasets, queries, schemas.
- 2Connect SalesforceAccounts, opportunities, cases.
- 3Connect HubSpotCRM, deals, marketing, support.
- 4Connect IntercomConversations, contacts, articles.
- 5Connect NotionPages, databases, comments.
- 6Set each agent's modelWe leave models unset so you pick the tier — fast + cheap, or top-quality.
- 7Tune it to your dataEdit the prompts, filters, and field mappings so it matches how your team works.
- 8Test, then turn it onRun once against a sample, confirm the output, then enable the trigger.
More Data Ops workflows
Snowflake column type-drift sentinel with Linear fix ticket
Snapshots the data types of every column in your tracked Snowflake schemas on a schedule, diffs against the last snapshot.
Daily BigQuery Scheduled-Query Cost Attribution to Owners
Each morning, totals the prior day's on-demand bytes-billed per scheduled query, maps each query to its owner from a label, and posts a per-owner cost leaderboard to Slack.
BigQuery dropped/renamed column sentinel with PagerDuty incident
Detects when a column is dropped or renamed in your governed BigQuery datasets and, because that breaks downstream queries hard, pages the on-call via PagerDuty and posts…
PR-time Snowflake schema contract check on dbt model changes
When a pull request changes a dbt model, it compares the model's declared output columns against the live Snowflake table it will replace and blocks the merge with a GitHub check…
Agent-triaged warehouse drift with impact analysis and runbook update
On a webhook from your warehouse audit log, an agent investigates the changed column, traces which downstream models and dashboards depend on it.
Cross-warehouse replication schema mismatch reconciler
Compares the column shape of mirrored tables between BigQuery and Snowflake and, when a replicated table has drifted out of sync between the two, opens an Asana task for the data…
Run it inside a business
This workflow drops into a full company template. Import the org, and this is one of the playbooks its agents run.
Run this workflow in your colony.
14-day trial. No DevOps. No Sales call. Provisioned in under a minute.