> ## Documentation Index > Fetch the complete documentation index at: https://docs.allgoodhq.com/llms.txt > Use this file to discover all available pages before exploring further. # Give allGood access to data from your warehouse 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](/ops/snowflake/outbound-sharing), 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](#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. In allGood, go to **Settings → Snowflake Data Sharing** and find the **Bring Your Data into allGood** card. 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. 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: ```sql theme={null} -- Adjust these grants to control what allGood can read through the share. grant usage on all schemas in database MY_DATABASE to share MY_SHARE; grant select on all tables in database MY_DATABASE to share MY_SHARE; grant select on all views in database MY_DATABASE to share MY_SHARE; ``` 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: ```sql theme={null} select current_organization_name()||'.'||current_account_name(); ``` 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: ```sql theme={null} drop share MY_SHARE; ``` The other direction. Query allGood's entities, records and activity from your own warehouse. Load tabular data into allGood without Snowflake sharing.