Home / architect / salesforce-learning-research

salesforce-learning-research

Research a Salesforce topic for a learner using a citation-first, release-aware evidence workflow: bound the question, prioritize official sources, build a claim ledger, resolve contradictions, and produce a research packet for teaching. Trigger keywords: research Salesforce topic, find official Salesforce docs, prepare learning sources, verify Salesforce concept, release-aware research. Repository package authoring and upstream intake remain outside this package. NOT for the final learner-facing explanation — use admin/salesforce-learning-brief.

v1.0.0
Salesforce Summer '26+
Updated 2026-09-01
Reliability
User Experience
Operational Excellence

learning-research
source-hierarchy
citations
freshness
evidence-ledger
contradiction-resolution

Open the skill folder on GitHub

Salesforce Learning Research

Use this skill to establish what can responsibly be taught about a Salesforce topic before writing the lesson. It separates evidence acquisition from explanation so the final learning brief cannot turn stale release guidance, org assumptions, or community opinion into timeless platform fact.

This is an end-user research workflow. It does not replace the repository's build-time content-researcher agent, upstream intake, source manifest, or skill-authoring validation.

Research Packet Contract

Section	Required content
Research question	Learner's question, role/level, desired outcome, and explicit boundaries
Context identity	Cloud/product, release/API version, org/package context, and observed date when relevant
Terminology	Official names, aliases, renamed products, deprecated terms, and disambiguation
Source inventory	Source ID, title, owner, tier, publication/update date, retrieval date, scope, and URL/reference
Claim ledger	Atomic claim, state, evidence IDs, applicability, confidence, and teaching implication
Contradictions	Conflicting statements, winner under source hierarchy, and unresolved conditions
Freshness	Current, preview/beta, retired, historical, or unknown status for release-sensitive content
Gaps	Questions the sources do not support and evidence still needed
Brief handoff	Ordered concepts, examples safe to teach, caveats, and knowledge-check targets

Do not copy large passages into the packet. Record concise original summaries and stable citations.

Bound the Learning Question

Capture:

learner role and current experience;
what they should be able to explain or do afterward;
whether the topic is conceptual, procedural, architectural, diagnostic, or release-specific;
relevant Salesforce cloud, product, edition, license, API version, package, or org context;
exclusions and neighboring concepts that should route to another brief;
supplied sources that must remain the sole basis, when the user requests source-bounded work.

A broad prompt such as "teach me Flow" needs a narrower outcome before research. A bounded prompt such as "explain before-save versus after-save record-triggered Flow to an admin who knows formulas" has a researchable evidence surface.

Source Hierarchy

Apply standards/source-hierarchy.md. Use the source best suited to the claim rather than treating every Salesforce-owned page as interchangeable.

Claim type	Preferred evidence
Current behavior, limits, API, metadata, security contract	Salesforce product/developer documentation and current release notes
Architecture patterns and tradeoffs	Salesforce Architects guidance, then official developer guidance
Guided learning sequence	Trailhead or official learning content, verified against product docs for exact behavior
Current tooling command or option	Official CLI/tool documentation for the installed major version
Feature availability or lifecycle	Current release notes and official product availability documentation
Org-specific state	Read-only evidence from the explicitly identified org or user-provided snapshot
Practitioner nuance absent from official sources	Named expert source, explicitly lower confidence, corroborated per repository policy

Rules:

A lower-tier source never overrides a higher-tier source on platform behavior.
Current release notes override older product documentation when behavior changed.
Documentation proves platform capability, not target-org entitlement or activation.
Search snippets are discovery aids, not final evidence; open the source before recording the claim.
AI-generated summaries, including this repository's own skills, are navigation aids unless their underlying sources are inspected.
When the user says to use only attached material, do not silently fill gaps from the web or general knowledge.

Atomic Claim Ledger

Each row should make one testable statement.

Field	Meaning
`claim_id`	Stable identifier such as `C-01`
`claim`	One factual or recommendation statement in original wording
`state`	`verified-fact`, `official-recommendation`, `inference`, `assumption`, `unknown`, or `unsupported`
`evidence_ids`	One or more source or org evidence identifiers
`applicability`	Product, edition, release/API version, environment, persona, or file type
`freshness`	`current`, `preview`, `beta`, `retired`, `historical`, or `unknown`
`confidence`	`HIGH`, `MEDIUM`, or `LOW` with a short reason
`teaching_implication`	What the final brief may say, must qualify, or must omit

Never combine a verified platform behavior and an inferred best practice in one row. Split them so the final brief can label each correctly.

Freshness and Lifecycle

For every release-sensitive claim, record:

publication or last-updated date when visible;
retrieval date;
Salesforce release or API version;
feature status such as GA, beta, developer preview, retired, or announced;
enforcement or rollout date when the official source states one;
whether the target org can be assumed to have received the release.

Use absolute dates in the packet. Do not write "recently", "now", or "next release" without anchoring the date and release.

A repository skill may summarize an older behavior accurately for its stated version. Do not label it wrong solely because it is historical; label its applicability and keep it out of a current brief unless history is relevant.

Contradiction Resolution

Confirm that the sources discuss the same product, release, API, license, and context.
Prefer the higher source tier; within Tier 1, prefer the more current and more specific source.
Check whether one source is preview/beta while the other describes GA behavior.
Separate a product guarantee from an implementation recommendation.
Record the losing statement and why it does not control; do not silently discard it.
When authoritative sources still conflict, mark the claim unknown, explain the conflict, and prevent the final brief from asserting either side as settled.

Recommended Workflow

Bound the learning question by defining the learner outcome, mapping ambiguous/renamed terminology, and recording product, release, API, org, and source boundaries.
Plan and retrieve evidence by claim type—behavior, limit, procedure, architecture, lifecycle, or org state—and search the strongest authorized sources first.
Build the evidence packet with source inventory, observed dates, stable references, atomic claims, applicability, freshness, and confidence. Use original synthesis rather than copied upstream expression.
Resolve contradictions and gaps using repository policy. Preserve unsupported, stale, inaccessible, or conflicting claims instead of silently choosing a convenient answer.
Design the teaching handoff with concept order, safe examples, caveats, checks for understanding, and the claim IDs that must remain cited.
Validate and hand off the packet with the bundled checker, then pass it to admin/salesforce-learning-brief for learner-facing synthesis.

Quality Gates

[ ] Learner role, level, outcome, and scope are explicit
[ ] Product/cloud and release/API context are pinned where material
[ ] Terminology and product renames are resolved
[ ] Every source has owner, tier, date/retrieval date, scope, and reference
[ ] Every material statement is an atomic claim with a state
[ ] Release-sensitive claims carry freshness and applicability
[ ] Recommendations are not labeled as platform guarantees
[ ] Org-specific claims use identified org evidence or remain unknown
[ ] Contradictions and unsupported claims are preserved, not hidden
[ ] Search snippets and AI summaries are not the sole evidence
[ ] The handoff tells the learning brief what it may teach and what it must qualify

Output and Validation

Create the packet from templates/salesforce-learning-research-template.md, then run:

python3 skills/architect/salesforce-learning-research/scripts/check_salesforce_learning_research.py --input path/to/research-packet.md

A passing packet is evidence-ready, not automatically correct. Review source relevance and claim interpretation before teaching.

admin/salesforce-learning-brief — turn the verified packet into a learner-facing explanation and practice sequence.
Repository content-researcher agent — research and author canonical SfSkills content; it has provenance, licensing, and repository-specific responsibilities this skill does not perform.
architect/salesforce-decision-analysis — compare viable options; use learning research only to supply evidence for concepts the decision depends on.
Domain skills — supply bounded practitioner guidance after their sources and release applicability are verified.

See the bundled references for example packets, contradiction cases, and common research failures.