Test Dynamic Plans

• How to Test Dynamic Plans
• Draft and Evaluate the Service Plan Summary
• Case Summary Plan
• Messaging Summary Plan
• Troubleshoot Summary Error Messages
• Work and Review a Dynamic Plan
• Troubleshoot Knowledge Grounding

How to Test Dynamic Plans

A dynamic plan is a real-time plan that adapts as the record changes, available for both cases and messaging sessions. To test dynamic plans, generate them on records. Service Assistant provides service plans through a Lightning web component, so they can't be tested in the Agentforce Builder or Agentforce Testing Center. For general testing setup, how to pick use cases to test, and knowledge grounding guidance that applies to all plan types, see Test Service Assistant.

A dynamic plan has no set length or end time. Its length depends on how much the case or messaging session evolves and how much information your grounding sources hold to address the issue. Service Assistant adds steps as the record changes and the resolution progresses, so a plan grounded in richer sources and a longer conversation runs more steps than one with limited context. The plan ends automatically when the record closes, either when the case is closed or the messaging session ends and the chat terminates. The plan history is saved in the component feed and is accessible after the record is closed or ended.

Draft and Evaluate the Service Plan Summary

When a record meets your eligibility criteria, Service Assistant drafts a service plan summary that includes a summary of the record and a general overview of the resolution steps, known as summary steps. After the summary generates, the Start Plan button appears. You click Start Plan to begin the real-time, interactive workflow. When the summary generates depends on the record type.

As part of the summary, Service Assistant identifies the issue and assigns the matched subagent. Confirm that the correct subagent is assigned. For cases, Service Assistant assigns the subagent based on the Subject and Description fields set in your Service AI Grounding configuration. For messaging sessions, it assigns the subagent based on the context of the conversation transcript.

A summary plan can take up to one minute to show. The component shows no loading indicator. Every case summary begins with Service Plan Available: followed by the subagent name.

Case Summary Plan

To start the testing process, open an existing case or create a new one. Make sure that the case meets your eligibility criteria. When a case is opened or created, Service Assistant drafts the summary. Here is an example.

The level of detail of both the case summary and summary steps varies and is based on the amount of information in the case, what fields and objects you have set in your Service AI Grounding configuration, and the amount of information in subagents, instructions, and knowledge articles. Generally, when you have a more detailed service plan summary (as shown above), you can expect the drafted service plan to be fairly detailed.

Specifically, the Subject and Description fields are critical because Service Assistant uses them to categorize the case and match it to a subagent. Although Service Assistant grounds on additional fields and objects set in your Service AI Grounding configuration, the Subject and Description need clear, specific information to generate an accurate plan. Generally, the more detailed the fields are, the better the match.

Messaging Summary Plan

To start the testing process, open a messaging session that meets your eligibility criteria. Unlike a case, a messaging session doesn't generate a summary as soon as it's opened. Service Assistant generates the service plan summary only after the conversation has at least five total messages, and at least one of those messages contains information that matches your subagents and instructions.

• If the first five messages don't contain information that matches a subagent, Service Assistant keeps monitoring the conversation and generates the summary when a later message provides a match. Generating the summary can take more than five messages.
• To test this behavior, send messages that reflect the use cases in your subagents and confirm that Service Assistant generates a summary and identifies the matched subagent.

If the summary doesn't show for a messaging session, confirm these requirements are met.

• The user testing the plan has access to the eligibility flow, even if they have the Run Flows permission. The Run Flows permission alone doesn't grant access to the eligibility flow. See Service Plan Eligibility Criteria and Set Up Service Assistant for Messaging.
• The conversation has at least five total messages. A summary isn't generated before the conversation reaches five messages.
• The messaging session record is owned by a human agent, not a bot user. Service Assistant doesn't generate a plan for a record owned by a bot user.

Troubleshoot Summary Error Messages

If the plan summary generation doesn't start or you see the listed error messages, take these troubleshooting steps.

Error Messages

• We couldn't draft a service plan summary. We'll keep trying, but if the issue continues, contact your Salesforce admin.
• There's not enough information to draft a service plan summary. Add more details, then check back here.
• We couldn't draft a service plan because no relevant subagents exist. Ask your Salesforce admin to create one, or add more context to the item.

General Troubleshooting Steps

• Make sure you have the right permissions. Admins require the Service Planner Builder and Agentforce Default Admin permission sets. If you use knowledge grounding, make sure you have the Data Cloud Architect permission set with access to the default data space. Service reps require the Service Planner User permission set and Access Agentforce Default Agent permission set.
• Make sure the ServicePlanner User has these permission sets assigned: Service Planner Agent User, Agentforce_Service_Assistant Permissions, and Data Cloud User.
• Make sure your knowledge articles contain accurate, comprehensive, and well-structured information. Service Assistant includes knowledge information in the summary steps.
• If you see the error message "We couldn't draft a service plan because no relevant subagents exist. Ask your Salesforce admin to create one, or add more context to the item," this means that Service Assistant can't find a subagent that matches the record details. The previous troubleshooting steps apply. In addition, review your subagents and instructions. Make sure they follow the guidelines in Grounding Service Assistant with Topics and Topic Best Practices.
  • Make sure that relevant subagents and instructions are created for the record.
  • Make sure each subagent has a distinct title like "Return Request" or "Refund Request."
  • Don't create generic, catch-all subagents like "Case resolution assistance." Subagents describe your company's specific policies and standards for resolving a particular case type. A subagent titled "Case resolution assistance" is too broad and prevents Service Assistant from matching cases to the right subagent. Instead, create distinct subagents that each address one specific case category, such as "Product Defect Report," "Billing Dispute," or "Account Access Issue."
  • Break down case types into subagent categories. For example, use a broad subagent like "Return Request" for general information on how to process returns. This is best for when the case doesn't mention an explicit item. For return processes that vary in scope and processes, create individual return request subagents like "Shoe Return Request." These are simple examples, but the idea is to make sure that you have enough information in your subagents and instructions that try to address the varying levels of information a specific case can have.
  • Don't include several pieces of information in one instruction. Each instruction needs to outline a singular task or process that's required for resolving the issue.

Case Troubleshooting Steps

• Make sure the case has a clear, descriptive subject that relates to your subagent.
• Make sure the case has sufficient detail in the description about the issue or request. We recommend 1–2 sentences.
• Review your Service AI Grounding configuration. Make sure that all the fields and related case objects you want to ground on are selected. Then review the data of these fields in the case. Make sure there is clear and non-conflicting information in your grounding fields or case feed, comments, and emails. Conflicting information can result in less detailed or unclear case summaries and summary steps.

Messaging Troubleshooting Steps

• Service Assistant grounds in the conversation transcript rather than the Subject and Description fields. Make sure the conversation includes clear, specific details about the customer's issue so Service Assistant can match a subagent and generate focused summary steps.
• Confirm that the summary requirements are met: the conversation has at least five total messages, at least one message matches a subagent, the record is owned by a human agent and not a bot user, and the user testing the plan has access to the eligibility flow. See Messaging Summary Plan.

Work and Review a Dynamic Plan

After you have a successful plan summary, click Start Plan to begin the workflow. Unlike a guidance plan, a dynamic plan doesn't draft a full checklist at once. Service Assistant presents one step at a time, adapts each step as the record changes, and can surface agent actions to automate a step. As you work the plan, evaluate it for accuracy and relevance.

Review the Guidance at Each Step

• Review the guidance at each step to confirm it's accurate, relevant, and consistent with the resolution guidance in your subagents, instructions, and knowledge articles.
• Review the wording of each step, and confirm that any agent actions surface and execute as expected. When an action is available to complete a step, Service Assistant surfaces it in the step for you to confirm and run, or the action runs automatically based on your configuration.

Subagent-Based Steps

• Steps created from subagent instructions are formed directly from the guidance you provide in each instruction. From a sample service plan, a subagent-based step is "Conduct identity verification to ensure the user's eligibility for document processing."
• If a step relies only on a subagent (without knowledge grounding), it doesn't include any citation links.
• The subagent that matched to your case is used to generate the plan. The subagent name is listed at the top of the service plan.

Knowledge-Based Steps

Service plans are grounded in your knowledge articles when you set up a data library using the knowledge data type and have Show Sources enabled. See Set Up Knowledge Grounding.

Display and Navigation

• Each step created from a knowledge article is cited with a number at the end of the step in the form of [1]. The citation contains a hyperlink to the corresponding entry in the Sources section that lists the name of the knowledge article. To show citations, enable Show Sources in your data library setup.
• Because a dynamic plan creates each step in real time, each step has its own Sources section rather than a single Sources section for the whole plan. Confirm that each step's citations link to the article used for that step.
• The same article can appear under a different citation number from one step to the next. In a dynamic plan, citation numbers aren't consistent across steps because each step is created and cited on its own. This behavior is expected and differs from a guidance plan, where an article used in multiple steps keeps the same citation number.
• A step can be created from both a subagent and a knowledge article.
• A step can be created from multiple knowledge articles. This is indicated when you see two or more citations at the end of a step, like [1][2].

Non-Grounded Steps

Service Assistant can propose its own steps that aren't based on your grounding sources. Proposed steps show when there isn't enough information in your subagents, instructions, or knowledge articles. In a dynamic plan, Service Assistant flags a proposed step with language such as "There's no information in your company documents. Here's what I suggest, but it might not be correct." Use these flags during testing to find gaps in your grounding sources, and then add the missing guidance to your subagents, instructions, or knowledge articles.

Dynamic Plan Updates

A dynamic plan updates its steps in real time as new information arrives. Unlike a guidance plan, you can't redraft a dynamic plan. Instead, you update your grounding sources during the plan, and Service Assistant picks up the updates as they're made. How you test this behavior depends on the record type.

For cases, update the fields and objects set in your Service AI Grounding configuration and confirm that Service Assistant incorporates the changes.

• Service Assistant monitors the case through the fields and objects set in your Service AI Grounding configuration.
• Currently, only a new case email updates the step the rep is currently on, in real time. All other information, such as case comments, the case feed, and other grounding fields, is tracked and incorporated into the next step rather than the current step.

For messaging sessions, Service Assistant grounds the plan in the conversation transcript, so updates are highly real-time. Send new messages in the session and confirm that Service Assistant updates the plan as the chat feed advances.

• Service Assistant monitors the entire transcript and generates a new plan step as each new message comes in, so each step reflects where the conversation currently stands.
• Unlike a case, where only a new case email updates the current step, a messaging session updates step by step as the conversation progresses.

Test Agent Actions

In a dynamic plan, Service Assistant surfaces an agent action automatically when it matches the action to a plan step. As you work the plan, pay attention to which actions are presented and where they're missed. If an action you expect doesn't surface in a step, try these methods.

• Add a direct reference to the action in a subagent instruction. Reference the action by its label, not its API name, and tell Service Assistant when to use it. For example, "As a first step, use the Get Travel Records action." A direct reference forces Service Assistant to include the action, so use it for mandatory steps that must always run. See How Service Assistant Matches Actions to Plan Steps.
• Refine the action description. For situational steps that run only when conditions are met, Service Assistant relies on context matching, so write descriptions that mirror the terminology in your subagent instructions and knowledge articles. See Guidelines for Creating Actions.
• Check the action's permissions for the ServicePlanner User. Actions run under the ServicePlanner User's permissions, and a missing permission can cause an action to fail or return blank data. See Action Permissions.

After an action runs, Service Assistant sometimes prompts with open-ended language, such as "The record is updated. Let me know how to proceed," instead of advancing to the next step. To keep the plan moving, state what happens next in your subagent instructions, such as "After the action completes, immediately proceed to verify entry requirements." For more details on configuring and matching actions, see Grounding Service Assistant with Agent Actions.

Require Specific Information in a Plan

To make sure specific information always appears in a plan, put it in a subagent instruction. Use this technique when the information isn't pulled from your knowledge articles. Write the instruction to state exactly what you want and when, such as "As a first step, verify the customer's account status." Information stated this way in an instruction is always included in the plan.

Advance the Plan

Dynamic plans advance steps automatically when a step is completed with an agent action. For a step that isn't automated by an action, Service Assistant states what the service rep does manually to complete the step, and then it waits for the rep to confirm. This behavior is expected, and Service Assistant especially waits when you ask an informational question in the agent chat.

• For a step that isn't automated, Service Assistant describes the task to complete and prompts the rep with language such as "Let me know once this step is complete." The plan doesn't advance on its own.
• To move the plan forward, respond with language that clearly reflects that the step is complete, such as "Completed," "Step complete," or "Go to the next step." Service Assistant then generates the next step.

Generally, work through the resolution guidance and evaluate the wording of each step for accuracy and consistency with your service specialists and your knowledge and subagent instructions.

Subagent Switching

Service Assistant detects the customer's intent as the case progresses and can switch to the relevant subagent to provide guidance from that subagent and its related knowledge information. Test this behavior by introducing a second issue and confirming that Service Assistant switches subagents.

• If the resolution starts with one subagent's issue but shifts to a second issue, Service Assistant switches to the second subagent, gathers the information it needs, and resolves that part of the plan.
• When the second issue is resolved, Service Assistant can automatically switch back to the original subagent. In some instances, it doesn't switch back on its own. Use the chat to redirect it, such as "Let's go back to the original issue."

For more details, see Service Plan Record Processing.

Using the Agent Chat

Test the agent chat to confirm that Service Assistant can look up knowledge and run actions on demand. To use the agent chat, add the General CRM and FAQ subagents to your agent. See Agent Chat for Service Assistant.

• Ask a knowledge question, or ask for knowledge information, and confirm that Service Assistant returns relevant information from your knowledge articles.
• Ask Service Assistant to launch a common action, such as drafting an email, and any custom actions you've added. If an action doesn't work, check the action's permissions for the ServicePlanner User. See Action Permissions.

When the case is closed or the messaging session ends, the agent chat is terminated and the chat box is disabled. The feed history persists and stays visible, so you can review the full record of the plan steps, actions, and chat interactions after the record is closed.

Troubleshoot Knowledge Grounding

If knowledge articles aren't cited, the cited articles aren't relevant, or you see the general error messages, try these troubleshooting steps. Knowledge grounding works the same across plan types, so this guidance applies to both cases and messaging sessions. In a dynamic plan, remember that each step is created and cited on its own, so a citation problem can appear on one step but not another.

General Error Messages

• Something went wrong while creating a plan. Ask your Salesforce admin to review the data library configuration.
• I couldn't find any sources to cite. Ask your Salesforce admin to check the data library configuration.
• We couldn't show any sources. Ask your Salesforce admin for help.

Check User Permissions and Data Access

• Confirm your agent is active.
• Confirm all users have the correct knowledge grounding permissions. See Best Practices for Grounding Service Assistant in Knowledge. Pay close attention to the ServicePlanner User's permissions. Check that it has the Data Cloud User permission set and that the user has access to any custom record types and to the data categories assigned to your knowledge articles.
• Confirm that you (the admin), service reps, and the ServicePlanner User have access to the default data space on their permission sets. Generally, only the Service Assistant admin needs access to the default data space that's enabled on the Data Cloud Architect permission set. However, providing service reps access to the default data space is recommended when your knowledge articles aren't included in your plans. You can grant default data space access through either the knowledge custom permission sets or the standard Service Assistant permission sets. See Default Data Space Access.

Review Your Knowledge Grounding Setup

• Make sure your articles are public and published. Knowledge articles that are publicly available have IsVisibleInPkb set to True.
• Make sure you have Show Sources enabled in your data library configuration. Without Show Sources, a dynamic plan step doesn't display its per-step Sources section or citations.
• Make sure your data library has your latest knowledge base information by rebuilding the search index. Although your data library search index refreshes every day, manually rebuild it to sync your data library with your latest knowledge base updates. We recommend rebuilding your search index when you add, modify, or remove knowledge articles. See Rebuild a Search Index Configuration.
• Double-check your data category settings and access. Make sure that your data categories are visible and that any data categories set for your knowledge articles match the data category filtering set in the Knowledge tab of your data library.
• Review your articles to make sure that the structure and format match the identifying and content fields you've set in your data library. Identifying fields search your knowledge base to find relevant articles that match the record details. Content fields extract key information from the knowledge articles to create plan steps.
  • For identifying fields, select fields that provide a concise summary of the article, such as Title, Summary, and Question.
  • For content fields, select the fields that have the most content, such as Answer and Detail.
  • Apply any custom knowledge fields to your identifying and content field configuration.
• Review or add a knowledge article Summary to briefly describe the article and its scope. A summary improves search results. Include phrases that are commonly found in the record details to describe the issue or request.
• Make sure the content of your articles contains keywords and information related to the record.

Record Content

• For cases, review the case subject, description, and fields set in your Service AI Grounding configuration to confirm there's enough information in each field and that the information is relevant to the knowledge articles you expect to show. Review the case comments and case feed if you've selected those as grounding sources. Make sure the information is relevant and doesn't conflict with the knowledge articles you expect to show.
• For messaging sessions, review the conversation transcript to confirm the messages include specific details and keywords that relate to the knowledge articles you expect to show. Because the plan grounds in the transcript, send messages that reflect the issue so Service Assistant retrieves and cites the relevant articles.

Targeted Error Message Troubleshooting

• I couldn't find any sources to cite. Because a dynamic plan can't be redrafted, continue the conversation or update the record to prompt a new step, then confirm the citation shows. If the issue continues, ask your Salesforce admin to contact Salesforce Customer Support for help with the data library retriever.
• We couldn't show any sources. Ask your Salesforce admin to contact Salesforce Customer Support for help with the data library retriever.

For more setup and testing details, see Set Up Knowledge Grounding and Troubleshooting Knowledge.