Multiple Agents in Service Assistant

Multiple Agents in Service Assistant

When your business spans multiple products, services, or business units, you can create multiple Service Assistant agents to have tailored issue resolution guidance for specific cases. You can create up to 150 Service Assistant agents and provide them with specialized subagents, instructions, and actions.

When you have more than one agent, each record is assigned to a specific agent using an autolaunched flow that receives an input variable containing the case record ID and returns an output variable containing the API name of the agent to assign. Because every customer’s business requirements are different, you must build your own autolaunched flow that sets your specific rerouting logic using Get Records, Decision, and Assignment elements. We don’t provide a flow template.

The following sections specify the requirements for your flow and provide reference guidance for how the feature works. Setup guidance is provided in Set Up Multiple Agent Record Assignment, which walks you through creating the flow, connecting it to Service Assistant through the setup page, and testing your configuration.

In addition to creating a routing flow, you must set a default agent. Every case that meets your eligibility criteria must have an agent assigned. The default agent handles cases that don’t match the criteria and conditions in your flow or whose matched agent is deactivated. All agents use the same eligibility criteria. You can’t set different eligibility criteria for different agents. See Default Agent Configuration.

Multiple Agent Flow Configuration

How you configure your flow is based on your business requirements. You can configure your flow to route agents to cases based on record data like record type, case origin, related records, and custom fields. Generally, your agent routing flow can use these elements.

The only requirements that your flow must meet are that it’s an autolaunched flow and includes a text input variable that receives the case record ID and a text output variable that returns the API name of the agent to assign.

In each Assignment element, add your output variable and set the Value field to the API name of the agent you want to assign. Find the API name in the agent’s detail page in Setup. Our recommended name for the output variable is BotDefinitionDeveloperName. Set the name to your preferences.

Setup guidance for the multiple agent feature is provided in Set Up Multiple Agent Record Assignment. We provide steps for creating the required input and output variables, adding a Get Records element, and connecting your flow to Service Assistant. In addition, we provide guidance for setting up the Decision element, outcome conditions, and Assignment elements. Complete those configurations according to your business requirements.

If you have an existing record routing flow for cases, you can use it for Service Assistant as long as it’s autolaunched and includes the required input and output variables.

Service Assistant supports the assignment of agents based on related records, like Account or Contact. In your Get Records element, select Also get related records and choose the relationships you need.

Agent Assignment and Routing

The agent assignment flow runs only after a case meets your eligibility criteria. All agents share the same eligibility flow. You can’t assign different eligibility flows to different agents.

When a case meets your eligibility criteria, your assignment flow runs and Service Assistant evaluates which agent to assign.

• If no agent assignment flow is configured, Service Assistant assigns your default agent, which is the agent assigned to the record when the record doesn’t meet any of the criteria and conditions set in your flow. See next section.
• If an agent assignment flow is configured, Service Assistant runs it after the eligibility criteria are met. The flow evaluates the record against your routing conditions and returns the API name of the matching agent, which must be active.
• If the flow executes successfully and returns an active agent, that agent is assigned.
• If the flow executes successfully but returns an empty or null value, the default agent is assigned. There’s no message or notification in the component that the default agent is assigned.
• If the flow encounters an error, times out, returns an invalid or inactive agent API name, the default agent isn’t assigned and the service rep sees this error message: “An agent wasn’t assigned to the record. Ask your admin to check the agent assignment flow and make sure all agents are activated.”

Default Agent Configuration

Every record that meets your eligibility criteria must be assigned to an agent. If your eligibility criteria and routing flow account for a defined set of record types you want Service Assistant to handle, the default agent handles all the record types you haven’t specified in your flow.

If Service Assistant is configured to handle a wide variety of record types, your flow may not account for every record type and those records route to the default agent automatically. Common scenarios include:

• A new record type is added after your flow is built but isn’t yet mapped to an agent.
• A case has a valid record type, but a field used in the decision outcome (like origin or a custom field) is empty or set to a value your flow doesn’t handle.

Because the default agent can be assigned to a range of record types that aren’t defined in your flow, we recommend configuring it as a generalist, not a specialist. Its subagents, instructions, and actions should be general enough to handle a range of records. If the default agent is configured for specific record types, service plans can contain incorrect guidance or there could be no subagent found to assign to the record.

As a best practice, try to address as many record types in your flow as possible. Always review your flow regularly, especially when you add new record types, business units, and add or modify conditions and outcomes set in your flow.

Agent Assignment Persistence

When a record is opened and meets your eligibility criteria, the assignment flow runs based on the current record data. The matched agent is used to generate the plan summary shown to the service rep.

If the fields or objects set in your Service AI grounding configuration are updated before a service rep clicks Draft Plan, the assignment flow runs again and that can result in a different agent being assigned based on the updated data. Also, when there’s new information on the record and the service rep clicks Redraft Plan, the agent assignment flow runs again and a different agent can be assigned based on the new record data.

Once a service rep clicks Draft Plan and begins working with the plan, field updates to routing criteria do not automatically trigger reassignment. The service rep must explicitly click Redraft Plan to re-evaluate the agent assignment based on updated record data.

If the currently assigned agent is deactivated after assignment, or the flow encounters an error during re-evaluation, the service rep sees this error message: “An agent wasn’t assigned to the record. Ask your admin to check the agent assignment flow and make sure all agents are activated.” Service Assistant doesn’t automatically reassign to the default agent.

Considerations

• The flow executes under the ServicePlanner User’s Run Flows permission provided by the Einstein Agent User profile assigned to the agent. Service reps don’t require access to the flow.
• The eligibility flow and the agent assignment flow are separate flows that serve distinct purposes. The eligibility flow determines whether a record is eligible for a service plan. The agent assignment flow determines which agent handles that record. While it’s possible to adapt your eligibility flow and set it as your multiple agent assignment flow we don’t recommended this approach. The two flows contain different variable names and configurations, which can make the flow difficult to maintain and troubleshoot. For the best results, create a dedicated autolaunched flow for agent assignment
• Ensure routing fields are populated before Service Assistant creates a service plan summary. If a field used in your routing criteria is empty or incorrect when the Service Assistant starts to generate a service plan summary, your flow runs based on that incomplete data and may assign the wrong agent.
• If your routing flow encounters errors (timeout, invalid agent ID, inactive agent), the service rep sees an error message and should notify their admin. The default agent is only used for successful flow execution that returns empty or null, not for flow error scenarios.
• Agent API names are case-sensitive. The API name returned by your flow must match the Service Assistant agent’s API name exactly, including capitalization and underscores.
• If you have an active implementation of Service Assistant before the release of the multiple agent feature June 30, 2026, your existing agent is automatically set as your default agent. If you activate and set up Service Assistant after the official release, you must manually set a default agent in the Setup page.
• Testing agent routing is manual. You have two options.
  • Test your flow in Flow Builder using the Debug tool in Flow Builder. Create a test scenario and provide a record ID for a specific record that you expect the agents set in your flow to be assigned.
  • Create a case that matches each routing condition in your flow and verify the correct agent is assigned by reviewing the subagent name in the service plan summary. The subagent name corresponds to the agent assigned to the case. If the shown isn’t what you expect, review your Decision element conditions and Assignment element values.