Data Gateway Use Cases: AI to SaaS and Data Warehouse

This is the second of six scenarios walking through how AI agents already connect to enterprise SaaS without anyone signing off on it, and how a data gateway closes the gap without shutting the access down. The first covered an AE connecting an agent straight to Salesforce: one hop, one identity, no gateway in between. This one keeps that same connection running and adds a second one next to it, into Snowflake, the data warehouse most IT teams already run underneath Salesforce for reporting.

Once the agent can reach both systems, one question stops having one answer. It can pull pipeline numbers from Salesforce or from the warehouse underneath it, and which one it picks isn't a policy anybody wrote down, it's whichever schema the model happens to try first.

Most IT teams already run a warehouse that consolidates data from several systems for reporting and analytics. A typical stack runs Fivetran that replicates Salesforce into Snowflake on a nightly schedule, dbt models the raw objects into reporting tables, and Looker or Tableau sits on top for the CRO's pipeline dashboard. The same warehouse usually includes data from NetSuite for invoices, Zendesk for tickets and Workday for headcount.

The AE now connects the agent to both. Salesforce through the connector from scenario 1, and Snowflake through a second OAuth flow using the AE's Snowflake role. Two connections, one chat.

This approach works because the warehouse is what the business already trusts for reporting. The numbers are modeled, the joins are done, and the queries return in seconds. Asking about pipeline against Snowflake is faster and often more consistent than asking Salesforce directly. It works because the AE has access to both the IT provisioned Snowflake and data pipeline.

1. Fine-grained permissions do not survive in the data warehouse

Salesforce enforces access through profiles, permission sets, sharing rules, territory management and field level security. None of that is replicated into the warehouse. Fivetran syncs whatever its connecting Salesforce user can see, which is normally an integration user with broad access, and lands it as ordinary tables. From that point the Snowflake role decides who reads what information.

Warehouse roles are almost always coarser than Salesforce profiles. An analyst role that can read the reporting schema can read every opportunity in it, including the ones Salesforce would have hidden from that AE. The least privilege you get for free in scenario 1 is gone. Reconstructing it requires row access policies and masking policies written by hand in Snowflake, and most teams have not written them.

2. You cannot see or control which route the agent takes

The same question now has two possible responses. Ask about closed won revenue and the agent may query Salesforce, or it may query Snowflake, but will not explain the choice. Routing is decided by the model, based on whichever schema it read first or whichever query succeeded. The Salesforce path returns what the AE is entitled to see. The Snowflake path returns additional information that the AE may not be entitled, based on Snowflake warehouse access. The two answers can differ in scope and freshness, because the warehouse is only as current as the last sync.

3. The warehouse grant is wider than the request

The AE asked for pipeline data, but the grant gives the agent access to the warehouse schema that role can reach, which, in a consolidated warehouse means billing, support history and whatever else was joined in for reporting.

The Salesforce API limit called out in scenario 1 does not apply in this scenario. Warehouse queries do not consume Salesforce API calls, so the throttle that used to cap agent activity is now gone. Instead, consumption moves to Snowflake compute credits, which are billed on actual consumption without any particular daily limit.

The data gateway gives you one place to make the routing decision the model was making on its own. Connections are defined in the workspace by IT and shared with AEs, so the Snowflake connection can carry a purpose-built role scoped to the reporting schema, and the agent reaches the warehouse only through that connection.

Workspace rules then state which source is authoritative for which concept, so "opportunity means Salesforce, revenue means the warehouse" becomes a written policy instead of a guess the model makes from whichever schema it reads first. Every query is recorded against the connection it ran on, so after the fact you can see which route was taken and why two numbers from two different sources disagree. Persisted results also mean a repeat question does not spend Snowflake credits twice.

Adding Snowflake doesn't just double the number of systems an agent can reach, it removes the free least-privilege guarantee that direct MCP gave you in scenario one. The warehouse never learned Salesforce's sharing rules, and nothing in the chat window tells you which system actually answered a given question, or why two runs of the same question came back different. The next scenario keeps this same AE, but multiplies the agent instead of the system: three narrow agents in one chat, one for pipeline, one for forecast, one for the briefing, sharing a single Okta login. Salesforce and Snowflake each see their own agent's connection, so what looks like one sign-in becomes three separate, uncorrelated logs, with no single switch that turns all three off at once.

If your AEs already have both of these connected, and most do without anyone deciding it should work that way, I'd like to look at it with you. Book time with me and we'll walk through what a routing policy would actually look like on your own Salesforce and Snowflake setup.