General Considerations for Service Assistant

General Considerations

Keep these functionality considerations in mind as you set up Service Assistant. These considerations are also provided in each respective area of this documentation.

General Functionality

• Service Assistant is supported only in the legacy Agentforce Builder. Starting in July 2026, the requirement that new agents can be created only in the new Agentforce Builder doesn't apply to Service Assistant. You can continue to create and configure a Service Assistant agent in the legacy builder until further notice. See Create Agents in the New Builder Only Starting July 2026.

• Specific permissions are required to access and use Service Assistant. See Permissions and Licensing for Service Assistant.
• Each of your users must have a User Role assigned. See Create a User Role and Assign Users to Role.
• Data 360 is required to create service plans. Make sure that Data Cloud is provisioned and turned on.
• A service plan is generated only when the case meets your eligibility criteria. See Service Plan Eligibility Criteria.
• Service Assistant isn't supported on mobile apps (Salesforce mobile app, custom apps, Service Console on mobile/tablet). This limitation applies to native mobile apps, not web browsers accessed through mobile devices. Although Service Assistant appears in mobile web browsers, full functionality isn't guaranteed.
• URLs are supported in service plans. If your subagent instructions or knowledge articles contain URLs, they're rendered in the steps of a service plan.

Grounding and Data Masking

• Service Assistant is grounded in these data sources. See Grounding Sources.
  • Case data through Service AI Grounding (required)
  • Your service policies and practices transcribed in Agentforce topics and instructions (required)
  • Knowledge data through Agentforce Data Libraries (optional)
  • Standard and custom case object quick actions (optional)
  • Messaging and voice records (optional)
• Each optional feature requires additional permissions. See Permissions and Licensing for Service Assistant.
• For Service AI Grounding, keep these considerations in mind.
  • Service Assistant relies on Service AI Grounding, not context variables, for case data. Subagent selection and service plan generation are driven by the Subject and Description fields automatically set in Service AI Grounding, not by context variables passed through the agent session. Service Assistant can't access information such as Account or Contact associated with the case.
  • Service plans are grounded in the context of the ServicePlanner User's permissions. This means service reps can see grounded responses for fields and objects they don't have direct access to. Set your grounding configuration so that the ServicePlanner User's permissions align with the data access intended for your service reps. See Service Assistant Grounding Data Access.
  • Encrypted fields aren't supported for grounding.
  • Only String and Text Area type fields are supported for grounding.
  • Only text from Case Email, Case Comments, and Case Feed is supported. PDFs, images, and other attachments aren't used as grounding sources.
  • If you choose to ground with the case feed, you must provide Service Assistant access to the case feed. The agent has access to case emails and case comments by default.
  • You have the option to choose the Case fields you want to mask to prevent their exposure to Service Assistant with the Einstein Trust Layer. See Select What Data To Mask.
• Service Assistant can propose its own steps that aren't based on your grounding sources. Such steps are indicated with an asterisk (*). Proposed steps appear when there isn't enough information in your subagents, instructions, or knowledge articles.

Agent Details

• As part of the Agentforce suite, Service Assistant has its own template and type in the Agentforce Builder: Agentforce Service Assistant. It's not officially categorized as an employee agent.
• As part of the agent creation process, an agent user named ServicePlanner User is auto-created. It's set to the listed configuration, and the agent record is active by default.
  • Email: noreply@salesforce.com
  • Username: ServicePlanner User
  • Type: ServicePlanner
  • Profile: Einstein Agent
  • User license: Einstein Agent
  • Permission set: Service Planner User and Agentforce_Service_Assistant Permissions
• The ServicePlanner User (the agent user) must have a User Role assigned. See Create a User Role and Assign Users to Role.
• Service Assistant supports translation for guidance plans for Case only. See Service Plan Translation.

Agent Testing

• Because Service Assistant creates service plans through a Lightning web component on the Case record page, service plans can't be tested in the Agentforce Builder or Agentforce Testing Center.
• You can perform a quick sanity check of your subagents and actions directly in Agentforce Builder, but testing how the subagents and actions are working in a service plan requires creating service plans on records. See Test Service Assistant.

Other Considerations

Review the languages, LLM models, and other functionality that Service Assistant supports.

Feature Language and Locale Support

• Service Assistant supports translation for gudiance plans for case only. Dynamic plans for both case and messaging aren't translated. The agent user's (ServicePlanner User) locale must be set to English.
• The Service Assistant Setup page is translated into all supported languages and locales.

Feature Large Language Model Support

Service Assistant supports only OpenAI GPT-4. See Large Language Model Support.

Feature Region Support

Service Assistant supports only the GPT-4 Omni geo-aware model. See Geo-Aware LLM Request Routing on the Einstein Generative AI Platform.

Einstein Trust Layer Service Support

Service Assistant supports these subsets of Trust Layer services, as described in Einstein Trust Layer. You can configure all Trust Layer services to your preferences.

• Dynamic grounding with Service Data Retrieval: Relevant information from a Salesforce record is merged with the prompt to provide context.
• Prompt Defense: System policies help limit hallucinations and decrease the likelihood of unintended or harmful outputs by the agent reasoning engine (LLM).
• Data Masking: Sensitive information in prompts is masked before sending them to the large language model (LLM)
• Toxicity Scores: Potentially harmful LLM responses are detected and flagged.
• Audit and Feedback: Service plan ratings gathered with the Feedback component are logged and stored in Data 360. Feedback can be used to improve service plans.