Skip to main content
Export your referral intelligence to a table in your own Snowflake account. After every enrichment job, Clustr re-sends your workspace’s opportunities to the table (up to 50,000 rows) with an upsert, keeping your warehouse and BI tools current. It is a data export, not an OAuth app. You connect with key-pair auth: Clustr generates the key, you run one line in Snowflake, and Clustr only ever writes to the one table it manages.
Connecting Snowflake is admin-only, under Integrations, Apps, Snowflake in the dashboard.

​
Connect Snowflake

Have your Snowsight URL and a Snowflake username ready, then run the four-step wizard.
1

Enter your account and user

Open Snowsight and copy the address from your browser, for example app.snowflake.com/tsyqtjr/kt32003. Paste it into Clustr, enter the username Clustr should sign in as, and click Continue. A dedicated service user is recommended.
2

Authorize with a key pair

Clustr generates a key pair and shows one statement. Run it once in a Snowflake worksheet as an admin:
Click I’ve run it. Clustr keeps the private key. Only the public key is shared.
New Snowflake accounts block password sign-in for drivers, so Clustr uses key-pair auth. No password is ever stored.
3

Pick your destination

Choose a warehouse and database from the dropdowns, then pick an existing schema or create a new one (defaults to EXPORTS). Click Continue.
4

Connect and sync

Review the destination and click Connect to save the connection and run the first full export. Clustr writes to <database>.<schema>.clustr_referral_paths.
After the initial sync, Clustr runs a sync at the end of every enrichment job. Each sync re-sends the opportunities (up to 50,000 rows) rather than only the ones that changed, and a sync already running is not started twice.

​
How It Works

Clustr writes a single table, <schema>.clustr_referral_paths, one flat, denormalized row per opportunity. Rows are upserted on id with a MERGE, so re-syncing never duplicates, and a full sync also removes opportunities that no longer exist in Clustr. Because it is keyed and idempotent, the table is safe to query live, build views on, or point a BI dashboard at.

​
Settings

The Snowflake panel shows connection status and sync controls.

​
Table Schema

clustr_referral_paths is keyed on id (used for upserts); all other data fields are stored as text so the export never fails on type coercion. Full column reference:

​
Accounts and Connectors tables (optional)

Besides the warm intros, Clustr can export your Accounts and Connectors ledgers. Both are off by default. Turn them on in the connect form’s last step, or later under Integrations → Snowflake → Settings. Turning one on starts a sync straight away. They are written into the same schema as the warm intros, by the same sync, with the same rules: every row is upserted on its key, and rows that left the ledger are removed after a complete sync. Turning a table off stops writing it; the table and its rows stay. All columns are text, like the warm-intros table.

​
Competitor monitoring tables (optional)

With competitor monitoring, Clustr can also export your competitors’ activity and the accounts they work. One switch writes both tables: Competitor monitoring, in the connect form’s last step or under Integrations → Snowflake → Settings. It is off by default, and turning it on starts a sync straight away. Both tables are written by every sync, including the one that follows each competitor scan, and each sync writes them whole: an interaction you ignore or a competitor you remove leaves them at the next sync. Turning the switch off stops writing them; the tables and their rows stay.
  • clustr_competitor_activity has one row per like or comment, as the Activity tab lists them. activity_id stays the same for the same interaction from one sync to the next. direction is outbound when their person engaged someone’s post, inbound when someone engaged their person’s post.
  • clustr_competitor_accounts has one row per account a competitor ever touched, and per company that buys from a competitor you watch (customer_only is true for those, with no interactions). standing is customer, crm or new, as the Account column reads.
  • has_open_deal, deal_stage and deal_name are the open deal in your CRM, the one the Accounts page shows.
  • Join either table to clustr_accounts on company_id, account_linkedin_id or clustr_account_id.

​
Renaming a table

Every table Clustr writes carries a marker in its comment (clustr:referral_paths, clustr:accounts, clustr:connectors, clustr:competitor_activity, clustr:competitor_accounts). If you rename a table in your database, Clustr finds it by that marker and keeps writing to it under its new name. Clustr only writes the comment when the table has none, so a comment of your own is never overwritten; keep the marker text in it if you edit it.

​
Troubleshooting