Every rule we check. Every source. Every one we turned down.

What it requires. An agent action that is defined but attached to no topic, so no agent can ever reach it.

Why it matters. An orphaned action is configuration that looks like capability. It appears in the action list, it is counted when someone asks how much the agent can do, and it never runs. The planner routes through topics, so an action outside every topic is unreachable by construction rather than by accident.

How to fix it. Attach the action to the topic that should own it, or delete it. Leaving it in place makes the agent look more capable than it is.

Source. Agentforce planner model: actions are reached through topics

AG-001 on its own page

What it requires. A topic carrying no example utterances, leaving the planner nothing to match a user request against.

Why it matters. Routing is the planner deciding which topic a request belongs to. With no examples the decision is made on the topic name and scope alone, so requests land in the wrong topic or in none. This fired five times on the first prototype run, making it the most common finding in that run.

How to fix it. Add example utterances in the words customers actually use, not the words the topic is named after.

Source. Prototype run against a live org, 30 August 2026 (5 of 10 findings)

AG-002 on its own page

What it requires. A merge field or grounding reference naming a field that is absent from the org.

Why it matters. The agent does not error on a missing field, it substitutes silently, so the prompt reaches the model with a hole in it and the answer is produced from what remains. Common after a migration or a managed-package change, and invisible in the output.

How to fix it. Repoint the reference at the field that replaced it, or remove the reference and the sentence that depended on it.

Source. Prompt template merge-field resolution behaviour

AG-003 on its own page

What it requires. Field-level security or sharing hides grounded data from the user the agent runs as, so the agent answers from nothing.

Why it matters. The agent inherits its running user's visibility. Where sharing or field-level security removes a record or a field, the grounding returns empty and the model answers anyway, fluently, from whatever remains. Nothing in the output distinguishes this from a correct answer. With AG-016 established, this is the bound on every downstream quality claim rather than one check among many.

How to fix it. Check the running user's profile and sharing against every object and field the agent grounds on. Where access is deliberately withheld, remove the grounding rather than leaving the agent to answer around it.

Source. Agentforce running-user model; our grounding quality specification v1

AG-004 on its own page

What it requires. An action pointed at a corpus that is not enabled, or at an object holding no records.

Why it matters. An empty source reads exactly like a source with nothing relevant in it. The agent answers from adjacent material and sounds no less certain. This fired on the first prototype run against a real org, which is why it leads this family rather than sitting inside it: the failure is not rare and it is not visible.

How to fix it. Enable the corpus, or point the action at the source that actually holds the content. If neither, remove the action.

Source. Prototype run against a live org, 30 August 2026 (fired first pass)

AG-005 on its own page

What it requires. A field the agent reads is empty on a large enough share of records that the answer is usually produced without it.

Why it matters. A field that exists and is mostly empty grounds nothing. The agent still reads it, still produces an answer, and the answer is built from whatever else was in the prompt.

How to fix it. Populate the field, or stop grounding on it and say in the topic scope that the agent cannot answer from it.

Source. Our grounding quality specification v1, section 3

AG-006 on its own page

What it requires. One value dominates a grounded field so heavily that the field distinguishes nothing.

Why it matters. A field where 98% of records share a value carries almost no information, but it looks like a populated field to anyone reviewing the configuration. The agent uses it and the answers do not vary with it.

How to fix it. Ground on the field that actually varies, or accept that answers cannot be differentiated on this dimension and say so in the scope.

Source. Our grounding quality specification v1, section 3

AG-007 on its own page

What it requires. A free-text field grounded into a prompt where values are so dispersed that retrieval cannot rank them.

Why it matters. Free text with no controlled vocabulary gives retrieval nothing to match on, so what surfaces is close to arbitrary and varies between otherwise identical questions.

How to fix it. Introduce a controlled field alongside the free text and ground on that, keeping the free text for the human reader.

Source. Our grounding quality specification v1, section 3

AG-008 on its own page

What it requires. The same question is answered by more than one record, so the answer depends on which surfaces first.

Why it matters. Duplicate or near-duplicate sources make the agent non-deterministic in a way nobody can see from the configuration. Two users ask the same thing and get different answers, both defensible, neither reproducible.

How to fix it. Merge or retire the duplicates, and make one record canonical for each question.

Source. Our grounding quality specification v1, section 3

AG-009 on its own page

What it requires. The last-modified distribution of a grounded source is skewed old enough that the agent is citing retired reality.

Why it matters. Staleness is invisible in the output: the agent cites an old record as confidently as a current one. It fired on the first prototype run. Note this is a measurement of the business, not of a sandbox - a refreshed copy carries the refresh date, not the record's real age.

How to fix it. Review and retire the stale records, or narrow the grounding to a recency window the business actually maintains.

Source. Prototype run against a live org, 30 August 2026

AG-010 on its own page

What it requires. Knowledge articles in a non-published state, or long unreviewed, that the agent can still retrieve and quote.

Why it matters. An archived article is a decision that it should no longer be relied on. If retrieval can still reach it, that decision has been recorded and not enforced, and the agent will quote it as current.

How to fix it. Exclude non-published states from the retrieval scope, and set a review cadence for the rest.

Source. Salesforce Knowledge article lifecycle states

AG-011 on its own page

What it requires. A topic's stated scope promises to answer about a domain that its grounding does not cover.

Why it matters. The scope is what the planner routes on and what a reader takes as the agent's remit. Where it is broader than the grounding, requests route in correctly and are answered from nothing relevant. This is an irreducibly semantic check and is reported as a judgement rather than a measurement.

How to fix it. Narrow the scope to what the grounding supports, or widen the grounding to match the promise.

Source. Our grounding quality specification v1, section 3

AG-015 on its own page

What it requires. An action that resolves its target at runtime, so the grounding surface is everything the running user can see rather than a declared field list.

Why it matters. Actions such as queryRecords, identifyObject and getRecordFieldsAndValues decide what to read when they run. There is no field list to review, so the honest description of what the agent is grounded on is the whole visible estate. That is the finding: not that a particular field is exposed, but that the question "what is this agent grounded on?" has no bounded answer.

How to fix it. Replace runtime resolution with a declared grounding target where the use case allows. Where it does not, treat the running user's visibility as the grounding scope and review it as such.

Source. Our grounding quality specification v1, section 5

AG-016 on its own page

What it requires. A prompt template or agent action invoked inside a loop, once per record, where the platform offers a bulk or batched path.

Why it matters. Metered per action, the naive shape is expensive in a way that does not show up until the bill. At 20 Flex Credits an action, a per-record call across a 5,000-row job is a $500 line item where a batched design costs a fraction of it. Measured on the same shape, 109 evaluations through one batch took about 11.6 minutes rather than 36 times the duration of a single call, which is why batching is the remedy rather than an optimisation.

How to fix it. Move the call outside the loop and pass the collection, or use the platform's batched path.

Source. Salesforce Flex Credits pricing; our batch runner implementation

AG-017 on its own page

What it requires. An agent, topic, action or prompt template has been changed since the version that is actually live, so the org's behaviour and its configuration disagree.

Why it matters. A save that succeeds is not a deployment, and nothing downstream tells the two apart: an updated component can sit in a draft for days while the active version keeps serving, and every run in between looks healthy. The consequences are silent by construction - an old version running past a ceiling the new one was written to clear, or stale configuration in every delivered output - because the deploy step reported success. The check is to read the active version, never to infer it from a successful save. On prompt templates the platform states this directly, exposing an active version identifier alongside each version's own.

How to fix it. Compare the active version against the latest edited version for every agent, topic and template, and republish or revert so they agree.

Source. Root-cause records, August 2026; Salesforce prompt template version metadata

AG-018 on its own page

What it requires. A topic whose instructions say nothing about what happens when an action errors, times out or returns empty, and an action path with no fault handling behind it.

Why it matters. Unhandled failure in an agent does not stop the conversation, it changes the answer. The model continues without the data and produces something plausible. The same shape upstream is worse: a run left in an intermediate state can be invisible to every downstream stage at once - the report, the delivery and the chase queue alike - so nobody is ever told. On the org this was written against, not one of twenty-one instructions mentioned failure at all.

How to fix it. Add a fault path to every flow-backed action, and state in the topic instructions what the agent should say when an action returns nothing.

Source. Our defect handling standard, 16 August 2026

AG-019 on its own page

What it requires. A prompt template or action asked for a set of things - every case, each product, all the reasons - with no structured output and no completeness check, so a response missing items reads exactly like a complete one.

Why it matters. An evaluator that returns a schema keyed by rule code cannot omit a rule without failing validation. With no such guard, coverage drift is invisible: rules go unevaluated behind a plausible-looking total, and nothing distinguishes a run that checked everything from one that quietly checked less. With it, a run either carries the expected rows for every subject - 1,147 checks of 1,147 - or it fails outright. A generation with no output schema has no equivalent guard, and a short answer is a well-formed one.

How to fix it. Give the template an output schema listing what must come back, so an incomplete answer fails instead of reading as complete.

Source. Our evaluator coverage design, August 2026

AG-020 on its own page

What it requires. A generation whose length limit is low enough that answers are cut off, with no indication to the reader that anything was lost.

Why it matters. A response cut off at max_tokens presents as a model failure rather than a limit, and costs real time to diagnose, because a truncated response is a well-formed one - it ends, it reads, and nothing marks the point where it stopped. It is the same failure class as AG-020 and worth keeping separate because the fix is a number rather than a schema.

How to fix it. Raise the limit to fit the longest legitimate answer, or have the template return a structured result whose completeness can be checked.

Source. Root-cause record, max_tokens truncation, August 2026

AG-021 on its own page

What it requires. An agent path where the do-nothing outcome and the success outcome are indistinguishable to everyone downstream: no signal, no counter, no field that would look different.

Why it matters. This is the failure that reports itself as success, and the shapes recur: a storage path column empty on every record while the process reads as though files were stored; a discounted order that takes the payment branch, reports completion and never starts what was ordered; a double-encoded column that makes a discount unreachable with nothing going red anywhere. It is semantic and hard, and it describes the failures nobody reports.

How to fix it. For each path, name the field that would look different if it had worked, and assert on it. If there is no such field, that is the defect.

Source. Standing check: if this silently did nothing, what would look different?; root-cause records, August 2026

AG-022 on its own page

What it requires. The org's own retention promise and what the platform actually keeps disagree - transcripts, prompts, grounded record values and audit rows.

Why it matters. A stated retention of "none" on a connection record says nothing about what the orchestration around it keeps. Where that platform logs every step's input and output, a single execution can hold the same customer's pricing metadata three times over, alongside their client name and instance URL: a promise made in one system and not kept by another. Note the audit surface is not in Salesforce core, so the check reaches beyond the org's own configuration.

How to fix it. Reconcile the published retention policy against what each platform in the path actually stores, and change whichever is wrong - usually the system, sometimes the promise.

Source. Retention root-cause record, August 2026; Einstein Trust Layer audit documentation

AG-023 on its own page

What it requires. A large or high-effort model configured for a task that is lookup or formatting, where a smaller model is equivalent.

Why it matters. Retrieval earns no reasoning budget; judgement does. Where an action is fetching or reformatting, a larger model costs more per call and returns nothing extra. With actions metered individually the difference is measurable rather than theoretical. The template's own type says which shape it is.

How to fix it. Move lookup and formatting templates to the smaller model and keep the larger one where a verdict is being formed.

Source. Our LLM budget ruling; Salesforce Flex Credits metering

AG-024 on its own page

What it requires. Text that a stranger can write - web-form fields, inbound email bodies, case descriptions, chat transcripts - is grounded into a prompt for an agent that can take actions or emit outbound links.

Why it matters. ForcedLeak (CVSS 9.4, Noma Labs, September 2025) submitted instructions through Web-to-Lead which executed later during an ordinary employee interaction and exfiltrated CRM data. Salesforce patched it - re-securing the domain and enforcing a URL allowlist on agent output - and that patch is the vendor's own evidence that the platform did not prevent it. The documentation describes prompt defence as heuristics that reduce the odds, not eliminate them. The check is not whether the Trust Layer is on; it is which untrusted fields reach a grounded prompt and what the agent can do once they are there.

How to fix it. Separate untrusted inbound fields from grounded prompts, or strip them to a controlled vocabulary before grounding. Where they must be grounded, restrict the agent's action scope on that surface.

Source. ForcedLeak, Noma Labs, September 2025 (CVSS 9.4); Salesforce Trust Layer documentation

AG-025 on its own page

What it requires. Two or more actions with the same target and overlapping descriptions, reachable from the same agent.

Why it matters. More tools do not always lead to better outcomes, and overlapping tools distract an agent from pursuing efficient strategies. This is a cited behavioural claim rather than a tidiness preference, and it comes with a fix: namespacing, or removing the duplicate.

How to fix it. Remove the duplicate, or namespace the two so their descriptions no longer compete for the same request.

Source. Anthropic tool-design guidance on overlapping tools

AG-026 on its own page

What it requires. An article whose answer to its own title sits deep in the body, so retrieval returns the background instead.

Why it matters. Retrieval pulls passages, not documents. Where the answer is in paragraph nine and the opening is context, what reaches the model is the context. This is structure rather than judgement, which is what makes it detectable.

How to fix it. Move the answer to the top of the article and leave the background beneath it.

Source. Support-agent knowledge base literature

AG-027 on its own page

What it requires. No content stating that a thing is unsupported, so the agent constructs a plausible answer from adjacent material.

Why it matters. With nothing saying a feature does not exist, an agent will often construct a plausible answer from adjacent material - which is a promise of something that does not exist, made to a customer, in writing. A coverage gap with a commercial consequence attached.

How to fix it. Write the negative cases down. An article saying plainly that something is not supported is worth more than one describing what is.

Source. Support-agent knowledge base literature

AG-028 on its own page

What it requires. An article that never uses the phrasing customers use, so it loses retrieval to a less relevant one that does.

Why it matters. Retrieval matches language, not intent. An article written in internal vocabulary is invisible to the request it answers, and the request is answered by something worse.

How to fix it. Add the customer's phrasing to the article - as a heading, an alternate title, or keywords - without rewriting the substance.

Source. Support-agent knowledge base literature

AG-029 on its own page

What it requires. An action that writes, sends, refunds, cancels or deletes, reachable by the planner with no confirmation step and no human in the loop.

Why it matters. To the planner an irreversible action is just another tool. The interesting version of this check is not "no confirmation anywhere" but "no confirmation on the irreversible ones specifically". On the org this was written against, exactly one of twenty-nine actions required confirmation - the record write - while an action that modifies automation metadata and two that send outbound to a third party carried none.

How to fix it. Set confirmation on every action whose effect leaves the org or cannot be undone, and review the default on any action installed by a package.

Source. General agent design practice; probe of a live org, 31 August 2026

AG-030 on its own page

What it requires. An action that is not safe to run twice, on a path that can run it twice - a retry, a re-planned step, or a user repeating themselves.

Why it matters. Planners retry, and users repeat themselves. Where the action creates, sends or moves money, the second run is a second real-world effect. The remedy is an idempotency key derived from the run itself, so a retry cannot double-charge or double-refund; without one the failure is silent and expensive.

How to fix it. Give the action an idempotency key derived from the request rather than the attempt, or gate it behind a confirmation the planner cannot repeat.

Source. Our refund model implementation

AG-031 on its own page

What it requires. A topic with no test utterances, or with utterances that have not been re-run since the topic last changed.

Why it matters. Salesforce ships Testing Center and vendors sell generated utterance sets, but nobody checks whether the set was run after the last change. This is the agent form of the standard we hold ourselves to: the tests changed in the same edit as the behaviour, or they prove nothing. On the org this was written against, every scorer was a shipped predefined one and there was not a single custom evaluation.

How to fix it. Write utterances for each topic and re-run them as part of any change to that topic, not on a schedule.

Source. Salesforce Testing Center; our standing check that tests change with the behaviour

AG-032 on its own page

What it requires. A topic scope or action description a competent reader could not act on without outside knowledge: unstated abbreviations, internal process names, or an instruction whose success condition is not stated.

Why it matters. The provider's own standard is better than any threshold we would invent: put yourself in the model's shoes, and ask whether it is obvious how to use this tool from the description and parameters alone. This is irreducibly semantic and is reported as a judgement rather than a measurement. A related shape is worth naming: a sequencing constraint stated only as an instruction - "call X before Y" - is a hope, not a control.

How to fix it. Rewrite the instruction so its success condition is stated and its terms are defined in it. Where the constraint must hold, enforce it in the action rather than asking for it.

Source. Anthropic tool-description guidance

AG-033 on its own page

What it requires. A numeric literal (a rate, a price, an uplift) sits inside a pricing element formula or parameter instead of a decision table or price book reference.

Why it matters. [reasoned from platform semantics] A literal in a step lives in versioned procedure metadata: changing it is a builder-access version edit and re-activation, invisible to data governance, and duplicated copies drift silently. Finance reads one price in the catalog while the engine charges another.

How to fix it. Move the value into the decision table or price source the element should reference; the number becomes data with an audit trail.

Source. Salesforce Help: Use Pricing Elements in Pricing Procedures (semantics; mechanism reasoned)

RC-001 on its own page

What it requires. A sequence of conditional elements enumerates cases (per-segment rates, per-product uplifts) that a single decision table lookup would serve.

Why it matters. [reasoned; corroborated by practitioner literature] Each ladder step is a sequential evaluation inside the procedure's runtime budget (one-minute default, two-minute maximum for a pricing procedure; a discovery procedure gets 10 seconds by default and 60 at most) and an element against the 130-per-version cap; a decision table is one compiled, indexed lookup - the platform's stated purpose for them. Adding a tier becomes a row plus refresh, not a version edit. Two guards on the fix: a decision table answers from its last refresh, so the conversion must arrive WITH refresh discipline (see RC-008) or it introduces a stale-price failure the ladder never had; and trivial logic stays inline - a single condition is not a ladder, and converting it buys nothing.

How to fix it. Collapse the ladder into one decision table and one lookup element.

Source. Kavaliro: RLM Pricing Procedures (practitioner); Salesforce Pricing Limits (budgets)

RC-002 on its own page

What it requires. Context mappings pull unconventional custom fields or loosely named variables instead of standard pricing-context attributes.

Why it matters. [reasoned] The context definition is the contract between quote data and the engine: ad hoc mappings couple pricing to unstable schema, faults surface at quote time, and clutter obscures the release-time diff the extension mechanism exists to carry.

How to fix it. Map standard attributes where they exist; name and document any custom mapping as deliberately as a public interface.

Source. Salesforce KB 004259656 (adjacent extension guidance; mechanism reasoned)

RC-003 on its own page

What it requires. A procedure or model carries many inactive versions or undated drafts ahead of the active version.

Why it matters. [reasoned; live-observed 27 Aug 2026] The active version is one status flip among lookalikes: people debug the wrong version, and drafts read as deployed. In production the same state is a heavier signal than in a sandbox workshop - severity is environment-modulated by design. Two allowances: a draft ahead of the active version with a FUTURE start date is deliberate staging, not sprawl - versions carry effective-date windows for exactly that; and numbering gaps alone prove nothing, because cross-org deployments renumber versions. The signal is inactive volume plus undated drafts ahead of active.

How to fix it. Retire superseded versions; keep one active optimised version and at most one deliberate draft.

Source. Salesforce Help: Build Your Pricing Procedures (versioning semantics; mechanism reasoned)

RC-004 on its own page

What it requires. Assignment arithmetic re-derives group totals that a GroupingAndAggregatePricing element should compute.

Why it matters. [reasoned] The aggregation element computes group totals once inside the waterfall; hand-rolled copies diverge when one is edited, and the Price Waterfall's per-element explanation degrades into opaque assignments - discarding the debuggability the platform sells. Two documented carve-outs where manual arithmetic is the only option and is NOT a defect (Trailhead, advanced price management): aggregation elements do not support derived products, and direct rollup to quote or order headers is not supported. Line-level unit arithmetic and those two cases pass this check.

How to fix it. Replace the arithmetic with the aggregation element and let dependent elements read its output.

Source. Salesforce Help: Use Pricing Elements in Pricing Procedures (element vocabulary; mechanism reasoned)

RC-005 on its own page

What it requires. A context definition carries values in both ClonedFrom and InheritedFrom (Tooling API fields).

Why it matters. [doc] Salesforce's own words: such a definition "can result in unexpected pricing errors and should be recreated", and "the InheritedFrom field should be blank if ClonedFrom is populated" (KB 004259656). The platform's default-procedure error path separately requires extension-not-clone lineage (KB 002183049). Two contradictory lineages; the sanctioned remedy is recreate, not repair.

How to fix it. Recreate the definition as a clean extension of the standard, then re-associate its procedures.

Source. Salesforce KB 004259656; KB 002183049

RC-006 on its own page

What it requires. A custom context definition was cloned rather than extended and lacks mappings the standard definition has since gained.

Why it matters. [doc] Extending a standard definition carries automatic upgrades and a Sync Now option, so mappings added by later releases arrive on their own; a clone of a standard definition gets "no automatic upgrades" (Salesforce Help, Clone a Context Definition). The exception is the thing this check keys on: a clone of an already-extended definition keeps its upgrades only when Preserve Inheritance was enabled, which is exactly the ClonedFrom-populated-with-InheritedFrom-empty state. A mapping that never arrived means the attribute is silently null in context, so every element referencing it no-ops: wrong price, no error. Separately, a definition carrying BOTH lineages "can result in unexpected pricing errors and should be recreated" (KB 004259656) - that is RC-006.

How to fix it. Recreate as an extension, or diff against the current standard and add the missing mappings deliberately.

Source. Salesforce Help: Clone a Context Definition (clone vs extend upgrades); Salesforce KB 004259656 (lineage)

RC-007 on its own page

What it requires. A decision table's source object rows were modified after the table's LastSyncDate.

Why it matters. [doc] A decision table is a compiled snapshot: it does not update when source data changes, and answers from the old compilation until refreshed (Salesforce Help). Modifications during a refresh may not be integrated, and an invocable Refresh Action exists for automation - so unrefreshed price rows are a standing wrong-price mechanism, not a hypothetical. In a sandbox, state the sandbox refresh date alongside: staleness predating it describes nothing.

How to fix it. Refresh the table now, and wire the Decision Table Refresh Action into whatever automation changes the source rows.

Source. Salesforce Help: Refresh a Decision Table; Decision Table Refresh Action

RC-008 on its own page

What it requires. A price-impacting product attribute (ProductAttributeDefinition.IsPriceImpacting) has a text data type with no picklist.

Why it matters. [practitioner-corroborated + reasoned] Pricing matches on attribute values: free text admits case, spacing and typo variants that miss exact-match lookups, so the adjustment silently never applies and a fallback price is charged. Corroborated across practitioner sources (arraytrail; Applikon); CML's keep-domains-small guidance states the same principle for configuration. Official Help pin outstanding.

How to fix it. Convert the attribute to a picklist so every value is matchable by construction.

Source. Practitioner (arraytrail; Applikon), corroborated; official pin pending

RC-009 on its own page

What it requires. The org's recipe/plan routing lacks a valid default pricing procedure for quotes that match no rule.

Why it matters. [doc] The platform fails such quotes at quote time with a named error: "The default pricing procedure must be associated with a context definition that's an extension of SalesTransactionContext__stdctx" (KB 002183049). Sellers are blocked in the moment of selling.

How to fix it. Set a default pricing procedure whose context definition extends the standard, so every quote prices deterministically.

Source. Salesforce KB 002183049

RC-010 on its own page

What it requires. An active procedure version's element count approaches the documented default of 130 elements per version (raisable to a documented maximum of 200 by a Salesforce support case, assessed individually for performance impact).

Why it matters. [doc] At the cap the next pricing change fails with a hard error - "Delete a pricing element and try again" (KB 005385232) - mid-change, with a support request as the only relief: the case goes to the Revenue Cloud Feature Activation team and is assessed individually for performance impact. The ceiling is documented rather than open-ended: Salesforce Pricing Limits gives pricing elements per pricing procedure as default 130, maximum 200, and the same page caps a pricing procedure's runtime at a one-minute default and a two-minute maximum, which tightens with element count. Findings state the default, the documented maximum and the support-case path, and never promise that a particular increase will be granted.

How to fix it. Consolidate redundant elements, split map-heavy elements, move mapping logic into decision tables, or route strategies through a plan. Where the design genuinely cannot be simplified, the support case is the documented path to a higher limit, up to 200.

Source. Salesforce KB 005385232; Salesforce Pricing Limits

RC-011 on its own page

What it requires. Near-duplicate products differ only by tokens an attribute should carry (size, term, tier), multiplying the catalog.

Why it matters. [practitioner: Cloud Giants] "Companies have long been guilty of SKU proliferation" - each variant-as-SKU multiplies every downstream artefact (price rows, selling models, components, table rows keyed by product) into a multiplicative maintenance surface, where attributes carry the same variance as data through one product.

How to fix it. Model the variance as attributes on one product; retire the variant SKUs as they fall out of quotes.

Source. Cloud Giants: RCA products guide

RC-012 on its own page

What it requires. Active products lack descriptions or drift from any naming convention.

Why it matters. [practitioner: Cloud Giants] "Define a consistent Product Name, SKU and Code convention. Populate Product Descriptions." Names and descriptions are the catalog's human interface - quoting UI, approvals and reports surface them; blanks invite mis-selection and unreviewable approvals.

How to fix it. Populate descriptions and settle one naming convention; enforce it at product creation.

Source. Cloud Giants: RCA products guide

RC-013 on its own page

What it requires. CML source references pricing fields such as ListPrice or NetUnitPrice.

Why it matters. [doc] "Pricing fields, such as ListPrice, NetUnitPrice, and others, are not supported in CML and should not be used in constraint models" (CML Best Practices). The constraint engine does not evaluate pricing context, so such constraints silently fail to enforce - configurations pass that should not.

How to fix it. Remove pricing references from the model; express commercial limits through pricing procedures and adjustments where they are evaluated.

Source. Salesforce CML Best Practices (developer guide)

RC-014 on its own page

What it requires. Relations carry no cardinality in CML AND the catalog's component rows carry no Min/MaxQuantity or required flags - nothing bounds the solver anywhere.

Why it matters. [doc + practitioner: Khaled McGonnell, 27 Aug 2026] Cardinality belongs in product master data (ProductRelatedComponent, ProductComponentGroup), which the configurator enforces; CML should not duplicate it. Where NEITHER declares bounds, the solver enumerates combinations it cannot bound ("specify the smallest required cardinality... to avoid testing unneeded combinations" - CML Best Practices), and an empty or gutted bundle is a legal configuration.

How to fix it. Set Min/MaxQuantity and required flags on component rows and group minimums in the catalog; reserve CML cardinality for what master data cannot express.

Source. Salesforce CML Best Practices; practitioner mechanism attributed (Khaled McGonnell, 27 Aug 2026)

RC-015 on its own page

What it requires. CML uses lineItemQuantity or ItemEndQuantity to create components rather than treating them as read-only.

Why it matters. [doc + practitioner: Khaled McGonnell, 26 Aug 2026] "Treat lineItemQuantity and ItemEndQuantity as read-only... Drive component creation by cardinality, not by attribute references" (CML Best Practices). A cardinality constraint tells the solver the valid range directly; rule-driven creation forces it to enumerate and test combinations, and the cost compounds with permutation growth - practitioner-confirmed as disastrous for performance.

How to fix it. Declare the component range as cardinality; use quantity fields only in calculation and evaluation rules.

Source. Salesforce CML Best Practices; practitioner mechanism attributed (Khaled McGonnell, 26 Aug 2026)

RC-016 on its own page

What it requires. Multiple conditional setdefault rules target the same assignment.

Why it matters. [doc + reasoned] "When multiple setdefault rules target the same assignment in the RHS, evaluations can conflict" and "only the last rule will reliably evaluate" (CML Best Practices) - earlier rules are not merely lower priority, they are unreliable. The configured default depends on evaluation order the modeller does not control, and an edit elsewhere can flip it.

How to fix it. Consolidate the conditional logic into a single derived variable with one setdefault.

Source. Salesforce CML Best Practices (developer guide)

RC-017 on its own page

What it requires. Relation declarations do not follow the documented LHS-first ordering for the constraints that use them.

Why it matters. [doc] "Order of relations matter for constraint evaluation. Specify the relations used in the LHS of the constraints first, followed by those in the RHS" (CML Best Practices). That sentence is the strongest published claim: Salesforce states that ordering matters for constraint evaluation, and no measurements of the cost exist publicly. Detection requires parsing, not grep - build cost noted.

How to fix it. Reorder relation declarations to match constraint LHS-then-RHS usage.

Source. Salesforce CML Best Practices (developer guide)

RC-018 on its own page

What it requires. The active discovery procedure and pricing procedure are associated with different context definitions.

Why it matters. [doc] The platform fails product-add at quote time with a named error: "Ensure that the discovery procedure and pricing procedure are associated with same context definition" (KB 002188066). A configuration join detects before a seller does.

How to fix it. Re-associate the discovery procedure with the pricing procedure's context definition (deactivate, update, reactivate per the KB).

Source. Salesforce KB 002188066

RC-019 on its own page

What it requires. An active decision table's source object holds zero rows.

Why it matters. [doc via snapshot semantics + payload schema] A table compiled from nothing returns no match for every lookup, so every dependent element takes its no-result branch (the step schema's noResultExplainerTemplate is exactly that path) and adjustments silently never apply. Where the empty table is unadopted Salesforce-standard machinery, report as Coverage & Adoption instead - the standard-vs-custom cut decides defect versus signal.

How to fix it. Populate and refresh the source, or retire the table and the elements that read it.

Source. Salesforce Help: Refresh a Decision Table (snapshot semantics)

RC-020 on its own page

What it requires. A constraint model has not been synced since its products' definitions changed in Product Catalog Management.

Why it matters. [doc] Salesforce ships a sync mechanism because CML encodes product structure at authoring time: "Sync product definition changes from Product Catalog Management (PCM) to the constraint modeling language (CML)... to make sure that the CML reflects the latest product definition." The failure consequence - the configurator enforcing yesterday's product, valid configurations rejected and invalid accepted - is inferred from that mechanism and is stated as inference: Salesforce documents the sync, not the failure. The stale-tables mechanism at the configurator layer. Child-page pin outstanding; parent page cited.

How to fix it. Run the constraint model sync after product definition changes, and put the sync into the change process.

Source. Salesforce Help: Rules and Constraints in Configurator (sync section)

RC-021 on its own page