# Connect Snowflake to Salesforce

> Load Salesforce accounts, opportunities and activity into Snowflake, with history kept for reporting. Send health scores, product usage and churn risk back to the Salesforce records your reps work in.

**Canonical page:** https://tray.ai/connectors/snowflake-salesforce-integrations/
**Snowflake connector:** https://tray.ai/connectors/snowflake-integrations/
**Snowflake documentation:** https://tray.ai/documentation/connectors/service/snowflake
**Salesforce connector:** https://tray.ai/connectors/salesforce-integrations/
**Salesforce documentation:** https://tray.ai/documentation/connectors/service/salesforce

## Overview

Your data team builds health scores, product usage and churn risk in Snowflake. Your reps work in Salesforce and never see them. Tray.ai moves data both ways between the two. Warehouse results land on the account, lead and opportunity records reps open every day, and Salesforce changes land in Snowflake for reporting.

The first sync is easy. The trouble starts a week later. A synced value overwrites a field a rep typed, a run hits the Salesforce API limit and reports success anyway, or a renamed field breaks the load. With Tray.ai, you agree which Salesforce fields the warehouse owns before anything writes. Only rows that changed since the last run sync, rate limits pause the run instead of dropping rows, and every run compares rows attempted with rows written.

## Use cases

### Health scores and churn risk on the Salesforce account

Your model scores every account in Snowflake. Tray.ai writes the score, its risk tier and the date it was calculated to dedicated fields on the Salesforce account. When an account moves into a high risk tier, the account owner gets a task.

- Reps see risk before the renewal call
- Scores in labeled, warehouse-owned fields
- Tasks created on a threshold, not a report

### Product usage on every account

Usage events live in Snowflake. Tray.ai rolls them up per account, such as active users, seats used and the last active date, and writes the totals to Salesforce. Account teams see expansion and adoption without opening a dashboard.

- Usage next to the deal, not in BI
- Expansion signals reach the account owner
- Only changed accounts are written

### Lead scores from the warehouse

Score leads in Snowflake with product, firmographic and intent data, then write the score to the Salesforce lead. Routing and assignment rules in Salesforce read the score like any other field.

- Scoring logic stays in SQL
- Routing rules read the latest score
- Matches on email or external ID

### Salesforce history in Snowflake

Load accounts, contacts, opportunities and activities from Salesforce into Snowflake as records change. Deletes and merges are recorded, history is kept, and row counts are checked on every run, so pipeline reports match the CRM.

- Pipeline history, not just current state
- Deletes and merges kept in the warehouse
- Row counts reconciled every run

### Closed-won deals into Snowflake

When an opportunity moves to closed won, Tray.ai writes the deal, its amount and its close date to a Snowflake table straight away. Finance and commission models read bookings the same day.

- Bookings in the warehouse as deals close
- One event, one row, no duplicates
- Finance works from the same numbers

### Alerts from warehouse thresholds

Run a Snowflake query on a schedule and act on the result in Salesforce. Examples are a usage drop on a renewing account or a deal with no activity for 30 days. Tray.ai updates the record, creates a task or posts to Slack.

- Warehouse signals become CRM actions
- No one has to watch a dashboard
- Thresholds edited without code

## Templates

### Snowflake account health score to Salesforce account

Reads changed health scores from a Snowflake table and writes them to warehouse-owned fields on the matching Salesforce accounts. Creates a task for the owner when the risk tier is high.

Connectors used: Snowflake, Salesforce

Steps:
1. Run on a schedule, or when the scoring model finishes
2. Query Snowflake for rows whose score changed since the last successful run
3. Match each row to a Salesforce account by ID or domain
4. Write the score, tier and calculated date to the warehouse-owned fields
5. Create a task for the account owner when the tier is high
6. Report rows attempted, written, failed and skipped

### Warehouse lead score to Salesforce

Writes the latest lead score from Snowflake to the Salesforce lead, so routing and assignment rules work from the current score.

Connectors used: Snowflake, Salesforce

Steps:
1. Query the Snowflake lead score table for rows updated in this window
2. Look up the matching Salesforce lead by email or external ID
3. Update the lead score field in batches, backing off when Salesforce limits the rate
4. Send unmatched rows to a review list instead of dropping them

### Salesforce opportunities to Snowflake, with history

Loads changed Salesforce opportunities into Snowflake and keeps each change as a new row, so the warehouse can answer how pipeline looked at any date.

Connectors used: Salesforce, Snowflake

Steps:
1. Run on a schedule
2. Query Salesforce for opportunities modified since the last run, including deleted records
3. Write each change as a new row with valid-from and valid-to dates
4. Compare Salesforce record counts with rows written and fail on any gap

### Closed-won opportunity to Snowflake bookings table

Listens for opportunities that move to closed won and writes one bookings row to Snowflake for each.

Connectors used: Salesforce, Snowflake

Steps:
1. Trigger when an opportunity stage changes to closed won
2. Read the opportunity, its account, amount and close date
3. Insert one row into the Snowflake bookings table, keyed on the opportunity ID
4. Notify finance in Slack for deals over a set amount

## Challenges Tray.ai solves

### Syncs overwrite what reps typed

A customer success manager sets an account to red after a bad call. That night the sync writes the warehouse value back over it. After the third time, nobody trusts the field.

**How Tray.ai helps:** Agree in writing which Salesforce fields the warehouse owns before anything writes. Tray.ai writes only those fields. Where a person also edits a value, the warehouse writes a separate field labeled as computed.

### Partial syncs that report success

Salesforce caps how many API calls it accepts. A run hits the cap, writes part of the batch and finishes with a green check. The accounts it skipped keep old values.

**How Tray.ai helps:** Tray.ai treats a rate limit as a pause. It backs off, retries and resumes where it stopped. Every run compares rows attempted with rows written, and a gap fails the run instead of passing it.

### Full syncs that burn the API limit

Writing every row on every run uses the daily Salesforce API allowance and hides the few changes that mattered.

**How Tray.ai helps:** Only rows whose values changed since the last successful run are written. Large loads use the Salesforce Bulk API, which needs far fewer calls.

### Renamed fields and changed picklists

An admin renames a Salesforce field or changes a picklist value. The load fails, or it succeeds with an empty column.

**How Tray.ai helps:** Field mappings are visible in the workflow and change without code. A value Salesforce will not accept fails loudly and goes to a review list, instead of being written as blank.

### Deleted and merged records

A sync that reads only changed records never sees a delete or a merge. The warehouse keeps records that no longer exist, and writes back to IDs that are gone.

**How Tray.ai helps:** The workflow reads deleted records too, which the Salesforce API returns on request, and records which account a merged record moved into. The warehouse and the write-back both follow the surviving record.

## Learn more

- Intelligent Integration: https://tray.ai/platform/intelligent-ipaas/
- Merlin Agent Builder: https://tray.ai/platform/merlin-agent-builder/
- Agent Gateway for MCP: https://tray.ai/platform/agent-gateway/
- Book a demo: https://tray.ai/contact/