Salesforce Agentforce Specialist (AI-201) — Skills Reference

Overview

> Rebrand note (read first): The original "Salesforce Certified AI > Specialist" exam (launched September 2024) was rebranded > "Salesforce Certified Agentforce Specialist" (AI-201) on March 3, 2025. > Topic areas and weights shifted significantly. Existing AI Specialist > credential holders were automatically transitioned with no retest required. > "AI Specialist" is no longer the current name — use Agentforce Specialist > (AI-201). (Distinct from the entry-level AI Associate credential, which > was retired in early 2026.)

The Agentforce Specialist (formerly AI Specialist) validates the ability to implement, configure, and govern Salesforce generative + agentic AI — Prompt Builder, Agentforce agents (formerly Einstein Copilot), Model Builder, Data 360 (formerly Data Cloud) grounding, and the Einstein Trust Layer. This document is an operational playbook, not an exam outline: every section states the rule as an actionable instruction, the real limits, the decision criteria, and the anti-patterns to catch in review.

> Product rename (Oct 2025): Salesforce Data Cloud was renamed > Data 360 at Dreamforce on October 13, 2025. The underlying product, > licenses, data model, and integrations are unchanged. This document uses > "Data 360 (formerly Data Cloud)" on first use and "Data 360" thereafter.

The certification sits between entry-level AI Associate (conceptual, no hands-on) and senior architecture credentials. Recommended (not required) prior knowledge: Salesforce Administrator or Platform App Builder.

> Load this skill when… building or reviewing Agentforce agents (topics, actions, agent-user security); creating Prompt Builder templates (Sales Email, Field Generation, Record Summary, Flex); configuring Data 360 (formerly Data Cloud) grounding or Knowledge RAG for a prompt or agent; or reviewing Einstein Trust Layer settings (data masking, zero-retention, audit trail). > Not this skill: admin-level Agentforce permission setup (enabling features, assigning licenses) without building an agent → see salesforce-administrator; writing the Apex code behind an agent action → see salesforce-platform-developer-2.

> Deeper context: Study resources live in references/study-resources.md (loaded on demand). For org-specific applications of these rules, see a per-org appendix you maintain in your own project, referenced from a CLAUDE.md. For NPSP/nonprofit-specific guidance, see salesforce-nonprofit-cloud-consultant.

> Verify steps assume nothing about your tooling — use your project's Salesforce MCP connection, the Salesforce CLI (sf), or the Salesforce setup UI, in that order of preference.

Credential logistics and study path: see references/study-resources.md.

Uncertainty & Escalation

• Always re-verify live: [volatile — verify live] items include: Agentforce agent type availability per edition and license (Service Agent, SDR Agent, Sales Coach Agent), Prompt Builder template type capabilities across releases, Data 360 RAG/Data Library feature availability, Einstein Trust Layer masking configuration UI paths, and AI-201 blueprint topic weights.
• Live wins: when this file and the live org or official AI-201 blueprint disagree — for example, a template type added or renamed in a recent release — trust the live system and flag this skill as stale via the Feedback protocol below.
• Escalate to a human: surface — never silently execute — any configuration that points an agent at sensitive or PII-containing records without first verifying the running-user's FLS and sharing scope, grants an agent user a broad profile or "Modify All" permission, publishes a prompt template with no Trust Layer masking review for sensitive fields, or configures a production agent without Testing Center validation.
• Confidence taxonomy: every fact in this file is considered stable unless tagged [volatile — verify live] or [opinion — house style].

Inline volatile tags applied:

• Agent type roster (Service Agent, SDR Agent, Sales Coach Agent, Employee Agent) [volatile — verify live] — new agent types are introduced each release; verify available types in your org's Agentforce Setup.
• AI Associate credential retired "in early 2026" [volatile — verify live] — retirement dates and credential transitions are announced on Trailhead; verify current status.
• Data 360 (formerly Data Cloud) RAG / Data Library / vector search availability [volatile — verify live] — requires Data 360 provisioning; feature names and configuration paths change across releases.
• Einstein Trust Layer masking configuration for custom fields [volatile — verify live] — masking entity configuration UI and defaults evolve; verify which custom fields require explicit registration in your org's current release.

1. Prompt Engineering & Prompt Builder (20%) volatile — verify live]

The rules

• Reach for an out-of-the-box Einstein feature before building a template.

Build a Prompt Builder template only when no standard generative feature (Einstein Sales Emails, Work Summaries, Service Replies) covers the need, OR when you need it grounded on custom objects/fields the standard feature can't see. When everything you need lives on custom objects or custom fields that no standard feature grounds on, custom templates become the norm.

• Pick the template type by output target, not by vibe:

| Need | Template type | |---|---| | Personalized outbound email to a person from CRM data | Sales Email | | Write AI text into a record field | Field Generation | | Natural-language summary of one record for a human to read | Record Summary | | Anything else / multi-input / used inside Flow/Apex/Agent action | Flex |

Flex is the catch-all and the one you use to back an agent action. Field Generation must target a writable field whose length you control (see length rule below).

• Ground every template. Ungrounded prompts hallucinate. Grounding sources,

in increasing power: (a) merge fields off the template's input record/object, (b) related-record merge fields via lookup traversal, (c) flow/Apex data providers, (d) Data 360 RAG retriever for unstructured content. Use the lightest one that supplies the needed facts.

• Static vs. dynamic grounding: static = fixed text baked into the template

(policy, tone, disclaimers). Dynamic = merge fields resolved at run time from the record. Put PII-shaped facts in dynamic grounding so they're masked by the Trust Layer (see §6); never paste a real record's data as static text.

• Lifecycle is draft → version → activate → test in the preview pane → deploy.

A template must be activated before a Lightning page, Flow, or agent action can reference it. Edits create a new version; reactivate to publish.

• Permissions are two distinct grants. "Prompt Template Manager" (create/edit)

is separate from "Prompt Template User" (execute at run time). A staff user who should only run a template must not get Manager. Grant via permission set, not by widening a profile.

• Write prompts with structure: assign a role, state the task, constrain the

output format explicitly (length, tone, "do not invent facts not present in the grounded data"), and iterate in the preview pane against real sandbox records.

Concrete numbers

• A Field Generation result silently truncates to the target field's length.

Match the prompt's max-output instruction to the field size, and verify the field length first with describe — do not assume.

• Sales Email / Record Summary outputs are bounded by the model context window;

keep grounded record sets small. Don't ground a template on a giant related list expecting all rows — retrieval/merge limits apply and the model will drop the tail.

Anti-patterns / red flags

• A template with no grounding that nonetheless asks for record-specific

facts → it will fabricate them. Red flag in any review.

• Pasting real PII (names, DOB, medical notes, SSN, sensitive document text) as

static grounding → bypasses Trust Layer masking. Always use dynamic merge fields.

• A Field Generation template whose output instruction is longer than the

target field → silent data loss on write.

• Referencing a template from a Lightning page that is still in draft → it

won't resolve at run time.

Verify against the live org

• describe the target object(s) to confirm the exact API names and lengths

of every merge field before wiring it into a template.

• Pull a real sandbox record to test the template against in the preview pane.
• List objects to confirm which custom objects exist before assuming a merge source.

2. AI Agents — agents, topics, actions, security (35% — largest domain) volatile — verify live]

The rules

• Understand the loop: the reasoning engine (LLM planner + executor) reads

the user utterance, classifies it to a topic, then chains the actions attached to that topic. Topic classification quality is driven by the topic's scope, description, and instructions — vague topics misroute.

• Pick the agent type by audience and job:

| Job | Agent type | |---|---| | Inbound customer/constituent service | Service Agent | | Autonomous prospecting / lead qualification | SDR Agent | | Rep coaching via role-play | Sales Coach Agent | | Internal staff productivity | Employee Agent |

• Standard topics ship pre-built; custom topics encode org intent. Add a

custom topic when no standard topic matches the request; give it a tight scope, a clear description, and explicit instructions that tell the planner when to use it and when NOT to.

• Choose the action mechanism by what it must do:

| Action need | Build it as | |---|---| | Deterministic query/DML on Salesforce data | Flow action (preferred — declarative, testable) | | Logic Flow can't express, or complex SOQL/transaction | Apex action (@InvocableMethod) | | Generate natural-language text | Prompt template action | | Call out to an external system | External service / API action |

Prefer Flow over Apex when both work; it's declarative and easier to govern.

• The agent runs as a real, named Salesforce user. Its profile + permission

sets + sharing define exactly what it can read/write. Design least privilege: an Employee Agent answering status questions needs read on the relevant object, not modify-all. Never give an agent user broad admin.

• Constrain behavior deterministically. Use topic/action instructions,

input/output filters, and response templates to keep the agent on-rails. Don't rely on the LLM's good intentions for compliance-sensitive output.

• Test in Agentforce Testing Center, not by eyeballing. Author test

utterances, run evaluations, read the trustworthiness / topic-and-action accuracy scores. Results are graded quality scores, not a binary pass/fail — iterate the topic/action descriptions to raise them.

Concrete behaviors

• Agent metadata that ships sandbox → prod: the agent (Bot), its topics,

actions, and referenced prompt templates. The backing Flows/Apex must also be deployed, and the agent user, profile, and permission set assignments must exist in the target org — these are environment-specific and a frequent cutover miss.

• An agent can only act on data its assigned user can see; FLS and sharing apply

exactly as they would for that user (see §6).

Anti-patterns / red flags

• One mega-topic that "handles everything" → the planner can't route reliably.

Split into scoped topics.

• Agent user granted a powerful profile "to make it work" → least-privilege

violation; the blast radius of a prompt-injection grows to whatever that user can do.

• Deploying an agent to prod without deploying its Flows/Apex or creating its

agent user → agent loads but every action fails at run time.

• Treating Testing Center as optional → untested agents misroute on real

utterances.

Verify against the live org

• List/describe objects to confirm the objects + FLS an agent action will touch,

then size the agent user's permission set to exactly that.

• Dry-run the exact query a Flow/Apex action will execute, as the intended agent

user's visibility, before wiring it in.

• After a cutover, query through the agent's expected access path to confirm the

agent user can actually see the records.

3. Data 360 (formerly Data Cloud) for Agentforce — grounding (20%) volatile — verify live]

The rules

• Data 360 must be enabled before any Data Library / RAG feature exists.

RAG grounding, vector search, and Data Library are not available in an org without first provisioning Data 360 (formerly Data Cloud). Don't design a solution that assumes them unless Data 360 is confirmed enabled.

• Use the Data Library for unstructured grounding (PDFs, Knowledge articles,

uploaded files, Data 360 objects). Structured CRM facts should still come from merge fields / Flow, not RAG.

• Chunking governs retrieval quality. Chunk unstructured docs into

retrievable segments with sensible size + overlap: too large dilutes relevance, too small loses context; overlap preserves meaning across boundaries. Indexing turns chunks into vector embeddings that semantic search queries.

• Pick the retriever by source count: single source → individual

retriever; multiple sources needing merged/re-ranked results → ensemble retriever.

• Pick the search type by query shape:

| Query | Search type | |---|---| | Exact token (SKU, policy #, record ID) | Keyword | | Conceptual / natural-language ("how do I qualify?") | Vector / semantic | | Mixed / unsure / production default | Hybrid |

Anti-patterns / red flags

• Designing RAG features for an org where Data 360 isn't enabled → the build

won't have the objects.

• Using vector search for exact-ID lookups → keyword is faster and exact.
• One giant chunk per document → poor retrieval relevance.

Verify against the live org

• Confirm Data 360 presence/absence by checking whether Data 360 DMO/DLO

objects appear in the object list. Treat Data 360 features as a future, post-provisioning capability if they're absent.

4. Development Lifecycle — testing, deployment, adoption (20%) volatile — verify live]

> Blueprint note: Development Lifecycle is a top-level AI-201 domain (≈20%). Service Cloud and Sales Cloud are not standalone exam domains; their agent patterns are covered within §2 (AI Agents). The key Service/Sales guard-rules are retained below.

The rules

• Test with Agentforce Testing Center before any production release. Author test utterances covering happy-path, adversarial/out-of-scope, and edge cases (record not found, ambiguous input). Review both trustworthiness and topic-and-action accuracy scores — these are quality signals to iterate on, not a binary pass/fail.
• Deploy agent metadata + backing automation + agent user together. A change set or metadata deployment that includes the agent Bot, topics, and prompt templates must also include the backing Flows/Apex. The agent user, their profile, and permission set assignments must exist in the target org. Missing any of these three layers is the most common cutover failure.
• Activation does not travel with deployment. A Prompt Builder template deployed via change set lands in Draft status in the target org. Reactivate it in Prompt Builder before the agent action can invoke it.
• Monitor adoption post-launch. Review agent conversation logs, escalation rates, and topic-accuracy scores in production. Falling trustworthiness scores or rising escalation rates are signals that topic instructions or action logic needs iteration.

Service/Sales agent guard-rules (no standalone exam domains; patterns sit within AI Agents): ground service agents on Knowledge articles and always configure an escalation/hand-off path; confirm Case/KnowledgeArticleVersion are in use before proposing a Service Cloud-grounded agent; don't force-fit SDR/Coach agents to orgs with no sales pipeline (see salesforce-nonprofit-cloud-consultant). Full feature-to-scenario tables and cloud-specific anti-patterns: references/study-resources.md.

Anti-patterns: (a) "it worked in sandbox" as a production gate — always run Testing Center in the production org post-deploy; (b) deploying the agent Bot without its backing Flows or agent user → every action fails at run time; (c) assuming a deployed template is Active — reactivate it in the target org.

5. Multi-Agent Interoperability (5%) volatile — verify live]

Key operational rules: use MCP for agent-to-agent communication; use Agent API to trigger an Agentforce agent from an external system or orchestrator; design each agent with a single responsibility. Least-privilege applies to every agent in a multi-agent network — inter-agent calls do not expand the called agent's access. Trust Layer masking and audit apply to all AI calls regardless of call origin.

Full rules, anti-patterns, and A2A protocol decision criteria: references/study-resources.md.

6. Einstein Trust Layer & data protection (woven through all domains)

The rules

• Every AI call in the org passes through the Trust Layer. It provides

zero-data-retention with Salesforce's LLM partners, dynamic data masking before the external call, toxicity/bias scoring on the response, and an audit trail of prompts + responses.

• Zero retention means PII sent in a grounded prompt is not used to

train external models — the property that makes grounding on sensitive records acceptable at all.

• Configure masking for sensitive fields explicitly. Mask SSN, document

content, medical detail, DOB, and contact PII so they're tokenized before the prompt leaves Salesforce and de-tokenized in the response. Don't assume defaults cover custom sensitive fields — verify.

• The audit trail is your compliance evidence. Keep it on; it records what

was sent and returned for every prompt over sensitive data.

Anti-patterns / red flags

• Any design that puts sensitive data (medical info, SSN, document content) into

static grounding or into a logged debug string → bypasses masking and violates a "no PII in logs" policy.

• Assuming masking auto-covers custom sensitive fields → custom fields often need

explicit entity configuration. Verify.

Verify against the live org

• describe the relevant objects to enumerate the exact medical/PII custom

fields that must be in the masking configuration.

Operational Rules Quick Reference

• DO prefer an out-of-the-box Einstein feature; build Prompt Builder templates only when grounding on custom objects/fields a standard feature can't see.
• DO ground every prompt template — ungrounded prompts hallucinate.
• DO put record facts in dynamic merge-field grounding so the Trust Layer can mask them; DON'T paste PII as static grounding text.
• DO match a Field Generation template's max-output instruction to the target field length (describe first) — output silently truncates otherwise.
• DO activate a template before referencing it from a page/Flow/agent; a draft won't resolve at run time.
• DO separate "manage template" from "execute template" permissions; grant via permission set.
• DO pick the template type by output target: Sales Email / Field Generation / Record Summary / Flex (Flex backs agent actions).
• DO give each agent a scoped topic with clear instructions; DON'T build one mega-topic — the planner will misroute.
• DO prefer Flow actions over Apex actions when both work; use Apex only when Flow can't express it.
• DO run the agent as a least-privilege named user; DON'T hand it a powerful profile "to make it work."
• DO deploy agent metadata + backing Flows/Apex + agent user + permission sets together to the target org — omitting any layer causes run-time failures.
• DO test in Agentforce Testing Center with happy-path, adversarial, and edge-case utterances before production; run the same set post-deployment in prod; treat trustworthiness/topic-accuracy scores as iteration signals, not a binary gate.
• DO reactivate a Prompt Builder template in the target org after deployment; activation status does not travel with a change set.
• DO pick search type by query shape: keyword for exact IDs, vector for conceptual, hybrid as production default.
• DON'T assume Data 360 / Data Library / RAG features exist unless Data 360 (formerly Data Cloud) is confirmed enabled.
• DON'T propose Sales Cloud agents (SDR/Coach/pipeline) for an org with no sales pipeline.
• DON'T build a single "super-agent" for multi-agent workflows — compose focused specialist agents and use MCP/Agent API for orchestration.
• DO configure Trust Layer masking explicitly for SSN, medical, DOB, and PII fields; DON'T assume defaults cover custom fields.
• DO keep the Trust Layer audit trail on — it's the compliance record. DON'T put PII/sensitive content in static grounding or logs.
• DO verify field API names + lengths + FLS with describe before wiring merge fields or agent actions.
• DO dry-run an action's SOQL as the agent user before trusting it.

Executable Workflows

Workflow 1 — Build and ship an agent topic + action with a least-privilege agent user

1. Create a dedicated named Salesforce user for the agent. Assign a minimal base profile (e.g. Minimum Access). Do NOT assign System Administrator or any "Modify All" permission.

→ gate: user created; profile confirmed as restrictive in Setup.

1. Identify exactly which objects and fields the agent's action(s) will read or write. Create a permission set granting only those object permissions and FLS (readable/editable as needed).

→ gate: describe each object as the agent user (or via runAs in Apex) — only the required objects/fields are accessible.

1. In Agent Builder, create the agent topic: write a tight scope description and explicit instructions including "when NOT to use this topic."

→ gate: topic scope is narrower than the default; Testing Center correctly routes a representative utterance to this topic and not to an unrelated one.

1. Build the action (Flow preferred over Apex when both work). Wire it to the topic. Dry-run the underlying SOQL/DML as the agent user before activating.

→ gate: SOQL returns the expected records as the agent user; no INSUFFICIENT_ACCESS error.

1. Test in Agentforce Testing Center with at least one happy-path utterance, one out-of-scope utterance, and one edge case (e.g. record not found). Review trustworthiness and topic-accuracy scores.

→ gate: scores meet your quality bar; misrouted utterances are addressed by tightening topic instructions.

1. Deploy the agent, its backing Flows/Apex, the agent user, and the permission set together to the target org. Confirm the agent user exists and the permission set is assigned before activating the agent.

→ gate: post-deploy query confirms agent user + permset assignment; agent activates without errors.

Workflow 2 — Build a grounded Field Generation prompt template safely (match field length, dynamic grounding)

1. Describe the target object: confirm the exact API name and character length of the destination field before writing the template.

→ gate: field length is documented; template's max-output instruction will be set to this value or below.

1. Identify all facts the template needs. Map each to a dynamic merge field (resolved at run time from the record or a related object via lookup traversal). Do NOT paste any record data as static text in the template body.

→ gate: zero hard-coded record facts in the template body; all variable content enters via merge fields.

1. Build the template in Prompt Builder as Field Generation type. Set an explicit max-output instruction in the prompt that matches (or is below) the field length from step 1. Assign the template's object/field target.

→ gate: template compiles; preview pane output is within field length on a real sandbox record.

1. Activate the template. Verify status = Active before referencing it from a Flow, page, or agent action.

→ gate: template status shows "Active" in Prompt Builder; draft templates don't resolve at run time.

1. Review Trust Layer masking configuration: confirm that any PII or sensitive fields flowing through merge fields are registered for masking. Verify in the Trust Layer audit trail after the first run.

→ gate: audit trail entry for the template invocation shows masked tokens where PII fields were grounded; no raw PII visible in the audit log.

Workflow 3 — Diagnose "agent can't access a record" (running-user CRUD → FLS → sharing)

1. Identify the agent user: check which named Salesforce user the agent is configured to run as in Agent Builder.

→ gate: agent user identity confirmed.

1. Check object-level CRUD: as the agent user's profile + permission set combination, confirm the target object has Read (and Write if needed) access. SOQL SELECT Id FROM Object__c LIMIT 1 as the agent user is the definitive test.

→ gate: object access confirmed or denied — if denied, add to the permission set and retest.

1. Check FLS: describe the object as the agent user and verify every field the action queries or writes is listed as accessible/editable. A missing field returns INVALID_FIELD in SOQL even with full object access.

→ gate: describe returns each required field with accessible: true; add missing fields to the permission set's <fieldPermissions>.

1. Check sharing: verify the agent user can see the specific record. OWD Private + no sharing rule means the agent user sees only records it owns. Confirm via SOQL WHERE Id = '<RecordId>' as the agent user.

→ gate: the specific record appears in the query result as the agent user; if not, add a sharing rule or adjust OWD.

1. If all three checks pass but the action still fails, inspect the Apex action's SOQL for hard-coded profile or role filters that might exclude the agent user.

→ gate: no phantom filter; action returns expected data in a test run logged as the agent user.

Decision scenarios

Original teaching scenarios — distinct from held-out eval scenarios in evals/.

Scenario 1 — Field Generation silent truncation

> Situation: A Field Generation template writes an AI description to custom > Description__c. The preview reads fine at ~500 chars, but saved values are > always cut off mid-sentence at the same spot — no error anywhere. > > Competent move: describe the object for the field's length — it's > almost certainly shorter than 500 (e.g., 255). Set the prompt's max-output > instruction at or below that, re-activate, re-test. Never assume a field > length; confirm with describe before wiring. > > Tempting-but-wrong: Raising the model's max-token setting. The model isn't > the constraint — the field length is — so the write still silently truncates. > > Verify: describe the object, read the target field's length, confirm > the prompt's output constraint is at or below it.

Scenario 2 — Agent user over-privileged "to make it work"

> Situation: A Service Agent's Apex action returns no records because the > agent user's profile has restrictive object access. The quick fix applied: > assign that user the System Administrator profile. > > Competent move: Identify exactly which objects, fields, and sharing the > action needs, and grant only those via a dedicated permission set. Dry-run the > action's SOQL as the agent user (or runAs in a test) to confirm records are > visible with minimal rights before go-live. > > Tempting-but-wrong: The admin profile clears the error but lets any prompt > injection or misconfigured action run with org-wide rights — the blast radius > becomes the whole org. Least-privilege is non-negotiable, not a nice-to-have. > > Verify: Query the affected objects as the agent user's profile + permission > set in Workbench or runAs, confirm records return, remove any excess.

Scenario 3 — Draft template not resolving at run time

> Situation: A Flow references a Prompt Builder Flex template to generate a > follow-up message. In testing the Flow throws a generic error on the Prompt > Builder step. The template was built last week and tested in the preview pane. > > Competent move: Check the template's status in Prompt Builder. A template > must be Active before any Flow, Lightning page, or agent action can invoke > it — if it reads "Draft," activate it and re-run the Flow. > > Tempting-but-wrong: Debugging Flow elements or opening a support case. The > template is the issue — drafts don't resolve at run time, and the generic error > masks it. > > Verify: Confirm template status = Active, re-run in a fresh debug, and add > a pre-deploy checklist step that verifies all referenced templates are Active.

Scenario 4 — RAG retriever for an org without Data 360

> Situation: A design calls for a Service Agent grounded on internal process > PDFs via Data 360 (formerly Data Cloud) vector search. The architect starts > building the Data Library, then finds the feature is unavailable in Setup. > > Competent move: Confirm Data 360 is provisioned (its DMO/DLO objects in > the object list, or the Data 360 section in Setup). If absent, RAG / Data > Library / vector search are unavailable — pivot to Knowledge articles for > unstructured grounding (Knowledge must be enabled), or scope Data 360 > provisioning as a funded prerequisite with budget and timeline impact. > > Tempting-but-wrong: Building Data Library config or promising a go-live > date before validating Data 360's presence — wasted effort against an unfunded > dependency. > > Verify: Check the object list for Data 360 objects before any design work; > document Data 360 as a dependency in the solution spec.

Scenario 5 — PII in static grounding bypasses Trust Layer masking

> Situation: To personalize a record-summary template, a developer pastes a > customer's full name and contract ID as fixed text in the template body > (static grounding) — later reused in production for real account data. > > Competent move: Move all record-specific facts — especially PII (name, ID, > contact info, DOB, financial data) — into dynamic merge fields resolved at run > time. Merge fields flow through the Trust Layer where masking applies; static > template text is never masked, whatever the Trust Layer config. > > Tempting-but-wrong: Assuming the Trust Layer masks static text like it > masks merge-field output. It does not — static body text reaches the LLM > exactly as written, with no masking pass. > > Verify: Review the template body for hard-coded record data; use describe > to enumerate PII fields and ensure each enters only via a dynamic merge field.

Study resources & relevance

Study resources (official Salesforce + community, practice exams, hands-on environments) and supplemental rules for Model Builder and Agent Channels (blueprint-covered topics with lower exam weight) are kept in references/study-resources.md. For NPSP/nonprofit-specific guidance, see salesforce-nonprofit-cloud-consultant.

Feedback protocol

Using this skill and hit a wall? If you find a claim contradicted by the live system or official docs, a missing rule that cost you a wrong attempt, or a decision this skill gave no criteria for — append an entry in the moment to .skill-feedback/salesforce-agentforce-specialist.md at the project root (create it if absent):

date | skill last-reviewed | claim or gap | what you observed instead | evidence (error text / doc URL / query output) | suggested fix

These are harvested back into the skill via the learning loop. When the live system and this file disagree, trust the live system.

Changelog

• 2026-06-11 — D10 right-size (wind-down): compressed the five decision-scenario prose blocks and tightened §6 Trust Layer rules; no facts removed. Body trimmed ~250 words toward the project's context-economy ceiling; all five scenarios retained (D9).
• 2026-06-10 — Cycle-4 curation (inbox): (1) Blueprint reweight: §1 Prompt Engineering corrected from 30% → 20%; §2 AI Agents corrected from 30% → 35% (largest domain); "largest topic" label removed from Prompt Engineering and moved to AI Agents. (2) New top-level sections added: §4 Development Lifecycle (20%) and §5 Multi-Agent Interoperability (5%) — both are current AI-201 exam domains. Service Cloud / Sales Cloud guard-rules folded into §4 (no longer standalone 10%-each framing). (3) Data Cloud → Data 360 rename (Dreamforce Oct 2025): all body occurrences updated; "Data 360 (formerly Data Cloud)" on first use, description field, volatile tags, scenarios, quick reference, and study-resources. (4) Passing score: 72% → 73% (44/60) [volatile — verify live] in study-resources.md. Sources: salesforceben.com/salesforce-agentforce-specialist-certification-guide-tips/ (domain weights, passing score); salesforceben.com/salesforce-data-cloud-renamed-to-data-360-as-part-of-agentforce-360/ (Data 360 rename). Domain percentages marked [volatile — verify live].
• 2026-06-09 — Conformed to the 12-dimension skill standard: task-vocab description + Scope block, Uncertainty & Escalation guidance with inline [volatile — verify live] marks, executable workflows, tool-agnostic verify steps, and the feedback protocol above. Exam logistics relocated to references/study-resources.md; last-reviewed set to 2026-06-09.

Independent educational content to upskill AI agents. Not affiliated with or endorsed by Salesforce; all trademarks belong to their owners. Guidance only — verify against official documentation and live orgs. No certification outcome is implied or guaranteed.