How do you decide what data should be included in a Data Graph for real-time Agentforce use cases?

Question

Hi Trailblazers,

I’m exploring Data Graphs in Data 360 for real-time Agentforce use cases.

Since a Data Graph can bring related customer information together for faster access, I’m interested in understanding how teams decide what data should be included.

Do you mainly consider relationship depth, response time, business relevance, data volume, or how frequently the data is accessed by Agentforce?

Also, have you seen performance issues when too many related objects or attributes are included in a Data Graph?

Would love to hear some real implementation experiences.

#Data360 #Agentforce #Salesforce #AI

Venkat Yadav · Accepted Answer

Hi  @Santhosh Gorantala https://trailblazers.salesforce.com/profileView?u=005KX000003f3CNYAY   Good question! I think the main thing is to include only the data that Agentforce actually needs, rather than bringing everything into one Data Graph.    A few things I would consider: Business Use Case:  First, understand what questions the agent needs to answer and what data is required. Relevant Data:  Include only necessary objects and fields. Avoid adding unnecessary information. Relationships:  Keep relationships simple. Too many related objects can make things complex. Data Volume:  Be careful with large datasets and historical records. Performance:  Test how quickly Agentforce can retrieve the required information. For example, if we're building a customer support agent, I would start with Account, Contact, recent Cases, and Orders instead of bringing in the entire customer history.   And yes, adding too many related objects or attributes can increase graph size and potentially impact performance.    My suggestion would be to start small, test with real-world scenarios, and add more data only when it's actually needed.    At the end of the day, Agentforce needs the  right information at the right time , not every piece of data available.    Hope this helps!    Thank you,  Venkat Yadav.

Deepak Sachdeva · Answer

Hi  @Santhosh Gorantala https://trailblazers.salesforce.com/profileView?u=005KX000003f3CNYAY ,   I decide what goes into a Data Graph by starting from the Agentforce use case and working backwards:    Start with the question the agent must answer.  For example, "what is this customer's recent orders and open cases?" Only include the objects and fields the agent needs to answer that. Business relevance comes first. Choose the primary DMO carefully.  It decides which related objects you can add. For customer use cases, the Unified Individual is the usual starting point. Pick the type by freshness needed.  A standard data graph refreshes on a schedule, which can take minutes to hours. A real-time data graph updates continuously, but it needs the Real-Time SKU, and it has limits. It supports only 1:1 and 1:N relationships, and the join must use the parent's primary key. Keep it small.  A data graph turns the data into one JSON record, so every extra object and field makes that record bigger and slower to build and read. Include only the fields you really use, and leave out large or rarely used data. Mind the cost.  For real-time graphs, the consumption limits (record caching and session length) affect cost and performance, so set them on purpose. On performance: I would expect larger graphs to take longer to build, because Salesforce notes that processing time depends on the size of the primary DMO and the related objects. Please test with real data volume before going live. How many objects are you planning to include?

How do you decide what data should be included in a Data Graph for real-time Agentforce use cases?

Agentforce

Related Learning

More Help