Architecture
How does data get into and out of allGood?
Through two Snowflake data shares, one in each direction. You share your tables (leads, contacts, accounts, opportunities, and anything else you want to act on) to allGood, and allGood syncs them into the Marketing Kernel. allGood shares its data back to you as secure views — people, records, activity, and every data change — so it lands in your own Snowflake. See Inbound Sharing and Outbound Sharing.Why two shares instead of one?
A Snowflake data share only goes one way: the provider publishes, the consumer reads. Sending data in both directions takes two shares, one published by each side.Is there an API or ETL tool involved?
No. The whole integration is Snowflake data sharing, not an HTTP API. Nothing is exported, and there’s no pipeline to schedule or monitor. Data allGood shares with you shows up in your Snowflake the moment you accept the share.Where should our “golden” customer record live?
In your own Snowflake. allGood’s outbound share is meant to feed your golden layer, not replace it. Pull the shared views into your modelled layer and join them with the rest of your data, as you would any other source.Do we need to create service accounts or users for allGood?
No. The only hard requirement is publishing a share to allGood and accepting the one allGood publishes to you. You’ll want roles on your side that control what your share exposes, and who in your account can read allGood’s data. For the outbound share, grant allGood’s database role to one of your roles to open access.Sharing your data with allGood
Which tables should we share for a first version?
Start with these:- Marketo leads — standard fields plus any custom fields you actively use.
- Salesforce leads and contacts — the same rule: standard fields plus the custom fields you use.
- Salesforce accounts and opportunities.
- Salesforce users, so ownership resolves.
What format does the data need to be in?
Whatever shape it already has. One row per record in a normal flat table is ideal, and you don’t need to transform it to fit an allGood schema. allGood builds its automations on top of the shape your data already has. Share anything you’d like to act on in allGood — including non-marketing data such as product usage, event attendance, or nonprofit reference data.Should we join our sources before sharing them?
No. Share each source as its own table. If an enrichment table and your Salesforce accounts table both carry a domain, share both and let allGood’s identity resolution match them. You then decide in allGood which fields to take from which source.Can we share views, or only tables?
Tables or secure views. Snowflake won’t put a regular view in a share, so any view you want allGood to read must be created assecure.
Our Marketo data already backs up into Snowflake. Do we still need to export it?
No. Create a secure view over the backed-up Marketo table and grant it to your allGood share. allGood reads the same underlying table directly.How does allGood detect changes?
allGood re-reads your shared tables on a schedule. It compares each row to the record it already holds, field by field, and logs every change it finds. Rows removed from your table are marked as deleted in allGood, not erased. To set this up, allGood needs three things for each table: which table, which column uniquely identifies a row, and which column changes when a row is updated.Identity resolution
Where does identity resolution happen?
Inside allGood. You share the tables, and allGood runs the matching rules — for example, “a Marketo lead and a Salesforce lead with the same SFDC lead ID are one person.” Anonymous web activity joins a person once something identifies them, such as a form fill with an email address.Does allGood merge our records together?
Not destructively. Each source’s data is kept in its own namespace, so a person’s Marketo lead and Salesforce lead stay separate records. They’re tied together under one entity, which is allGood’s resolved person or company. You can always see which source a value came from, and when and why two records were linked.Can we see what allGood tied together?
Yes. The outbound share includes the mapping: each record carries the entity it belongs to. Query at the entity level for the resolved view, or at the record level to see each source on its own. When two entities merge, the merged-away entity stays queryable and points at the one that survived. See Outbound Sharing.Data quality and auditing
How do we verify allGood is doing what it says?
Point your existing data-quality tools at the outbound share. Checks like “null rate on this column stays under 3%” run against allGood’s views as they would against any table. If you need something beyond that, allGood can build it into the product for you.Is there an audit log of changes?
Yes. Every change in allGood is logged with a plain-language reason, whether it came from a sync, an agent, a person, or an automation. allGood’s application state is built from that log, so what you see in the app always matches it. The log is shared to you asDATA_CHANGE, so you can run your own checks against it.
Does the log catch records that didn’t process?
Yes — it works as a dead-letter record too. Inbound sync writes each row as a logged decision, so a row that arrived but didn’t produce the change you expected is visible in the log.Regions
Does our Snowflake account need to be in the same region as allGood’s?
Yes — Snowflake doesn’t share data between accounts in different regions. allGood’s default region is AWSus-west-2. If your account is in another region, contact allGood before you begin. The Snowflake account that holds your allGood data needs to be set up in your region first, so confirm your exact region (for example, us-east-1) before any setup starts.
Web tracking and forms
What replaces Marketo’s Munchkin tracking code?
allGood’s web tracking tag. You install it on your site, like Munchkin, and it records page views and events as activity. It only sends data from domains you’ve approved, and it respects your cookie consent tool. See Install the tag.Where does a form submission go first?
To allGood’s edge layer, running on Cloudflare close to the visitor. From there it’s queued to object storage and loaded into Snowflake in batches. Forms are plain HTML that you own and style; they post to allGood rather than rendering through a Marketo-style embed. See Capture a form.Automation
What do policies, plans, and motions do?
They’re the three layers of automation in allGood:- Policies clean up and decide. A policy reads declared fields, runs a formula or an agent, and writes declared outputs. Examples: normalizing job titles into role and level, inferring time zone, assigning a sales theater. Outputs stay current as the data changes.
- Plans run campaigns. Like a Marketo program, a plan moves people between statuses and acts on them — sending an email, publishing a landing page, reacting to a form fill.
- Motions are presets that build plans quickly for common campaign types, such as gated content.
Who configures them?
allGood builds the first set with your team and walks you through each one. After that, you can build more yourself from the docs, or describe what you need in plain language and have an agent in allGood draft it.Does allGood replace everything Marketo does today?
That’s the goal. Campaign execution, data management, and the operational rules Marketo handles today all move to allGood. Anything that can’t move right away — or that belongs in Salesforce — is identified during migration planning.Still have questions?
Contact support@allgoodhq.com, or ask your allGood implementation lead.Inbound Sharing
Publish a share so allGood can read your warehouse data.
Outbound Sharing
Accept allGood’s share and query its views from your warehouse.