Salesforce's Help Agent graph resolves a tenant ID into customer context under 200 ms at P50

The Q&A labels the roughly 400-millisecond figure a benchmark of the earlier solution, and the sub-200 figure a P50 seen in live monitoring ^[5][6]. Those are two different instruments. Taken at face value, the later number is under half the earlier one ^[7]. The gap spans both a design change and a change in how the number was measured.

Data 360 data graphs do the joins, the aggregation, the relationship management and the business logic before an agent ever asks ^[2]. The work moved. At request time the agent hands over a tenant ID and gets context back, instead of running its own queries, joins and mappings ^[3]. Knowing the access patterns in advance also lets the team build indices and read the relevant rows instead of scanning tables ^[15].

The design choice is graph granularity. A graph that is too large costs performance; graphs that are too small have to be joined at retrieval time, recreating the aggregation problem ^[14]. The team's stated method is to work out how agents will actually use the data, then split context into smaller graphs or multi-graphs ^[13]. That ties the latency figure to a predicted set of questions, while the same write-up frames the modeling requirement as many-to-many relationships for agents that can ask questions nobody anticipated ^[18].

Identity is the harder half of the problem: information sits in different systems, one customer can have several product deployments, and one product can span several customers ^[9]. The relationships between individual, account, tenant, organization, products, utilization, services and entitlements all have to survive the modeling ^[10]. Smith said the question of who a customer is sounds simple, and that in enterprise data it is not ^[17].

The broader identity graph stays in its own data space, and a filtered view is exposed to the customer success data space, locked down for specific agent-context and outreach use cases ^[12]. Isolation is enforced in the storage layout. Salesforce's stated reason is that a customer success view must not mix prospect data, or one customer's information with another's ^[11].

For the sub-200 median to mean anything on another stack, a few conditions have to hold. The caller needs a stable key at request time, the way the Help Agent has a tenant ID ^[3]. Agent questions need to land inside a small number of graphs, because a cross-graph question pays the join at retrieval ^[14]. Identity resolution has to be finished before the request arrives. That is the premise of the whole design ^[2]. Salesforce did not publish P90 or P99 for the same path, the payload each call returns, or the query volume behind the median ^[19].

Data 360 also means the team did not have to build dedicated compute, autoscaling, REST APIs and identity-serving infrastructure to reach that performance ^[16]. That is a saving in engineering time, and it is counted separately from the milliseconds. It also means the 200 milliseconds is a property of Salesforce's own serving path, measured on Salesforce's own customer data.