Connecting an LLM
GRAX Data Lake writes your Salesforce history to your cloud storage in an open columnar file format. Any tool that can read those files can be pointed at your Salesforce history, including an AI assistant.
This page describes that connection: the stages involved, the decision you make at each one, and what you own versus what GRAX provides. It is deliberately not a single recipe; the cloud you run on, the query engine you already use, and the AI tooling your company has standardized on all change the specifics.
Scope of Support
GRAX supports the data lake itself: your data lands in storage you own, in a documented format. The layers you build on top of it are yours to build, operate, and validate. The paths below demonstrate what is possible. They are examples rather than requirements, and they are not a supported product surface.
Before You Start
Is your GRAX data landing in storage you own?
This is the prerequisite for everything else. If GRAX is not currently writing to a storage container in your own cloud account, that is the first thing to fix. See Connecting Storage for the supported platforms and connection methods. Nothing below is possible until this is true.
If you would like to discuss your options for storage or migrating between storage containers, please Contact GRAX Support for assistance.
Do you want your cloud provider's native query tooling, or something you already run?
Your existing data platform, warehouse, or analytics vendor may already be able to read GRAX Data Lake output, and where that relationship exists it is usually the cheaper answer. GRAX does not prescribe one because every stack is different.
The Five Stages
These are the same on every cloud and with every model. Only the product names change.
Storage you own. GRAX writes your Salesforce history there and keeps it current. This part is done for you. Data Lake documents the file format and layout your data is written in.
A query engine that reads those files in place. Something that runs SQL directly against the files without copying them into a database first, or a scheduled load into a warehouse you already operate. Both are valid: the first is cheaper to stand up, the second is cheaper to query repeatedly.
Credentials scoped to that engine. An identity that can run queries and nothing else. How that identity is issued and rotated is a real security decision, since you are granting query access to a complete history of your Salesforce data. AWS Data Lakehouse IAM Role covers scoping a consuming principal to the Parquet files without exposing the rest of the bucket.
A connector between your AI tooling and the engine. Two common shapes: a command line client the assistant is allowed to invoke, or an MCP server, which presents the engine to the assistant as a defined set of operations rather than as arbitrary shell access. MCP is an open standard supported by multiple AI tools, which makes it the more portable of the two if you expect to change assistants. Nothing here is specific to any one model or vendor.
A curated set of views, and a way to check the answers. The most valuable stage and the least prescribable. Covered in Stage 5 below.
The AI assistant never touches your storage directly. It asks for a query through a boundary you control, and that boundary is where your guarantees belong. Read only access, result size caps, and which views are visible at all should be enforced in the connector rather than requested of the model in instructions. Enforced that way, they survive a change of model.
Stages 2 and 3 by Cloud
AWS S3
Athena, over a Glue catalog
Snowflake, Redshift
Several engine choices are independent of which cloud holds the storage. DuckDB Data Lakehouse runs in process with no infrastructure to stand up, and Open Source Lakehouse covers a fully self hosted assembly. If GRAX runs on Heroku, Heroku Data Lakehouse covers querying the lake from a Heroku application. Data Cloud covers Salesforce Data Cloud as the destination.
Worked Example: AWS
This example is included because it is the most automated path, not because it is necessarily the best one for you. On Azure or GCP the stages above still hold; you assemble more of stage 2 yourself, using the reference documentation for your cloud.
Deploy the catalog and query layer
GRAX publishes a CloudFormation template that creates the Glue catalog, the jobs that maintain it, and the Athena configuration. See AWS Data Lakehouse for the template and its parameters. Two constraints are worth knowing before committing to this route:
The template must be deployed in the AWS account that owns the bucket. If your bucket lives in an account you cannot deploy CloudFormation into, the template will not work and you will need to build the equivalent yourself.
You must configure the S3 event notifications manually afterwards. This is a template limitation, not an optional step. Without it, the catalog never learns about new data. The template's outputs tell you what to point the notifications at.
Confirm it is actually working
Verify that the Glue jobs are running and that they pick up new changes, not just the data that was already present at deploy time. Budget real time for this: depending on data volume and how often your records change, confirming the pipeline end to end can take hours. Do not move on from this step assuming it worked.
Decide how access is granted
The template creates an identity with Athena access. Federating that access through assume role and your existing SSO or identity provider is the recommendation, since access is then tied to a person, expires, and is auditable. Long lived access keys also work and are simpler to set up, but they do not expire, they are easy to leak, and they are not attributable to a human. This is the point at which your security team should be involved.
Connect your tooling
Either a command line client the assistant can invoke, or an MCP server for your cloud's data services. Install and authenticate your choice.
Stage 5: What the Assistant Actually Sees
A GRAX Data Lake is a complete version history, not a current state copy. Every version of every record is retained. Raw tables therefore do not answer business questions directly: row counts count versions rather than records, and "the current value" requires an explicit ordering rule. Data Lake documents these semantics in full.
The normal answer is a small set of curated SQL views that encode your definitions: what "current" means, which fields your business actually reports on, and what to exclude. Point the assistant at those rather than at raw tables. What belongs in them is specific to your organization, and nobody outside your company can write them for you, since this is where your business logic lives.
Two things to plan for:
Validate before you trust. Assemble questions whose answers you already know from a report you trust, and check that you get them exactly. The errors this kind of system produces are small and plausible, which is what makes them worth catching deliberately rather than discovering later. Re run the set whenever the views, the definitions, the tooling, or the model change, since none of those announce that they have changed an answer.
Reconstructing current state from full history costs more as history grows. Most implementations end up periodically materializing current state rather than deriving it on every query. That is a reasonable trade, provided whoever reads the numbers knows how fresh they are.
Who You Will Need Involved
Realistically this touches five skill sets. They may be five people or one, but the work exists either way.
Cloud infrastructure
Standing up the query layer and verifying the pipeline
Security and identity
How query access is granted, scoped, and rotated
Data or analytics engineering
The curated views, and what "current" means in them
Business data owner
Which fields and definitions your company actually reports on
AI or platform owner
The connector, its guardrails, and validating the answers
If the middle three are not covered, start there. They determine whether the result is trustworthy, which is a different question from whether it works.
Reference Documentation
Connecting Storage. Connecting GRAX to storage you own.
Data Lake. The file format and layout your data is written in.
AWS Data Lakehouse. CloudFormation template, Glue, and Athena.
AWS Data Lakehouse IAM Role. Scoping a consuming principal to the Parquet files.
Azure Data Lakehouse. Synapse serverless over Blob or ADLS Gen2.
GCP Data Lakehouse. BigQuery over Cloud Storage.
DuckDB Data Lakehouse. Querying the lake in process.
Snowflake Tables from Data Lake. Scheduled load into Snowflake.
Heroku Data Lakehouse. Querying the lake from a Heroku application.
Open Source Lakehouse. A fully self hosted assembly.
Data Cloud. Salesforce Data Cloud as the destination.
Multiple Orgs. Planning storage and query targets across more than one org.
Last updated
Was this helpful?