> ## Documentation Index > Fetch the complete documentation index at: https://docs.synq.io/llms.txt > Use this file to discover all available pages before exploring further. # Data Warehouse Access > How queries from Coalesce Quality authenticate to your data warehouse, and the per-capability toggles that gate them Coalesce Quality issues queries against your data warehouse for a small, opt-in set of features (catalog data preview, ad-hoc reconciliation, scheduled reconciliation suites, Scout AI agent runs, and SQL test failed-rows inspection). This page describes the two ways those queries can authenticate and how to configure them safely. ### Default posture Nothing is enabled by default. When a workspace admin connects a data warehouse integration, the workspace credentials are stored encrypted but they are **not** automatically allowed to back any user-facing feature. Each capability has its own opt-in toggle that the admin must explicitly turn on. This default-deny posture is intentional. Workspace credentials typically have broader grants than any individual member's warehouse account; making them the default backing for member-triggered queries would bypass per-member grants, masking policies, and row-level security without the member realising. ### The two authentication paths There are two ways a query from Coalesce Quality can reach your data warehouse: #### Personal credentials (recommended) Each member authenticates as themselves. Queries run under the member's own warehouse account, so all your warehouse-side controls — grants, masking policies, row-level security, audit logs — apply automatically and reflect the real actor. The workspace admin enables personal credentials on the integration, and each member then connects from Settings → Warehouse access → My credentials. The exact mechanism depends on what the data warehouse offers — typically a username + password, an access key, or an OAuth-style consent flow. Credentials are stored encrypted; only the member who saved them can use them, and the admin never sees them. For warehouses that support a proper user-level OAuth flow — currently **Snowflake**, **BigQuery**, and **Databricks** — Coalesce Quality requires that flow rather than a long-lived password. The admin configures an OAuth app on the integration once; each member then completes a short browser-based consent and Coalesce Quality stores per-user access/refresh tokens. Revoking access is done in the warehouse like any other OAuth app. We strongly recommend personal credentials wherever the warehouse supports them. When you explicitly pick **Personal** for a query, it either runs as you or fails. Coalesce Quality will not fall back to the shared workspace credentials on its own — changing the identity that runs a query would also change which warehouse-side controls (grants, masking, RLS) apply, and the Personal path exists precisely to honour those controls. If your personal credentials aren't configured, or the admin hasn't enabled personal access for the integration, you'll see a clear permission-denied error and can choose to retry via Workspace credentials deliberately. #### Workspace credentials (convenience, requires explicit opt-in) Data preview, reconciliation (ad-hoc and scheduled), and column/table profiling are currently in early access. The capability toggles below appear only in workspaces that have been opted in — if a toggle isn't visible on your integration, the feature isn't available in your workspace yet. Some workflows benefit from running under the shared workspace credentials configured on the integration: * A user can preview data without first connecting personal credentials * Ad-hoc reconciliation can run for users who haven't (or can't) configure personal access * Scheduled jobs and managed agents have no member present at run time and have to use workspace credentials by definition Workspace credentials are gated by **five independent capability toggles** on each data warehouse integration. All default to off: | Capability | What it allows | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Data preview** | Catalog row previews and column samples may run under the workspace credentials. When disabled, preview requires personal credentials — members (and admins) without personal credentials configured will not be able to preview. | | **Ad-hoc reconciliation** | Members may trigger one-off reconciliation runs that execute under the workspace credentials. Personal credentials remain a parallel path when configured. | | **Scheduled reconciliation suites** | Required to publish reconciliation suites that run on a schedule or via API. Always executes under workspace credentials — there is no equivalent personal-credentials path. | | **Scout AI** | Scout is a workspace-level agent: it runs autonomously, with no member present, and therefore always uses the workspace credentials — there is no personal-credentials path for Scout. This toggle is the admin's explicit opt-in for Scout to reach a given integration; without it, Scout cannot connect to that warehouse, even if other workspace capabilities are enabled. | | **SQL test failed-rows queries** | Members may re-run a failing assertion under the workspace credentials to inspect the rows that tripped it. | Enabling a toggle lets every workspace member use the corresponding feature with the warehouse access of the shared workspace account. Warehouse-side per-member controls (grants, masking policies, row-level security) do not apply to queries served via that toggle, because the queries run as the workspace account rather than the member. We recommend keeping these toggles off unless the warehouse-side access for the workspace credentials has been intentionally narrowed (selective grants, masking policies, etc.) to a level you are comfortable sharing across the workspace. These toggles are workspace policy, not a permission knob: they apply to everyone who interacts with the integration, **including workspace admins**. Editing an integration and using it are separate capabilities — an admin who has not configured personal credentials is subject to the same gate as any other member. This is intentional: the "use" experience (preview, run, query) is predictable and uniform across roles, and the same audit trail applies to everyone. ### Where these are configured Two surfaces, both under **Settings → Warehouse access**: * **Overview** (admin only) — a single page listing every data warehouse integration with its current personal-access state and the five workspace-capability toggles. The fastest place to see and change policy across all integrations. * **My credentials** — every member sees this. Lists the warehouses on which the admin has enabled personal credentials and lets each member connect (OAuth flow or save username + password) or disconnect their own credentials. Members without personal credentials can use the shared workspace credentials only for the capabilities the admin has enabled. The same toggles are also available on the per-integration edit page under Settings → Integrations → *(integration)* → Warehouse access. OAuth app configuration is on the per-integration edit page. ### Support access to your data When a Coalesce Quality support engineer joins a customer workspace to investigate a case, that session runs under stricter rules than a normal member session. The workspace credentials configured on your data warehouse integrations remain reserved for your own members and automated jobs; a support session cannot reach them, regardless of how the capability toggles are configured. The same restriction applies across every workspace, every region, and every integration type. Two independent checks enforce this: * The capability matrix returned to support sessions reports every workspace-credential capability as unavailable, so the UI and downstream services never offer a "workspace credentials" path for these requests. * The credential resolver re-checks the session at the moment credentials are materialised, so any code path that misses the capability matrix still rejects the request with a clear policy error. If a support engineer needs to run queries during an investigation, they do so through their own personal credentials, configured against their own warehouse account — never against your shared credentials. This means warehouse-side controls (grants, masking, RLS) apply to the engineer the same way they apply to any other identified user, and warehouse audit logs attribute the activity to that engineer rather than to a shared service account. Data returned by any query is **in-transit only**: result rows are streamed straight to the requesting feature (a preview pane, a reconciliation run, a Scout investigation) and are never written to Coalesce Quality storage or logs. The credential resolver writes an audit record every time it fetches a workspace credential from our secret manager (`audit=workspace_credential_access`), capturing the calling user, integration, and workspace. Requests blocked by the support-session rule or by any other policy check are recorded at ERROR level on the same log. The audit log is queryable by the Coalesce Quality platform team and surfaces in our standard observability tooling. Automated system jobs (data ingestion pipelines, scheduled reconciliation deployments, managed Scout) have no human session and are governed by the capability toggles only — the support-session rule does not apply to them. ### Recommended setup For most workspaces: 1. Connect your data warehouse integration with workspace credentials that have the minimum grants needed for ingestion (metadata, query logs, etc. — see the [security policy](/security/security) for the broader access model). 2. If your warehouse supports it, configure an OAuth app on the integration so members can authenticate as themselves. 3. Otherwise, enable "Let members sign in with personal credentials" so members can save their own username and password. 4. Leave the five workspace-capability toggles off. 5. Ask members to connect from My credentials. Once enough members have personal credentials configured, leave workspace capabilities off permanently. 6. Enable workspace capabilities only for features that need them (Scheduled reconciliation, Scout AI) or as a deliberate trade-off for workspaces where preparing per-member grants is impractical and the workspace credentials' grants have been narrowed to a level you are comfortable sharing.