Agentforce

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

Click Install Extension Package on the Deploy page. That’s the whole step.

The extension is a second package holding the Agentforce metadata: the six runtime actions — Get_Catalog, Find_Records, Get_Records, Get_Briefs, Get_Skill and the optional Update_Records — a ready-made ContextWorks topic, and the admin agent’s actions and topic (step 2a). Everything is named exactly as 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. It does not name your entities: the subagent calls Get Catalog first, every conversation, so it discovers the live set rather than 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 the five read actions — catalog, find/aggregate, records, briefs, skills	You have no agent yet
Agent actions	Just the ContextWorks subagent and its five read 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, oversized maxRows requests are capped and the response says so, 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 added this afternoon reaches an agent whose script was pasted in March. Regenerate only when the package ships new or renamed actions, which are what the script does name.

The generated script wires the read actions only. Add Update_Records yourself, once write access is on: an action nobody registered cannot be misused.

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. Registering by hand instead, name each exactly as the Deploy page shows — the admin AgentScript references those names.

3a. Create the admin agent

The administration surface 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 need your approval (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 is permission-checked as the conversing user anyway, 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 grants class access only, never data access, 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. Agents sharing a user can never be separated, retroactively or otherwise.
• Set a distinct toolName on custom actions. It becomes the Surface dimension, which separates which action was called.

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. Two causes. Either the action block is missing its source: line — an action needs both source: "ctxl__Get_Catalog" naming the registered function and target: "apex://ctxl__GetCatalogAction" naming the class, and a block with only target: saves clean and fails on the first call; re-adding the action in Agent Builder writes both back. Or the target’s namespace prefix is wrong for the org: subscriber orgs need apex://ctxl__GetCatalogAction, while the package’s own namespaced dev org resolves local classes bare — apex://GetCatalogAction, with source: keeping ctxl__ in both. A prefixed target in the dev org fails at runtime and blocks activation with bad value for restricted picklist field. Regenerate from the Deploy page, which emits the right form per org.
• 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