Agentforce

Put curated context in front of an Agentforce agent. Deploy → Agentforce walks these steps with your org’s values already filled in.

1. Enable Agentforce

Setup → Agentforce Agents. Requires Einstein generative AI in the org.

2. Create the agent actions

On Deploy → Agentforce, click Install in step 2. That’s the whole step.

The extension is a second package holding the Agentforce metadata: the eight runtime actions (Get_Catalog, Find_Records, Get_Records, Get_Briefs, Get_Skill, Get_Info, Update_Records and Create_Records), a ready-made ContextWorks topic, and the admin agent’s actions and its own topic (step 2a). Every one carries exactly the name the generated AgentScript expects, so step 3 works without edits.

It ships separately because this metadata requires Einstein generative AI. Orgs that do not use Agentforce install the core package and skip it.

To register by hand instead: Setup → Agent Actions → New → Apex, once per action. The Deploy page shows each class, the name to give its action, and what it does. Do this when your naming standards differ, or when you want only some actions exposed.

3. Create the agent, or extend yours

Step 3 generates AgentScript wired to your installed actions. The script names no entities of yours: the subagent calls Get Catalog first in every conversation, so it reads the live set instead of carrying a copy that ages. A toggle picks the scope:

Mode	You get	Use when
Full agent	A router, an off-topic guard, and a ContextWorks subagent wired to every runtime action — catalog, find/aggregate, records, briefs, skills, info, update and create	You have no agent yet
Agent actions	Just the ContextWorks subagent and the same actions	You already have an agent

Copy the script, paste it into Agent Builder’s script editor, and adjust. If you chose Agent actions, add a transition to the new subagent from your existing agent’s router — without it the subagent is never reached.

The action inputs carry descriptions written for agents. Dates accept literals like THIS_QUARTER. Find Records takes a Level of list or standard and refuses detailed. For related lists and enrichment, the agent passes the ids from that result on to Get Records. ContextWorks caps an oversized maxRows request and says so in the response, and totals always cover the full matching set.

Regenerating

Almost never. Entities, fields, metrics and domains all resolve at call time and the script names none of them, so an entity you add this afternoon reaches an agent whose script you pasted in March. Regenerate only when the package ships new or renamed actions, which are what the script does name.

The generated script wires every runtime action, the two that change data included. The switches decide what those two do: write access and create access are each off until an admin turns them on, and an action the org switch, the domain or the entity refuses changes nothing.

What wiring them changes is what an agent will attempt, so the script instructs both: check the catalog rather than assuming one verb from the other, preview first, show the user the diff or the proposed record, and confirm before committing. The script also tells the agent where the two verbs differ. Running an update twice is harmless; running a create twice makes a duplicate.

To stop an agent trying at all, delete the action from the script before you paste it.

2a. Admin agent actions

Already installed: the extension package from step 2 registers the admin actions and the ContextWorks Administration topic alongside the runtime set. To register by hand instead, name each action exactly as the Deploy page shows. The admin AgentScript references those names.

3a. Create the admin agent

Administration gets its own agent, never mixed into the runtime one, so an agent that answers questions cannot reconfigure the system it reads from. Step 3a generates a complete admin AgentScript: router, off-topic guard, and a subagent wired to the reads (Get Full Config, Get Health, Get Change Log, Get Catalog), the composer (Save Draft), the changes that ask you to confirm first (Activate Draft, Update Domain Contents, Deactivate) and Get Skill.

Paste it into Agent Builder as a separate agent and give access only to admins and domain managers. Every call still checks the conversing user’s permissions, but a separate agent means nobody else ever sees the tools. Anything it drafts reaches no one until a person activates it. → The admin agent

4. Grant access

Assign the ContextWorks User permission set to whoever the actions run as:

• Employee agents run actions as the conversing user. Assign it to everyone who will talk to the agent.
• Service agents run as the agent’s own user. Assign it there.

It reaches the ContextWorks actions and ContextWorks’ own configuration records, never your Salesforce data, so broad assignment is safe.

5. Test it

Ask something that needs a curated field — ideally one carrying an instruction:

“What should I know about the Global Media account?”

The agent should call Get Catalog, then Get Records, and answer from your curated context. Check Observe → Usage for the load. No usage means the action was never reached, not that it failed.

Best practices

• Give each agent its own user, before the second agent goes live. Agentforce passes no agent identity to Apex, so the running user is the only per-agent signal in Usage. Once two agents share a user, you cannot tell their loads apart, then or later.
• Set a distinct toolName on custom actions. It becomes the Surface value on every load that tool assembles, so Usage reads that tool’s traffic on its own.

Troubleshooting

• The agent doesn’t call the actions. Check the action names match the script exactly. If you extended an existing agent, check the router transition.
• Action name not found: ctxl__GetCatalogAction. The action block is missing its source: line. Each action needs both: source: "ctxl__Get_Catalog" names the registered function, target: "apex://ctxl__GetCatalogAction" names the Apex class. A block carrying only target: saves clean and fails on the first call. Re-adding the action in Agent Builder writes both back.
• Activation fails with bad value for restricted picklist field. The namespace prefix is wrong for this org. A subscriber org prefixes both names, source: "ctxl__Get_Catalog" and target: "apex://ctxl__GetCatalogAction". The package’s own namespaced dev org resolves both bare instead, source: "Get_Catalog" and target: "apex://GetCatalogAction". Regenerate from the Deploy page, which emits the right form for the org you are in.
• The agent guesses object names. It isn’t calling Get Catalog first — strengthen the subagent instruction.
• Answers are thin. Check Quality — the caller’s FLS may strip fields you can see. Preview runs as you, so it won’t reproduce this.
• A whole section is missing. Check Issues for an element_failure, then the element’s minimum level.

What’s next

• MCP
• Custom tools