Five Einstein Copilot Gotchas

Tweet

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. You won't get any errors, but Copilot has cast your original formats in stone and if you return anything else it will just get discarded. If you need to change this, delete the action and recreate it. That might sound like a bit of work, but the alternative is scratching your head for a couple of hours and then doing it anyway, so it's really not.

3. Don't Change Apex Grounding for Prompt Templates

This arose because my grounding wasn't being returned to the prompt in the Summer 24 sandbox, which I have a case open with Salesforce about, and I was trying to figure out what was happening. This was also in the Developer Console as I didn't have the CLI hooked up. I added some debug to my grounding code, saved the class without error, but when I ran it again the debug didn't appear. After some trial and error I opened the class again to find my debug wasn't there. I couldn't get the changes to stick until I recreated the template.  If you need to change the Apex grounding code, create a new class and reference that instead. Again, the alternative is to spend several hours failing and then do that, so it's better to short circuit.

4. System Admins need Prompt Builder Permissions to Compile Code

This is one that I suspect is a bug in Summer 24. Once I had some grounding Apex classes in the org, if another System Administrator tried to deploy a change and run tests they would get failures that the grounding classes had invocable method capability type decorators that weren't available. Giving them the Prompt Template Manager permission set resolved this, but it felt like a really odd thing to have to do. I also have a case raised about this, to either get confirmation that it's a bug or get it added to the docs.

5. Users need Class Permissions to Access Apex Actions

This one isn't really a surprise, as it matches with quite a lot of other features, but I thought I'd mention it as it's not called out in the documentation at present. Where it gets tricky is figuring out this is the issue -  you login as another user, try the prompt and it doesn't pick your custom action. Or you don't know if it considered your custom action or not, as it told you there were no results. It's tricky to debug when this happens, especially if it's a regular user that can't access Copilot Builder. 

Related Posts

• Formatted Output from Copilot Custom Actions
• Einstein Copilot - AI + (most of your) Data + CRM
• Chaining Copilot Custom Actions
• Einstein Copilot Custom Actions
• Einstein Prompt Templates in Apex - the Sales Coach
• Einstein Prompt Grounding with Apex
• Hands on with Salesforce Copilot
• Hands On with Prompt Builder
• Salesforce Help for Prompt Builder
• Salesforce Admins Ultimate Guide to Prompt Builder

Follow @bob_buzzard