Salesforce

Building a Salesforce Agentforce Agent to Read and Manage Case Information

Agentforce lets you build a conversational AI layer directly on top of Salesforce Service Cloud — one that can read case details, update fields, and close tickets without a human agent touching the keyboard.

Ritik Jain
Sr. Salesforce Developer
June 11, 2026
7 min

Customer support teams handle enormous volumes of case tickets, and a significant portion of those interactions follow predictable patterns. What is the status of this case? What is the priority? Can this be closed? These are questions that do not require human judgment — they require accurate data retrieval and a reliable response. They are exactly the kind of interactions that an AI agent should be handling automatically. With Salesforce Agentforce, building an agent that reads, summarizes, and updates Case records is achievable through a combination of low-code configuration and structured Flows — no deep engineering required. This guide walks through the complete process, from defining the agent's role to deploying and monitoring it in production.

What Agentforce Is and How It Works

Agentforce is Salesforce's AI agent builder — a platform for creating conversational agents that integrate directly with Salesforce data and business logic. Understanding its four core components is the prerequisite for building anything on it.

Agent Builder is the low-code interface where the agent is defined — its role, its conversational scope, its available actions, and the guardrails that constrain its behavior.

Topics are conversational intents — the specific kinds of requests the agent is designed to handle. A topic called Case Processing, for example, would cover any user request related to reading or modifying a case. Topics are how the agent understands what a user is trying to accomplish.

Actions are the business logic that executes when a topic is triggered. Actions map directly to Salesforce operations — retrieving a record, updating a field, closing a case. They are implemented as Flows, invocable Apex methods, or REST API calls registered as agent actions.

Flows are the implementation layer for most agent actions. When a topic triggers an action, a Flow runs to execute the actual Salesforce operation — getting records, updating data, returning results to the agent's response.

Step 1: Define the Agent Role and Purpose

In Agentforce Builder, create a new agent. Give it a clear, specific name — Case Info Agent — and write a role description that the platform will use to scope its behavior: "This agent reads case records when asked, summarizes key information including status, priority, and description, and can update case fields or close cases when requested." From the beginning, configure the agent's permissions with the principle of least privilege. The agent should have read access only to the Case fields it needs to surface — CaseNumber, Status, Priority, Description, Owner, CreatedDate — and write access only to the fields it is permitted to update. An agent with broader permissions than its function requires is a governance risk that compounds at scale.

Step 2: Model the Topics

Three topics cover the core case management scenarios this agent needs to handle.

GetCaseInfo covers requests like "What is the status of case 00012345?" or "Tell me about this case." When this topic triggers, the agent retrieves the case record and returns a structured summary.

UpdateCasePriority covers requests like "Change the priority of case 00012345 to High." When triggered, the agent updates the Priority field on the specified case record.

CloseCase covers requests like "Close case 00012345" or "Mark this case as resolved." When triggered, the agent updates the Status field to Closed or the appropriate terminal status in your org's configuration.

For each topic, you define two things: natural-language instructions that tell the agent how to interpret user messages that match this intent, and the action that should execute when the topic is triggered.

Step 3: Create the Actions

Each topic needs a corresponding action that performs the actual Salesforce operation.

Get Case Record action takes a CaseId or CaseNumber as input and retrieves the case from the database. It returns the fields the agent needs to construct its response — status, priority, description, owner, creation date, and any other relevant metadata.

Update Case action takes a case identifier and the field values to change. It updates the specified fields on the case record and confirms the update to the agent for inclusion in its response.

Close Case action takes a case identifier and updates the Status field to the org's configured closed value. It can optionally capture a resolution comment or set additional closure fields depending on your org's process requirements.

Step 4: Configure the Flows

Each action is backed by a Salesforce Flow. Build these as autolaunched flows invoked by Agentforce, with input variables matching the parameters each action requires.

The Get Case Record flow accepts CaseId or CaseNumber as an input variable, uses a Get Records element to retrieve the case from the Case object, and returns the required field values as output variables that the agent incorporates into its response.

The Update Case flow accepts a case identifier and the field values to update, uses an Update Records element to apply the changes, and returns a confirmation status to the agent.

The Close Case flow follows the same pattern as the update flow but targets the Status field specifically, setting it to the correct closed value for your org's stage configuration. In each flow, build explicit error handling for the scenarios that will occur in production: an invalid case number, a case that cannot be found, a permission error on the update. When errors occur, the flow should return a meaningful message that the agent can communicate to the user — "I could not find a case with that number, can you verify it?" — rather than failing silently or surfacing a system error.

Step 5: Add Guardrails and Instructions

Guardrails define what the agent must not do — the boundaries of its authority. Configure guardrails that prevent the agent from closing high-severity cases without human review, from modifying cases that are under escalation, or from accessing case data outside its permitted field set. Guardrails are the mechanism that keeps an automated agent operating safely within the boundaries your business requires. For each topic, write clear natural-language instructions. For GetCaseInfo: "When given a case number or ID, retrieve its status, priority, and description, and return a concise summary. If the case cannot be found, ask the user to verify the case number." For UpdateCasePriority: "When given a case number and a priority value, update the Priority field on that case and confirm the change." For CloseCase: "When asked to close a case, verify the case exists and update its Status to Closed. If the case is Priority High or above, escalate to a human agent rather than closing automatically." Configure human handoff for scenarios where the agent should escalate. Agentforce supports seamless escalation to a human agent when the automated path is inappropriate — high-severity cases, ambiguous requests, or situations where the user explicitly asks for a person.

Step 6: Apex and REST APIs for Complex Logic

For use cases that require more than straightforward record retrieval and update — combining Case data with related objects, applying complex business validation, or integrating with external systems — Apex REST provides the extension point. Write an Apex class annotated with @RestResource to expose a custom endpoint. Describe the API in OpenAPI format, register it in your org's API catalog, and configure it as an agent action in Agentforce. The Apex method can run SOQL across multiple objects, apply business logic, enforce org-specific rules, and return exactly the data structure the agent needs — giving you full flexibility for scenarios that exceed what a Flow can handle cleanly.

Step 7: Test With Plan Tracer

Before activating the agent, validate it thoroughly using Agentforce's Plan Tracer. This tool simulates user prompts, shows the agent's reasoning process — which topic it selected and why — and displays the actions it would execute in response. Test with representative inputs across all three topics: "What is case 000123?" to validate GetCaseInfo, "Set priority to High for case 000123" to validate UpdateCasePriority, and "Close case 000123" to validate CloseCase. Test edge cases including invalid case numbers, cases outside the agent's permission scope, and requests that should trigger human escalation. Confirm that the correct topic triggers for each input and that the correct flow executes in response.

Step 8: Deploy and Monitor

Once testing is complete, activate the agent. If automatic case summarization or field population on record creation is a requirement, configure a Record-Triggered Flow on the Case object to invoke the agent when new cases are created or when specific field conditions are met.After deployment, monitor agent performance actively. Track how frequently the agent successfully retrieves case information, how often it completes updates without human intervention, how many escalations to human agents occur and why, and whether any error conditions are surfacing repeatedly. This data drives the ongoing refinement of topic instructions, flow logic, and guardrail configuration that improves agent reliability over time.

"The best support interaction is the one that resolves itself — and Agentforce is the closest Salesforce has ever come to making that actually possible at scale. An agent that never sleeps, never forgets to check the case status, and never puts a customer on hold is not a future concept. It is a few flows and topics away."
Why This Approach Delivers Real Value

An agent of this kind operates continuously without scaling costs proportional to volume. It surfaces accurate, real-time case data every time because it reads directly from the Salesforce database rather than relying on cached or summarized information. It handles the repetitive, high-frequency queries that consume human agent capacity — freeing those agents for the complex, high-judgment interactions where their expertise genuinely matters. And it does all of this within the security and governance framework that Salesforce's permission model provides, because it runs as a configured user subject to all the same object and field-level security controls as any other org user.

Official References

Agentforce Agent Builder Overview:salesforce.com/in/agentforce/agent-builder

Build Case Automation on Agentforce in 9 Steps:admin.salesforce.com/blog/2025/inside-our-hackathon-build-case-automation-on-agentforce-in-9-steps

Build Secure and Compliant AI Agents With Agentforce:admin.salesforce.com/blog/2025/build-secure-and-compliant-ai-agents-automate-with-agentforce

Make Apex REST APIs Available as Agent Actions:developer.salesforce.com/blogs/2025/03/make-apex-rest-apis-available-as-agent-actions

Salesforce Service Cloud Case Management:salesforce.com/products/service-cloud/features/case-management-software

Salesforce Implementation That Actually Moves the Needle

Most Salesforce implementations go live. Ours go to work. We configure, integrate, and deploy Salesforce so your teams operate faster, your data works harder, and your business grows without the friction.