Connect Salesforce to AI Dashboards and Agents

Salesforce reporting is genuinely good at what it does. Pipeline rollups, forecast categories, activity summaries — if the question lives entirely inside the Salesforce object model, the answer is probably one report type away. The problem is that the interesting questions almost never live entirely inside Salesforce.

"Which closed-won deals are actually paying us?" requires Stripe. "Does pipeline coverage predict revenue accurately, or do we always close 40% less than the forecast says?" requires historical actuals from billing. "Which rep's deals have the highest product adoption?" requires your product database. None of these data sources exist in Salesforce, and Salesforce's reporting engine has no mechanism to reach outside its own schema.

This is where teams either build an export-to-spreadsheet ritual, spin up a warehouse pipeline, or connect Salesforce to something that can query across sources natively. Here's how the Fastero integration works and why it matters.

What SOQL can't do (and why it matters)

SOQL is a query language designed to traverse Salesforce's object graph. It's good at that specific job. It is not SQL, and the gaps are not cosmetic — they shape what analysis is even possible inside Salesforce.

No JOINs. SOQL uses relationship queries — parent-child traversals that follow the object model's predefined relationships. You can pull Opportunities with their related Contacts, but you cannot arbitrarily join two objects that don't have a declared relationship. Need to correlate Activities with Opportunities by a shared custom field? You're writing two queries and stitching the results in Apex or a spreadsheet.

No window functions. ROW_NUMBER(), LAG(), RANK() — none of them exist. Stage conversion analysis (how long does each deal spend in each stage?), running totals, and cohort comparisons all require window functions that SOQL simply doesn't support. You end up exporting the data and doing the analysis elsewhere, which defeats the purpose of having a query language.

No subqueries in WHERE against unrelated objects. You can filter by a parent relationship (WHERE Account.Industry = 'Technology'), but you cannot write WHERE Id IN (SELECT OpportunityId FROM some_unrelated_table) unless that relationship is declared in the schema. Cross-object filtering is structurally limited to what Salesforce's data model anticipated.

Governor limits. Every SOQL query runs inside Salesforce's execution limits: 50,000 rows returned per query, 100 SOQL queries per transaction in Apex, and API call quotas that vary by edition. These exist for good architectural reasons — Salesforce is multi-tenant and protecting the shared infrastructure matters — but they turn large-scale analysis into a pagination exercise. Pulling 200,000 Opportunity history records for a forecast-accuracy analysis means batching across multiple API calls, tracking cursors, and reassembling results.

Standard SQL has none of these constraints. Once Salesforce data is synced into a queryable store, you write the same SQL you'd write against Postgres or BigQuery — JOINs, window functions, CTEs, subqueries, no row limits.

How the connection works

Fastero connects to Salesforce via OAuth 2.0 — the standard authorization flow, no API keys to manage or rotate. You authenticate with your Salesforce credentials, grant access to the objects you want to sync, and the connection is established.

Object sync is configurable. You choose which objects to include — Opportunities, Accounts, Contacts, Leads, Activities, Cases, custom objects — and Fastero pulls them on a schedule into its cross-source DuckDB store. Each object becomes a table you can query with standard SQL. The sync runs incrementally by default: only records that changed since the last sync are pulled, which keeps API usage well within Salesforce's quotas even on large orgs.

Custom objects sync the same way. If your Salesforce org has Renewal__c or Product_Usage__c custom objects, they appear in the object picker alongside standard objects. Fields, relationships, picklist values — everything comes through.

Schema changes are handled automatically. When a Salesforce admin adds a field to an object, the next sync picks it up. No manual mapping updates, no broken pipelines because someone added a Renewal_Risk__c picklist you didn't anticipate.

Pipeline analytics you can actually build

Once Salesforce objects are queryable as standard SQL tables, the analysis that was painful or impossible in native Salesforce becomes straightforward.

Pipeline coverage ratio by quarter:

SELECT
  DATE_TRUNC('quarter', close_date) AS quarter,
  SUM(CASE WHEN stage NOT IN ('Closed Won', 'Closed Lost') THEN amount ELSE 0 END) AS open_pipeline,
  SUM(CASE WHEN stage = 'Closed Won' THEN amount ELSE 0 END) AS closed_won,
  ROUND(
    SUM(CASE WHEN stage NOT IN ('Closed Won', 'Closed Lost') THEN amount ELSE 0 END)
    / NULLIF(SUM(CASE WHEN stage = 'Closed Won' THEN amount ELSE 0 END), 0),
    2
  ) AS coverage_ratio
FROM salesforce_opportunities
WHERE close_date >= DATE_TRUNC('quarter', CURRENT_DATE) - INTERVAL '4 quarters'
GROUP BY 1
ORDER BY 1;

Forecast vs. actual by quarter — the query your CFO actually wants:

WITH forecast AS (
  SELECT
    DATE_TRUNC('quarter', close_date) AS quarter,
    SUM(amount) AS forecasted_amount
  FROM salesforce_opportunities
  WHERE forecast_category IN ('Commit', 'Best Case')
    AND snapshot_date = DATE_TRUNC('quarter', close_date)  -- forecast as of quarter start
  GROUP BY 1
),
actual AS (
  SELECT
    DATE_TRUNC('quarter', close_date) AS quarter,
    SUM(amount) AS actual_closed
  FROM salesforce_opportunities
  WHERE stage = 'Closed Won'
  GROUP BY 1
)
SELECT
  f.quarter,
  f.forecasted_amount,
  a.actual_closed,
  ROUND((a.actual_closed / NULLIF(f.forecasted_amount, 0)) * 100, 1) AS accuracy_pct
FROM forecast f
JOIN actual a ON f.quarter = a.quarter
ORDER BY f.quarter;

Rep performance with stage velocity — window functions that SOQL cannot express:

SELECT
  owner_name,
  COUNT(*) AS total_opps,
  SUM(CASE WHEN stage = 'Closed Won' THEN 1 ELSE 0 END) AS wins,
  ROUND(AVG(CASE WHEN stage = 'Closed Won' THEN amount END), 0) AS avg_deal_size,
  ROUND(AVG(
    EXTRACT(DAY FROM closed_date - created_date)
  ), 1) AS avg_days_to_close
FROM salesforce_opportunities
WHERE created_date >= CURRENT_DATE - INTERVAL '6 months'
  AND stage IN ('Closed Won', 'Closed Lost')
GROUP BY owner_name
ORDER BY wins DESC;

None of these queries are exotic SQL. They're the kind of analysis every RevOps team wants, written in the same SQL you'd write against any other database. The difference is that you're writing them against Salesforce data without SOQL's constraints.

Cross-source joins: where it gets interesting

Salesforce data alone produces CRM reports. Salesforce data joined with other sources produces business intelligence.

Opportunities joined with Stripe payments. This is the query from our CRM-billing reconciliation guide, but with live-synced data instead of manual exports. Match Opportunities to Stripe subscriptions by email or account domain, compare the CRM deal amount against what Stripe actually collected, and surface deals where the numbers don't agree. At scale, this is the difference between knowing you have a revenue leak and guessing.

Pipeline data joined with product usage. Connect your product database alongside Salesforce, and suddenly you can answer "do deals where the prospect used the trial extensively close at a higher rate?" — a question that requires data from two systems that have no native awareness of each other.

Salesforce Leads joined with ad spend. Connect Google Ads or Meta Ads, join against Salesforce Leads by UTM parameters or campaign IDs, and calculate true cost-per-qualified-lead — not the ad platform's self-reported number, but your number, based on which leads actually became Opportunities.

The cross-source DuckDB store handles the join mechanics. Each connected source becomes a set of tables in the same query environment. You write a JOIN the way you normally would — no federation layer to configure, no ETL pipeline to maintain.

Reverse ETL: pushing data back to Salesforce

Analysis that stays in a dashboard is useful. Analysis that flows back into Salesforce where reps actually work is more useful. Fastero's reverse ETL lets you define a query, map the output columns to Salesforce fields, and sync on a schedule.

Practical use cases: push a computed lead score (based on product usage + firmographic data from your warehouse) back to a Lead_Score__c field on the Lead object. Push a customer health score that combines support ticket volume, product activity, and billing status back to an Account custom field. Push usage metrics — DAU, features adopted, last active date — so the AE sees them on the Account page without leaving Salesforce.

The sync runs on Salesforce's Bulk API v2, handles upsert matching on external IDs, and respects rate limits. The details of making that work reliably are covered in depth in our reverse ETL guide.

The Einstein Analytics question

Salesforce's own answer to these limitations is CRM Analytics (formerly Einstein Analytics, formerly Tableau CRM). It's real software — external data connectors, cross-object dataflows, SAQL queries, and dashboards that go well past what standard reports allow.

It's also $150/user/month on top of your existing Salesforce licensing. For a 20-person revenue team, that's $36,000/year before you've written a single dataflow. And the learning curve is nontrivial — SAQL is its own query language (not SQL, not SOQL, a third thing), dataflow transformations use a JSON-based recipe format, and the builder expects a level of data modeling fluency that most RevOps teams don't have time to develop.

If you already have Einstein licensed and a team that knows SAQL, use it — you're paying for exactly this problem. If you don't, and the core need is "query Salesforce data with real SQL, join it with Stripe and product data, and build dashboards my CFO can read," there's a simpler path that doesn't require a six-figure annual add-on to your Salesforce contract.

Getting started

Connect Salesforce in Fastero via OAuth. Pick the objects you want to sync. Wait for the initial pull — usually a few minutes for a typical org, longer for very large custom object tables. Then write SQL, ask questions in natural language, or let the AI agent build the dashboard for you.

The query that usually matters first: how your CRM revenue compares to what you've actually collected. Start there.

Try Fastero free — connect Salesforce via OAuth, sync your objects into queryable tables, and join with Stripe, product data, or anything else. No credit card required.