You are here:
Grounding Service Assistant with Agent Actions
Learn how Service Assistant uses agent actions to automate plan steps and review our recommended configuration guidelines.
Required Editions
| View supported editions. |
Agent actions let Service Assistant automate plan steps on behalf of the service rep.
Agent actions are an optional grounding source that lets Service Assistant automate the completion of plan steps. When plan steps are created, Service Assistant uses action descriptions to identify specific tasks that can be automated based on the information found in the record, subagent instructions, and knowledge that are used to ground the step. When a match is identified, Service Assistant adds the action to the plan step.
This article details how to apply general Agentforce action guidelines specifically to service plans. Service Assistant follows standard Agentforce configuration requirements, and we provide more configuration guidelines for action descriptions and input and output instructions. This metadata is important because it lets Service Assistant match actions to the context of the record, subagent instructions, and knowledge articles.
The guidelines in this article provide details on how to write action descriptions and input and output configurations, and how that action metadata is matched against the record data and relevant grounding sources to surface in a plan step. Most of these guidelines focus on getting actions to surface automatically in dynamic plan steps.
The guidelines for configuring your action metadata apply to both service plan types, but actions behave differently in guidance and dynamic plans.
- With guidance plans, Service Assistant executes actions only in a reactive capacity. Service reps use the agent chat to ask Service Assistant to launch actions, such as drafting an email or updating a record. After the action runs, Service Assistant waits for the service rep's next instruction. It doesn't guide the service rep to the next step or recommend another action.
- With dynamic plans, Service Assistant creates each step in real time. As it builds a step, it reviews the latest record data, subagent instructions, and knowledge articles to make the step as accurate as possible. Service Assistant identifies opportunities to automate the step by comparing the details found in the record data and your grounding sources with the action description and input and output instructions.
Genearal Details About Actions in Service Assistant
Before you review the configuration guidelines, here are a few key points about actions in Service Assistant.
- Service Assistant supports standard and custom Agentforce actions.
- Because actions rely on your specific business requirements, we don't provide prebuilt actions for Service Assistant.
- Service Assistant supports the use of custom Lightning types. Setup of custom Lightning types follows all configuration guidelines and best practices in Agent Action Custom Lightning Types.
- You can assign context variables to action inputs so Service Assistant automatically passes session information, such as the current record ID, into the action at session start. See Grounding with Context Variables.
- By default, Service Assistant can run a matched action automatically. For any action that requires human confirmation before it runs, such as closing a case, turn on Require User Confirmation on the action. See Action Confirmation.
Agent Actions Permissions
All actions execute in the context of the ServicePlanner User. Grant the ServicePlanner User the permissions to access the functionality your actions rely on, such as Apex classes, flows, and prompt templates. Action permissions follow the guidelines in Common Access for Actions. Here are a few more details to keep in mind.
- Apex class access. Explicitly grant the ServicePlanner User access to each Apex class the action calls. Without it, the action fails with a generic error message.
- Apex sharing mode. Use actions that query customer data without sharing in the Apex class. If the class uses sharing, the query can return zero results with no error message.
- Object permissions. Grant Read access on any object the action queries. If the action also creates or updates records, add Create and Edit access.
- Field-level security. Object-level Read access isn't enough. Each field the action reads needs explicit Read access granted on the permission set. Without it, Salesforce returns blank values, which can look like a data problem but is a permissions issue.
- How Service Assistant Matches Actions to Plan Steps
Service Assistant automatically adds actions to plan steps by comparing your action descriptions and input and output instructions against the record details and grounding sources. - Guidelines for Creating Actions
Follow these guidelines to write effective action descriptions and to set up Service Assistant action inputs and outputs.
