Five Einstein Copilot Gotchas
Summary
Working with Einstein Copilot reveals several key pitfalls to watch for, especially when developing Apex Copilot actions and prompt templates. Important gotchas include compatibility only with User Interface API-supported SObjects, immutable Apex action output formats, and the need for proper permissions for system admins and users. Awareness of these helps avoid wasted time troubleshooting issues with grounding code changes, deployment failures due to missing permissions, and users unable to access custom actions. Teams can speed up their development cycles and ensure smoother Copilot implementations by following these practical lessons.
Takeaways
- Only User Interface API-supported SObjects can be displayed in Copilot.
- Do not change Apex Copilot action output parameters; recreate actions instead.
- Avoid modifying Apex grounding code for prompts; create new classes to update.
- System admins need Prompt Template Manager permission to compile grounding code.
- Users require appropriate Apex class access to use custom Copilot actions.
Image created by DALL-E 3 based on a prompt by Bob Buzzard Introduction I've been working with Copilot for a few weeks now, both the current live version in a partner demo org, and the Summer 24 preview in a sandbox. I've learned quite a bit, including a few gotchas that took me by surprise, even though I was expecting a few hurdles with new capabilities like these. Read on to make sure they don't catch you out. 1. Only SObjects with User Interface Support can be Displayed I wrote about this a week or two ago, specifically around Tasks and Events . The docs have now been updated to reflect this: Einstein Copilot supports custom and standard User Interface API-supported objects . 2. Don't Change Apex Action Outputs Once you've created an Apex Copilot action and defined the format of the output parameters, you can't change them. Not in a way that works at any rate.