Raw sources & permissions

This project declares 10 dbt sources. Most of the ad-platform ones say "landed by Airbyte" in their own sources/*.yml descriptions — that's stale. Drive recently migrated these connectors from Airbyte to Integrate.io, and the schema names confirm it (IIO_GOOGLE_ADS_SCHEMA, IIO_META_ADS_DRIVE_SCHEMA, and so on — IIO is Integrate.io). This page documents the real ingestion path per source, and who can actually read the landed data.

Google Ads, Bing Ads, Meta Ads, TikTok Ads, RTB House, Salesforce LMS — Integrate.io

Six sources, all landed the same way: Integrate.io writes into a dedicated IIO_<platform>_SCHEMA schema under RAW_DB, declared via dbt_project.yml vars rather than hardcoded per source file:

snippet.yamlyaml

vars:
  google_ads_schema: "IIO_GOOGLE_ADS_SCHEMA"
  bing_ads_schema: "IIO_BING_ADS_SCHEMA"
  meta_ads_drive_schema: "IIO_META_ADS_DRIVE_SCHEMA"
  meta_ads_caradvice_schema: "IIO_META_ADS_CARADVICE_SCHEMA"
  tiktok_ads_5351_schema: "IIO_TIKTOK_ADS_5351_SCHEMA"
  salesforce_lms_schema: "IIO_SALESFORCE_LMS_SCHEMA"
  rtb_house_schema: "IIO_RTB_HOUSE_SCHEMA"

Meta Ads lands as two separate schemas, not one — IIO_META_ADS_DRIVE_SCHEMA and IIO_META_ADS_CARADVICE_SCHEMA, one per brand account. Both feed the same meta_ads staging folder (see Ad platforms & SCD2 snapshots).

The Integrate.io side of this is Snowflake infrastructure documented in Infrastructure: a dedicated DRIVE_{ENV}_ROLE_ETL role, a service user (DRIVE_{ENV}_IIO), and a storage integration (IIO_STORAGE_INTEGRATION) whose real AWS values Integrate.io's own platform sets out-of-band — Terraform provisions the placeholder and then leaves it alone (lifecycle.ignore_changes).

GA4 — Snowflake's native connector, not Integrate.io at all

GA4 is a third, distinct ingestion mechanism — Snowflake's own GA4 Native App, authenticated against Google's APIs via a dedicated GCP service account:

snippet.hclhcl

# platform/terraform/env-staging/main.gcp.iam.tf
resource "google_service_account" "snowflake_sa" {
  account_id  = "${var.environment}-${var.client_code}-${var.app_name}-ga4"
  description = "Service account for Snowflake Native App to access Google Analytics 4 data"
}

This service account is scoped to the Google Analytics Admin API and Analytics Data API specifically — Terraform's own file header calls it out as existing purely so "Snowflake's GA4 Native App connector" can read Google's side. Data lands in RAW_DB.GA4_SCHEMA (hardcoded in models/sources/ga4.yml, no var). This isn't Integrate.io and never was — don't lump it in with the six platforms above just because it also ends up in RAW_DB.

Insider — a separate database outside the RAW_DB pattern

models/sources/insider.yml points at INSIDER_DB.DRIVEAU_DRIVE_UDP_DEV_SCHEMA — a completely separate database, not a schema under RAW_DB like every other source. Searching this repo's Terraform for INSIDER_DB returns nothing: this database isn't provisioned or granted anywhere in this repo's infrastructure code. Either it's managed by a different repo, provisioned manually, or shared in from elsewhere — the exact mechanism isn't visible from here. If you need to grant access to it, don't assume the standard RAW_DB role grants below cover it; verify separately.

Manifold & Stock — not new ingestion, cross-database reads

manifold and stock aren't landed by this project at all — they're source() declarations pointing at tables that already exist in VEHICLE_STOCK_DB, owned and populated by the Stock pipeline (STOCK_IDENTIFIER_XREF, STOCK_FACT_MART, STOCK_LIFECYCLE_FACT_MART). See Stock Ingestion and Marts (fact & dimension) for how those tables actually get populated — this project only ever reads them.

The stock source's own yml description is a stale copy-paste, worth knowing before you trust it: it says "Raw Salesforce LMS dataset landed by Airbyte into raw_db.salesforce_lms_schema" — describing the Salesforce source's own text, not this one. The actual database/schema fields are correct (vehicle_stock_db.vehicle_stock_schema); only the free-text description is wrong.

Who can actually read these raw schemas

Permissions on RAW_DB (where most sources live) are granted once, account-wide, in Infrastructure — not per-project. The roles that matter for this project specifically:

Role	Access to `RAW_DB`	Relevance here
`DRIVE_{ENV}_ROLE_ETL`	Owns the schemas Integrate.io writes into; `CREATE FILE FORMAT`/`STAGE`/`TABLE`/`TEMP TABLE` on all + future `RAW_DB` schemas	The six Integrate.io-landed sources above are written under this role's ownership
`DRIVE_{ENV}_ROLE_DBT`	Read-only (`USAGE` + `SELECT`) on all + future `RAW_DB` tables/views, no ownership	What lets this project's `source()` declarations actually resolve when dbt runs
`DRIVE_{ENV}_ROLE_BI`	Read-only on all + future `RAW_DB` schemas	Sigma/Tableau can query the raw ad-platform tables directly, not just this project's marts/reporting output
`DRIVE_{ENV}_ROLE_READONLY`	`SELECT` on every database, existing + future	The broadest read role in the account — covers `RAW_DB` along with everything else

None of these grants extend to INSIDER_DB — see above. Full detail on all six functional roles, including the ones not relevant to this project, is in Snowflake resources & RBAC.