Five practical gotchas I discovered while working with Einstein Copilot (live and Summer ’24 preview) and how to avoid them.
Introduction
Einstein Copilot introduces powerful AI capabilities into Salesforce, but with new features come unexpected behaviours. After testing Copilot in both a partner demo org and a Summer ’24 sandbox, I ran into several gotchas that can waste time if you don’t know them in advance. Below I explain the issues, why they happen, and pragmatic workarounds.
1. Only SObjects with User Interface support can be displayed
Copilot’s visual display relies on the User Interface API. If your object isn’t supported by the UI API (for example, some older or non-UI-enabled objects), Copilot won’t be able to present records or fields in the built-in UI. Salesforce documentation and the UI API supported objects list are authoritative here.
What to do:
- Verify the object is supported by the UI API: https://developer.salesforce.com/docs/atlas.en-us.250.0.uiapi.meta/uiapi/ui_api_all_supported_objects.htm
- If it’s unsupported, consider exposing the data via a supported wrapper object, API view, or using formatted text output from a custom action.
2. Don’t change Apex action outputs
If you create an Apex-based Copilot action and define output parameters (types and structure), Copilot will lock to those formats. Updating the output structure later won’t behave as you expect — Copilot may silently discard mismatched fields without error.
Workaround:
- Delete and recreate the Apex Copilot action with the new outputs. It’s a nuisance but faster than debugging silent failures.
- Design outputs conservatively up front (use optional fields or generic structures where reasonable) to reduce future changes.
3. Don’t change Apex grounding for prompt templates
When using Apex grounding classes for prompt templates, changes to those classes may not persist or be picked up by Copilot in-place. In my Summer ’24 sandbox, edits to grounding logic (even simple debug additions) didn’t stick until I recreated the prompt template to reference a new class.
Workaround:
- Create a new Apex class for the updated grounding logic and update the prompt template to reference the new class.
- Keep grounding classes small, well-tested, and versioned so you can switch references instead of editing in-place.
4. System Administrators may need Prompt Builder permissions to compile code
In one Summer ’24 scenario, other System Administrators attempting deployments and test runs encountered failures related to grounding classes and invocable method decorators. Granting the “Prompt Template Manager” permission set resolved the issue, suggesting the compilation path may expect Prompt Builder-related privileges.
Notes & recommendations:
- Consider granting Prompt Template Manager permissions to admins involved in Copilot development/testing until Salesforce confirms and documents expected permission behavior.
- If you hit similar test/deploy failures, open a support case and include reproduction steps.
5. Users need class permissions to access Apex actions
Like many Apex-driven features, access to Copilot Apex actions is controlled by Apex class access. If a user can’t see or run a custom action, verify their profile or permission set includes access to the Apex classes used by the action. This can be hard to diagnose because Copilot may simply report no results.
Checklist:
- Ensure relevant users have Apex class access (profile or permission set).
- Test using a user with the same permissions as the affected user to reproduce the issue.
Key takeaways
- Design Copilot Apex outputs and grounding with stability in mind — changes can be brittle.
- When in doubt, recreate actions or classes and reference the new versions to avoid caching or persistence issues.
- Review permissions early: UI support, Apex class access, and Prompt Builder-related permissions can all impact Copilot functionality.
Conclusion
Einstein Copilot is a powerful addition to the Salesforce stack, but it’s early days and the integration points with Apex, grounding, and permissions can be surprising. Knowing these gotchas up-front saves debugging time and helps you deliver reliable Copilot experiences.
Why this matters for Salesforce admins, developers, and business users
Admins need to understand the UI API and permissions implications; developers need to design stable outputs and grounding patterns; business users benefit when Copilot actions are reliable and visible to the right people. Plan Copilot projects with these constraints in mind to reduce deployment risk and improve user adoption.