Skip to main content
Your warehouse already holds things Mary would benefit from knowing: product usage, support history, account health, revenue, the segmentation your team has already built. Inbound sharing lets allGood read that data directly, in place — the same Secure Data Sharing mechanism as outbound, pointed the other way. You publish a share containing whatever you choose, and allGood mounts it read-only. Reading the share is live — allGood queries your tables where they sit, and revoking the share ends that access immediately. Data you then bind into the Marketing Kernel works differently: allGood keeps its own copy of those rows as records, so the rest of the platform can act on them. That copy is allGood’s, and it outlives the share — see Disconnecting. Setting it up is two halves: you run a short script in your own Snowflake account to publish a share, then you tell allGood which account it came from.

​
Before you start

  • You need the Admin role in allGood to reach the Snowflake Data Sharing settings.
  • You need ACCOUNTADMIN (or another role that can create shares) in the Snowflake account holding the data.
  • Your Snowflake account must be in the same cloud region as your allGood account. The settings page names allGood’s region at the top; if yours differs, contact allGood support before you begin.
1

Open the Snowflake Data Sharing settings

In allGood, go to Settings → Snowflake Data Sharing and find the Bring Your Data into allGood card.
2

Copy the script that publishes the share

Click Copy to take the script, which creates a share, grants your data to it, and adds allGood’s account as the consumer.By default it shares everything in one database. To change the database name — or the name of the share itself — click ⚙ Options, or click the underlined values in the script.
The share name is yours to choose. allGood identifies an incoming share by the account that published it, not by what it’s called, so name it whatever fits your conventions.
3

Run it in your Snowflake account

Paste the script into an SQL console and execute it as ACCOUNTADMIN.The grant block in the middle is the part to adjust if you don’t want to share a whole database:
Narrow it to a single schema, name individual tables, or grant secure views you’ve built for the purpose — allGood reads exactly what this block gives it and nothing else.The last statement returns your account ID, which the next step needs:
4

Tell allGood where it came from

Back in allGood, click I’ve Run This. Paste the account ID into the field that appears and click Connect Share.allGood finds the share your account published, mounts it, and lists the tables it can now see.
Use the account ID from the query above, not your account locator (the eight-character code like AB12345 in some Snowflake URLs). The two look alike, and a locator won’t match.
If the share hasn’t arrived yet — Snowflake can take a moment — allGood keeps checking every ten seconds and connects it as soon as it appears. You can leave the page open.
5

Check what allGood can see

The card now lists every table and view in the share, by schema. If a table you expected is missing, add it to the grant block and re-run that part of the script; it’ll show up on the next page load without reconnecting.If the list is empty, the share was created but nothing was granted to it — check that the grant statements ran against the right database.

​
Using the data

Connecting a share makes it readable. To act on it, allGood binds a table to a record type in the Marketing Kernel, which keeps a set of records in step with your rows: new rows become records, changed rows update them, and deleted rows are marked as gone. Those records are a copy, held in allGood’s own storage — that’s what lets identity resolution, segments, policies and campaigns work against your data at the speed they need to. allGood re-reads the share on a schedule to keep the copy current, so it trails your warehouse by however often that runs. Contact allGood support to bind synchronized data to a record set in MK. We’ll need to know which table, which column uniquely identifies a row, and which column changes when a row is updated. Once a table is bound, its record type gets a Sync page under Setup → Record Types, showing what it reads, how often, and how many records have changed each day — plus a Sync Now button.

​
What allGood can read

Only what your grant statements name. A few properties are worth knowing:
Snowflake enforces this, not allGood. A database created from a share cannot be written to at all — no inserts, no updates, no new objects.
Grant them to the existing share and they appear. The setup script’s grant … on all tables in database covers tables that exist at the time it runs; add grant select on future tables in database … to share … if you want new tables picked up automatically.
An allGood workspace connects exactly one inbound share. To bring in data from several databases, grant them all to the same share rather than creating a second one. If your account has published more than one share to allGood, connecting will tell you so rather than guessing.
A single Snowflake account can only be connected to one allGood workspace at a time, because the account is how allGood tells shares apart. If you need to feed two workspaces, get in touch.

​
Disconnecting

Click Disconnect on the card and confirm. allGood immediately stops reading the share, and anything syncing from it stops. Nothing is deleted on your side — the tables stay in your account untouched — and records already synced into allGood stay too, frozen as they were. You can reconnect the same share later. To cut access from your own side instead, drop the share in Snowflake:

Outbound Sharing

The other direction. Query allGood’s entities, records and activity from your own warehouse.

Datasets

Load tabular data into allGood without Snowflake sharing.