Salesforce Data Graphs - Best Practices, Limits & Guardrails — 2026 Edition

Naming note: Salesforce has rebranded Data Cloud as Data 360. This post uses the new name; everything here applies to orgs still seeing the old label.

What a Data Graph really is

A Data Graph is a pre-computed, denormalized view of your customer data. You pick a primary Data Model Object (DMO) inside a Data Space, attach related DMOs, calculated insights, and segment memberships, and Data 360 joins all of that into a single read-only JSON blob per primary key. That blob is what gets queried - not the underlying tables - which is why Data Graphs can return sub-second responses even when the source data spans hundreds of millions of rows.

High-level architecture: bounded inputs flow into a pre-computed graph, which many consumers read cheaply.

There are two flavours, and the difference matters more than most teams realize on day one:

•Near real-time Data Graph - the default. Refreshes on a schedule (every 30 minutes on Marketing Cloud data graphs, hourly, every 4 hours, daily, weekly, or monthly). Good for almost every CRM-surface and offline-query use case.

•Real-time Data Graph - requires the Real-Time SKU. Sub-second updates driven by streaming ingestion and engagement events. Use it for web personalization, in-session decisioning, or anywhere a stale value would be visibly wrong to a customer.

Don't default to real-time because it sounds better. Real-time graphs cost more, have stricter size limits, and only earn their keep when latency genuinely changes the user experience.

Eight best practices

1.Start from the use case, not the data model

The most common mistake we see is teams treating a Data Graph like a reporting view - "let's include everything, just in case.” That is the path to slow refreshes and bloated JSON. Before you add a single related object, write down the consuming application: is it a Lightning component on the Account record, an Agentforce prompt, a Marketing Cloud personalization call, or an external API consumer? Each one has a different latency tolerance and a different field shopping list. Build the graph against that list.

2.Keep the graph narrow and shallow

Every related DMO you add increases both the JSON size and the work Data 360 has to do at refresh time. As a rule of thumb, keep one graph focused on one consuming surface. If your primary DMO is Individual and you find yourself attaching loyalty, transactions, web events, support cases, and product catalog all into the same graph, that is a sign you actually need two or three smaller graphs. Smaller graphs refresh faster, fail less often, and are easier to reason about when something goes wrong.

3.Watch out for unbounded 1:N explosions

This is the single biggest performance pitfall. When a related DMO has a 1:N relationship with the parent, every related row gets denormalized into the JSON — multiplied by the cardinality. If a customer has 4,000 web events and you naively attach the engagement DMO without filters, that customer's graph record balloons. Use the Data Recency filter on engagement DMOs (last N days, last N records) and treat any 1:N relationship as guilty until proven innocent. If you cannot bound the cardinality, leave the DMO out of the graph and query it separately at the application layer.

4.Choose the relationship path deliberately

When more than one path exists between the primary DMO and a related object, Data 360 will offer them all. The longer the path, the more joins, the slower the refresh. Pick the path that matches your business meaning, not the first one in the list — and document why you picked it. Future-you will be grateful when the data model evolves and the wrong path silently changes what the graph returns.

5.Match refresh frequency to the actual freshness requirement

Hourly refresh is roughly 24 times more expensive than daily refresh, and most use cases do not need it. Ask the consumer: how stale is acceptable? In practice, CRM-surfacing use cases are nearly always fine on daily; service-recovery and cross-sell use cases tend to want hourly; only true in-session personalization needs the real-time SKU. We have seen organizations cut Data 360 credit consumption on insights and graphs by more than 90% simply by moving non-critical graphs from hourly to daily.

6.Calculated insights belong in the graph only when they're hot

You can add calculated insights to a Data Graph as long as the underlying DMO is also in the graph and the DMO's primary key is configured as a dimension on the CIO. That is powerful — a Lifetime Value or Churn Risk score is exactly the kind of attribute you want pre-computed for downstream consumers. But every CI you add gets pre-calculated on every refresh. Include the ones you actually use on the surface; query the rest on demand.

7.Treat the data model as a prerequisite, not a side quest

Data Graphs only perform well if the joins underneath them are clean. If your relationships are configured with fuzzy keys, missing foreign keys, or Profile-vs-Other category mismatches, the pre-calculation step will be slow and brittle. Before scaling out Data Graphs, do the un-glamorous work: confirm primary and foreign keys, validate identity resolution rulesets, and make sure each DMO is sitting in the right category (Profile, Engagement, Other).

8.Test the JSON shape before consumers depend on it

Click Preview before you Save and Build. Then query the graph through the Data 360 Query API with a representative primary key, and hand the resulting JSON to the consuming team. Catching a renamed field or a missing dimension at design time is free. Catching it after a Lightning component, a flow, or an Agentforce action is bound to it costs a release cycle.

Limits and guardrails

These are the ceilings and the warning lines. The hard limits come from Salesforce; the soft guardrails are what we recommend you stay well below for sane operations. Always check the current Data 360 limits and guidelines page in Salesforce Help — numbers can change release-to-release. (All figures below re-verified against Salesforce documentation, July 2026.)

A note on credits

Billing on Data Graphs is primarily driven by how many rows are processed at each refresh, not by how many times you query the graph afterwards. That is what makes them efficient — calculate once, read many times. The corollary is that every additional related DMO, every shorter refresh interval, and every overly broad recency filter shows up directly on the consumption invoice. If you want a quick optimization win, the highest-leverage levers are: (1) drop unused related DMOs, (2) lengthen the refresh interval where you can, and (3) tighten engagement recency filters.

Anti-patterns to avoid

•"One giant graph to rule them all.” Massive graphs with every DMO attached. They refresh slowly, breach size limits on real-time, and become impossible to debug.

•Real-time by default. Choosing the real-time SKU because it sounds better, when the consuming surface is a nightly batch or a dashboard.

•No recency filter on engagement. Pulling in every web event a customer has ever generated. Cardinality eats the JSON and the refresh.

•Skipping the data model review. Building graphs on top of unresolved identities or sloppy join keys. The graph is only as good as the model under it.

•Treating drafts as production. Drafts cannot be refreshed and cannot be cloned. If something is real, save and build it.

Rollout checklist

• A short list to run through before you flip a Data Graph live:
• Use case, consumer, and latency tolerance are written down and agreed.
• Primary DMO and data space are correct; identity resolution is healthy.
• Related DMOs are bounded — every 1:N relationship has a recency filter.
• Calculated insights included are actually consumed by the surface.
• Refresh interval matches the freshness requirement, not the team's ambition.
• JSON preview reviewed by at least one consumer-side developer.
• Naming convention is consistent (use case, data space, owner) so it is findable in six months.
• Owner and review date are recorded somewhere outside Data 360.

The bottom line

A Data Graph is a contract between your data model and your consuming surface. Keep it narrow, bound every 1:N, refresh no faster than the use case demands, and test the JSON before anyone depends on it. Do those four things and Data Graphs become the cheapest fast path to customer data in the Salesforce stack - skip them and they become your biggest line item.

References

•Salesforce - Step-by-step Guide: Data Graphs (PDF): salesforce.com/en-us/wp-content/uploads/sites/4/Data-Graphs.pdf

•Salesforce Help Data Graphs: help.salesforce.com/s/articleView?id=data.c360_a_data_graphs.htm

•Salesforce Help - Data 360 Limits and Guidelines: help.salesforce.com/s/articleView?id=sf.c360_a_limits_and_guidelines.htm

•Salesforce Help - Real-Time Capabilities in Data 360: help.salesforce.com/s/articleView?id=sf.c360_a_real_time_capabilities.htm

•Salesforce Help - Reduce Credit Consumption in Data 360

•Salesforce Engineering - Data Graph: Sub-Second Insights from 200M Records: engineering.salesforce.com/how-data-clouds-data-graph-delivers-sub-second-insights-from-200-million-records/

•Trailhead - Explore and Manage Data Graphs in Data 360