Skip to main content
Kadoa can publish workflow output into Kadoa-owned Snowflake provider tables and share read-only secure views with your Snowflake account. This native connector does not require you to manage S3 buckets, external stages, or Snowpipe.
The older customer-managed S3 + Snowpipe setup remains available as a separate path. See Snowflake via Snowpipe if you want to own the Snowflake loading pipeline.

​
Required Inputs

Send Kadoa these Snowflake account details:
InputDescriptionExample
Organization namePreferred when availableACMEORG
Account name or account IDThe consumer account to receive the sharePROD_ANALYTICS or ALC62998
RegionYour Snowflake account regionUS East 1
CloudOptional if the region makes it clearAWS
You can find the values in Snowflake with: 
select
  current_organization_name() as organization_name,
  current_account_name() as account_name,
  current_account() as account_identifier,
  current_region() as snowflake_region;

​
Setup Flow

  1. Kadoa creates a Snowflake connector for your team with your account identifier, region, selected workflows, and optional activity-log export.
  2. Kadoa verifies the target account with a zero-data share before exposing workflow or activity data.
  3. After each successful workflow run, Kadoa stages the run into its own Snowflake ingestion bucket, loads provider tables, validates row counts and grants, and then publishes secure views.
  4. You import the share or private listing in your Snowflake account and query the shared database.
Same-region accounts use direct Snowflake shares. Cross-region or cross-cloud accounts use Snowflake private listings with Cross-Cloud Auto-Fulfillment when enabled for the target region.

​
Shared Views

Each connector gets a customer-facing schema with these views:
ViewPurpose
WORKFLOW_RUNSOne row per shared workflow run, including job ID, workflow ID, row count, schema version, and status metadata
WORKFLOW_SCHEMA_VERSIONSThe schema catalog for every published workflow schema version
WORKFLOW_SCHEMA_FIELDSOrdered field metadata, Kadoa type, Snowflake type, and cast policy
WF_<id>__V<n>Versioned workflow output view for a specific schema version
WF_<id>__LATESTConvenience view pointing at the latest schema version
ACTIVITY_LOGOptional activity-log view matching the customer-visible activity log surface
Kadoa grants only secure views to the share. Internal provider tables are not shared.

​
Schema Changes

Kadoa does not create a new view after every run. New rows append to provider tables, and the existing views continue to work when the workflow schema is unchanged. When the workflow schema descriptor changes, Kadoa creates a new versioned view, preserves older versioned views, and updates __LATEST only after load, grant, and visibility checks pass. Use versioned views for stable downstream models and __LATEST for quick exploration.

​
Freshness And Delivery State

Successful workflow runs are expected to appear in Snowflake within minutes after Kadoa stages the file. Activity-log export is also near real time, but it uses a separate cursor-based sync and should be treated as minutes, not instant. Historical activity-log backfill is not automatic. If delivery cannot complete, Kadoa records an actionable failure stage such as stage, schema, load, share, or verify and retries safe stages. Ops can inspect delivery history without querying customer accounts.

​
Disable And Revocation

Disabling a Snowflake connector stops new workflow and activity delivery immediately. Existing shared access remains available for 90 days, then Kadoa hard-revokes the direct share or private-listing target and verifies removal.

​
Example Queries

List recent workflow runs: 
select workflow_id, job_id, schema_version, row_count, shared_at
from workflow_runs
order by shared_at desc;
Inspect a workflow schema: 
select field_index, field_name, kadoa_type, snowflake_type
from workflow_schema_fields
where workflow_id = '<workflow_id>'
  and schema_version = 1
order by field_index;
Query the latest workflow output: 
select *
from wf_<id>__latest
limit 100;
Query activity events if activity-log export is enabled: 
select occurred_at, event_title, resource_name, workflow_id, request_source
from activity_log
order by occurred_at desc;