How CRM Analytics Fits: Architecture & Data Flow

Now that you know what CRM Analytics is, let's look at how it fits together. You do not need to memorize an engineering diagram, but a simple mental map of the architecture and data flow will make every later lesson — data sync, recipes, live connections — click into place. The clip above walks through this at a high level; here is the same picture in words.

Getting data in

CRM Analytics is only as useful as the data you feed it, so it offers several on-ramps:

• Native Salesforce connector — the star of the show. Because CRM Analytics lives inside Salesforce, it can pull from your standard and custom objects with no extra middleware, drivers, or exports. Point it at Accounts, Opportunities, Cases, and it just works.
• Connectors to other clouds & databases — prebuilt connectors reach out to external systems (other Salesforce orgs, marketing clouds, data warehouses, databases) to bring their data alongside your CRM data.
• CSV upload — for one-off or ad-hoc data, you can upload a CSV file directly. Perfect for a quick spreadsheet of targets or reference data.
• ETL / API ingestion — for anything more industrial, an external ETL tool or the analytics API can push data in on a schedule.

Where the data lands: datasets

However data arrives, it ultimately lands in datasets. A dataset is CRM Analytics' optimized, columnar storage format, engineered for fast queries over large volumes. Once you have datasets in place, the real fun begins:

• Combine datasets — join or blend multiple sources so a single analysis can span, say, opportunities and external revenue data.
• Create derived fields — compute new values (ratios, buckets, flags) that did not exist in the source.

This is where raw data becomes a shaped, analysis-ready model.

Live vs. replicated data

Not every source needs to be copied. CRM Analytics supports two philosophies:

Replication gives you blistering speed and the ability to blend and transform freely. Live/Direct Data gives you freshness and avoids storing another copy. Real-world architectures often use both, choosing per source based on volume, freshness needs, and governance.

Getting data back out

The flow is bidirectional. CRM Analytics is not a dead end where data goes to be viewed and forgotten. Through output connections, it can push results back out to other systems — for example to AWS S3, Snowflake, or Tableau Hyper extracts. That means the shaped, enriched, or scored data you build here can feed downstream warehouses, other BI tools, or data lakes.

Dedicated, virtualized compute

Here is the architectural detail that ties it all together, and it echoes the previous lesson. CRM Analytics runs on dedicated, virtualized compute — separate from the transactional database that powers your live Salesforce app.

Why does this matter? Analytics is heavy. Scanning millions of rows, joining datasets, and training models would grind an operational database to a halt and hurt every user trying to save a record. By running analytics on its own compute layer against optimized datasets, CRM Analytics keeps your day-to-day CRM snappy while still crunching serious volume behind the scenes.

The big picture

Put it together and the flow reads left to right, then back:

1. Sources — Salesforce, other clouds, CSV, external systems.
2. Ingestion — connectors, upload, ETL/API, or live connection.
3. Datasets — optimized storage where data is combined and enriched.
4. Analysis & intelligence — on dedicated compute.
5. Output — back to S3, Snowflake, Hyper, or into dashboards for users.

Keep this map in mind. In the next lesson we zoom into the data layer itself — sync, recipes, dataflows, and the datasets that make all of this fast.