Structure and evaluate a consequential Salesforce choice before the team commits: frame the decision, separate hard constraints from preferences, compare viable options with evidence, test score sensitivity, and recommend a reversible next step. Trigger keywords: compare Salesforce options, evaluate alternatives, make a platform decision, decision matrix, weighted decision. NOT for documenting an already accepted choice — use architect/architecture-decision-records. NOT for a narrow technology branch already covered by a canonical decision tree — apply that tree first.
Use this skill before committing to a non-trivial Salesforce product, architecture, automation, integration, security, data, or delivery choice. Its job is to make the decision auditable and testable, not to manufacture certainty or replace the specialist skill that supplies domain evidence.
Decision Packet Contract
A complete packet contains each element below. Keep raw research outside the packet and link to stable evidence IDs or URLs.
Element
Required content
Failure prevented
Decision frame
One question, one measurable outcome, in-scope and out-of-scope boundaries
Solving adjacent problems instead of the stated one
Target context
Org/project/workload/release identity, or an explicit not required
Treating release- or org-dependent behavior as universal
Constraints
Hard gates separated from preferences
Allowing a high weighted score to hide an infeasible option
Evidence ledger
Facts, recommendations, assumptions, unknowns, source tier, observed date
Laundering opinions into facts
Viable options
At least two options a competent team could choose; include standard/reuse/no-change when credible
Comparing a favorite to strawmen
Criteria model
Criterion definition, measurement, direction, weight, and rationale
Arbitrary weights and double-counting
Comparison
Hard-gate result, score, evidence, uncertainty, and tradeoff for every option/criterion
Unsupported scoring
Sensitivity
Weight or score changes that would alter the winner
False precision from one weighting scheme
Risk and reversibility
Failure modes, blast radius, lock-in, exit cost, rollback or experiment
Ignoring asymmetric downside
Recommendation
Preferred option, confidence, conditions, validation step, and decision owner
A recommendation with no action or accountability
Evidence States
Classify every material statement before scoring it.
State
Meaning
How it may influence the decision
fact
Directly supported by identified org/project evidence or a source appropriate to the claim
May support a hard gate or a score
recommendation
A documented pattern or expert judgment, not a platform guarantee
May shape criteria; never becomes a hard gate without policy ownership
assumption
Plausible but not yet verified
Score with uncertainty and add a validation action
unknown
Evidence is absent, contradictory, stale, or inaccessible
Do not assign a favorable score; expose the decision risk
For release-sensitive claims, record the Salesforce release or API version and the date observed. For org-specific claims, record the exact org or snapshot identity. Never use a source URL as proof that the target org has a licensed or enabled capability.
Hard Gates Before Weighted Scoring
A weighted matrix answers which feasible option best fits the preferences. It cannot make an infeasible option viable.
Evaluate gates first:
Platform feasibility — supported metadata/API/runtime behavior for the stated release.
License and entitlement — confirmed availability for the target edition, add-ons, user licenses, and contractual constraints.
Security and compliance — data classification, least privilege, residency, audit, encryption, and segregation requirements.
Authority and environment — whether the requested operation is permitted for this run and target.
Use PASS, FAIL, or UNKNOWN. A FAIL eliminates the option. An UNKNOWN keeps it provisional and caps confidence until validated.
Constructing Real Options
Options must differ in a load-bearing choice, not just naming. Consider these families where relevant:
Family
Candidate option
Standard
Native Salesforce capability with configuration only
Reuse
Extend an existing component, package, automation, service, or data product
Configure
Add declarative metadata while preserving the current architecture
Build
Add custom Apex, LWC, integration, or external service behavior
Buy
Adopt a managed package or licensed Salesforce product
Sequence
Run a bounded pilot, defer, or stage the capability behind an experiment
No change
Retain the current state and accept the documented cost/risk
Do not force all families into every decision. Include only options that survive an initial plausibility check, and explain why other obvious families were excluded.
Criteria and Weighting
Start from the business outcome and hard constraints. Then map criteria to Salesforce Well-Architected concerns without counting the same effect twice.
Criterion
Evidence question
Typical measurement
Outcome fit
Does the option satisfy the acceptance criteria?
Coverage of required scenarios
Trust
What access, data exposure, compliance, and failure risk does it create?
Control gaps and residual risk
Reliability
How does it fail, recover, retry, and avoid duplicate work?
Failure modes, RTO/RPO, idempotency
Scale and performance
Does it fit data volume, concurrency, limits, and latency?
Headroom and measured/estimated load
User and operator effort
How difficult is it to use, support, diagnose, and change?
Steps, roles, observability, runbooks
Delivery
Can it be built, tested, deployed, and rolled back safely?
Dependencies, lead time, test surface
Cost and lock-in
What recurring, implementation, migration, and exit costs exist?
Total cost range and switching cost
Weight rules:
Make weights sum to 100 and record who approved them.
Explain each weight in relation to the outcome; do not default to equal weights silently.
Keep mutually dependent criteria separate only when each has a distinct measurement.
Use a consistent score scale, normally 1–5, with anchors defined before options are scored.
Attach evidence and uncertainty to every score. A bare number is not a finding.
Avoid decimal precision that exceeds the evidence quality.
A practical 1–5 anchor:
Score
Meaning
1
Fails most of the criterion or creates an unacceptable tradeoff
2
Partially fits; substantial remediation or risk remains
3
Meets the minimum with material tradeoffs
4
Strong fit with manageable tradeoffs
5
Best-supported fit; do not use when evidence is incomplete
Sensitivity and Uncertainty
Run at least two challenges:
Weight sensitivity — increase the two most debatable weights and reduce the current winner's strongest criterion. Record whether the ranking changes.
Evidence sensitivity — replace each load-bearing assumption with a conservative value. Record whether the recommendation changes or becomes conditional.
Also state the smallest plausible change that would reverse the recommendation. When several options remain close, recommend a time-boxed experiment instead of declaring a false winner.
Risk and Reversibility
For every viable option, record:
failure mode and user/business impact;
blast radius and affected systems/personas;
detectability and time to detect;
rollback, compensating action, or exit path;
irreversible decisions, data migrations, contract terms, and namespace/package lock-in;
evidence needed before execution.
Prefer the smallest reversible step when evidence is weak and the cost of being wrong is high. Reversibility is not automatically superior: a temporary workaround that creates hidden operational debt may score worse than a deliberate durable change.
Recommended Workflow
Frame and route one decision question and measurable outcome. Separate constraints, preferences, non-goals, deadline, and owner; then apply the narrowest canonical decision tree or specialist skill and record its branch or gap.
Gather evidence and options using standards/source-hierarchy.md, target-org/project evidence when applicable, and a claim ledger. Generate genuinely viable options independently before ranking, including standard, reuse, and no-change options when credible.
Apply hard gates and remove failed options. Keep UNKNOWN gates visible and cap confidence until their validation action completes.
Define and score criteria with pre-declared anchors, owner-approved weights, evidence, and uncertainty. Never let a weighted score override feasibility.
Challenge the result with weight/evidence sensitivity, risk asymmetry, reversibility, and a pre-mortem. Prefer a bounded experiment when the winner is unstable.
Recommend and hand off an option, experiment, defer, or no-change posture with confidence, unresolved unknowns, validation actions, and reversal conditions. After human acceptance, hand the result to architect/architecture-decision-records; do not treat the mutable analysis packet as the frozen ADR.
Decision Statuses
Status
Use it when
recommend
Evidence supports one option and no load-bearing gate is unknown
conditional-recommend
One option leads, but named assumptions or gates must be verified
experiment
Options remain close or a reversible test can resolve the main uncertainty
defer
The decision deadline or dependency makes a responsible choice premature
no-change
The current state is deliberately retained after comparing its costs and risks
refuse
The requested decision would violate policy, authority, law, or a non-negotiable control
Review Checklist
One decision question and one measurable outcome are stated
Target org/project/release context is pinned or explicitly not required
Constraints are separated from weighted preferences
At least two genuinely viable options are compared
Standard, reuse, experiment, and no-change options were considered where credible
Every hard gate is PASS, FAIL, or UNKNOWN
Criteria have definitions, anchors, weights, rationales, and no obvious double-counting
Every score links to evidence and carries an uncertainty note
Weight and evidence sensitivity were tested
Risks, blast radius, reversibility, and exit costs are explicit
Recommendation names conditions that would change it
Accepted outcome is handed to an ADR rather than silently treated as final
Output Artifacts
Artifact
Purpose
decision-analysis.md
Human-readable decision packet using the bundled template
decision-analysis.json
Optional structured representation for automation and MCP consumers
evidence-ledger
Stable claim-to-source mapping with freshness and uncertainty
validation-actions
Ordered checks that resolve remaining assumptions before commitment
adr-handoff
Concise accepted decision, premises, alternatives, consequences, and review trigger
architect/solution-design-patterns — supply the domain design patterns and platform tradeoffs used as evidence.
architect/architecture-decision-records — freeze the accepted choice and premises after human approval.
architect/well-architected-review — evaluate an implementation or workload, not a single pre-commitment choice.
standards/decision-trees/ — apply narrow canonical routing before inventing a generic matrix.
Specialist decision skills — use the product-specific decision skill when the repository already owns the exact branch.
See references/examples.md, references/gotchas.md, references/llm-anti-patterns.md, and references/well-architected.md for worked packets and review guidance.
1---2name: salesforce-decision-analysis3description: Structure and evaluate a consequential Salesforce choice before the team commits: frame the decision, separate hard constraints from preferences, compare viable options with evidence, test score sensitivity, and recommend a reversible next step. Trigger keywords: compare Salesforce options, evaluate alternatives, make a platform decision, decision matrix, weighted decision. NOT for documenting an already accepted choice — use architect/architecture-decision-records. NOT for a narrow technology branch already covered by a canonical decision tree — apply that tree first.4---56# Salesforce Decision Analysis78Use this skill before committing to a non-trivial Salesforce product, architecture, automation, integration, security, data, or delivery choice. Its job is to make the decision **auditable and testable**, not to manufacture certainty or replace the specialist skill that supplies domain evidence.910---1112## Decision Packet Contract1314A complete packet contains each element below. Keep raw research outside the packet and link to stable evidence IDs or URLs.1516| Element | Required content | Failure prevented |17|---|---|---|18| Decision frame | One question, one measurable outcome, in-scope and out-of-scope boundaries | Solving adjacent problems instead of the stated one |19| Target context | Org/project/workload/release identity, or an explicit `not required` | Treating release- or org-dependent behavior as universal |20| Constraints | Hard gates separated from preferences | Allowing a high weighted score to hide an infeasible option |21| Evidence ledger | Facts, recommendations, assumptions, unknowns, source tier, observed date | Laundering opinions into facts |22| Viable options | At least two options a competent team could choose; include standard/reuse/no-change when credible | Comparing a favorite to strawmen |23| Criteria model | Criterion definition, measurement, direction, weight, and rationale | Arbitrary weights and double-counting |24| Comparison | Hard-gate result, score, evidence, uncertainty, and tradeoff for every option/criterion | Unsupported scoring |25| Sensitivity | Weight or score changes that would alter the winner | False precision from one weighting scheme |26| Risk and reversibility | Failure modes, blast radius, lock-in, exit cost, rollback or experiment | Ignoring asymmetric downside |27| Recommendation | Preferred option, confidence, conditions, validation step, and decision owner | A recommendation with no action or accountability |2829---3031## Evidence States3233Classify every material statement before scoring it.3435| State | Meaning | How it may influence the decision |36|---|---|---|37| `fact` | Directly supported by identified org/project evidence or a source appropriate to the claim | May support a hard gate or a score |38| `recommendation` | A documented pattern or expert judgment, not a platform guarantee | May shape criteria; never becomes a hard gate without policy ownership |39| `assumption` | Plausible but not yet verified | Score with uncertainty and add a validation action |40| `unknown` | Evidence is absent, contradictory, stale, or inaccessible | Do not assign a favorable score; expose the decision risk |4142For release-sensitive claims, record the Salesforce release or API version and the date observed. For org-specific claims, record the exact org or snapshot identity. Never use a source URL as proof that the target org has a licensed or enabled capability.4344---4546## Hard Gates Before Weighted Scoring4748A weighted matrix answers **which feasible option best fits the preferences**. It cannot make an infeasible option viable.4950Evaluate gates first:51521. **Platform feasibility** — supported metadata/API/runtime behavior for the stated release.532. **License and entitlement** — confirmed availability for the target edition, add-ons, user licenses, and contractual constraints.543. **Security and compliance** — data classification, least privilege, residency, audit, encryption, and segregation requirements.554. **Authority and environment** — whether the requested operation is permitted for this run and target.565. **Non-functional minimums** — required throughput, latency, availability, recovery, scale, and supportability.576. **Delivery boundary** — package ownership, deployment path, testability, and rollback feasibility.5859Use `PASS`, `FAIL`, or `UNKNOWN`. A `FAIL` eliminates the option. An `UNKNOWN` keeps it provisional and caps confidence until validated.6061---6263## Constructing Real Options6465Options must differ in a load-bearing choice, not just naming. Consider these families where relevant:6667| Family | Candidate option |68|---|---|69| Standard | Native Salesforce capability with configuration only |70| Reuse | Extend an existing component, package, automation, service, or data product |71| Configure | Add declarative metadata while preserving the current architecture |72| Build | Add custom Apex, LWC, integration, or external service behavior |73| Buy | Adopt a managed package or licensed Salesforce product |74| Sequence | Run a bounded pilot, defer, or stage the capability behind an experiment |75| No change | Retain the current state and accept the documented cost/risk |7677Do not force all families into every decision. Include only options that survive an initial plausibility check, and explain why other obvious families were excluded.7879---8081## Criteria and Weighting8283Start from the business outcome and hard constraints. Then map criteria to Salesforce Well-Architected concerns without counting the same effect twice.8485| Criterion | Evidence question | Typical measurement |86|---|---|---|87| Outcome fit | Does the option satisfy the acceptance criteria? | Coverage of required scenarios |88| Trust | What access, data exposure, compliance, and failure risk does it create? | Control gaps and residual risk |89| Reliability | How does it fail, recover, retry, and avoid duplicate work? | Failure modes, RTO/RPO, idempotency |90| Scale and performance | Does it fit data volume, concurrency, limits, and latency? | Headroom and measured/estimated load |91| User and operator effort | How difficult is it to use, support, diagnose, and change? | Steps, roles, observability, runbooks |92| Delivery | Can it be built, tested, deployed, and rolled back safely? | Dependencies, lead time, test surface |93| Cost and lock-in | What recurring, implementation, migration, and exit costs exist? | Total cost range and switching cost |9495Weight rules:9697- Make weights sum to 100 and record who approved them.98- Explain each weight in relation to the outcome; do not default to equal weights silently.99- Keep mutually dependent criteria separate only when each has a distinct measurement.100- Use a consistent score scale, normally 1–5, with anchors defined before options are scored.101- Attach evidence and uncertainty to every score. A bare number is not a finding.102- Avoid decimal precision that exceeds the evidence quality.103104A practical 1–5 anchor:105106| Score | Meaning |107|---:|---|108| 1 | Fails most of the criterion or creates an unacceptable tradeoff |109| 2 | Partially fits; substantial remediation or risk remains |110| 3 | Meets the minimum with material tradeoffs |111| 4 | Strong fit with manageable tradeoffs |112| 5 | Best-supported fit; do not use when evidence is incomplete |113114---115116## Sensitivity and Uncertainty117118Run at least two challenges:1191201. **Weight sensitivity** — increase the two most debatable weights and reduce the current winner's strongest criterion. Record whether the ranking changes.1212. **Evidence sensitivity** — replace each load-bearing assumption with a conservative value. Record whether the recommendation changes or becomes conditional.122123Also state the smallest plausible change that would reverse the recommendation. When several options remain close, recommend a time-boxed experiment instead of declaring a false winner.124125---126127## Risk and Reversibility128129For every viable option, record:130131- failure mode and user/business impact;132- blast radius and affected systems/personas;133- detectability and time to detect;134- rollback, compensating action, or exit path;135- irreversible decisions, data migrations, contract terms, and namespace/package lock-in;136- evidence needed before execution.137138Prefer the smallest reversible step when evidence is weak and the cost of being wrong is high. Reversibility is not automatically superior: a temporary workaround that creates hidden operational debt may score worse than a deliberate durable change.139140---141142## Recommended Workflow1431441. **Frame and route** one decision question and measurable outcome. Separate constraints, preferences, non-goals, deadline, and owner; then apply the narrowest canonical decision tree or specialist skill and record its branch or gap.1452. **Gather evidence and options** using `standards/source-hierarchy.md`, target-org/project evidence when applicable, and a claim ledger. Generate genuinely viable options independently before ranking, including standard, reuse, and no-change options when credible.1463. **Apply hard gates** and remove failed options. Keep `UNKNOWN` gates visible and cap confidence until their validation action completes.1474. **Define and score criteria** with pre-declared anchors, owner-approved weights, evidence, and uncertainty. Never let a weighted score override feasibility.1485. **Challenge the result** with weight/evidence sensitivity, risk asymmetry, reversibility, and a pre-mortem. Prefer a bounded experiment when the winner is unstable.1496. **Recommend and hand off** an option, experiment, defer, or no-change posture with confidence, unresolved unknowns, validation actions, and reversal conditions. After human acceptance, hand the result to `architect/architecture-decision-records`; do not treat the mutable analysis packet as the frozen ADR.150151---152153## Decision Statuses154155| Status | Use it when |156|---|---|157| `recommend` | Evidence supports one option and no load-bearing gate is unknown |158| `conditional-recommend` | One option leads, but named assumptions or gates must be verified |159| `experiment` | Options remain close or a reversible test can resolve the main uncertainty |160| `defer` | The decision deadline or dependency makes a responsible choice premature |161| `no-change` | The current state is deliberately retained after comparing its costs and risks |162| `refuse` | The requested decision would violate policy, authority, law, or a non-negotiable control |163164---165166## Review Checklist167168- [ ] One decision question and one measurable outcome are stated169- [ ] Target org/project/release context is pinned or explicitly not required170- [ ] Constraints are separated from weighted preferences171- [ ] At least two genuinely viable options are compared172- [ ] Standard, reuse, experiment, and no-change options were considered where credible173- [ ] Every hard gate is `PASS`, `FAIL`, or `UNKNOWN`174- [ ] Criteria have definitions, anchors, weights, rationales, and no obvious double-counting175- [ ] Every score links to evidence and carries an uncertainty note176- [ ] Weight and evidence sensitivity were tested177- [ ] Risks, blast radius, reversibility, and exit costs are explicit178- [ ] Recommendation names conditions that would change it179- [ ] Accepted outcome is handed to an ADR rather than silently treated as final180181---182183## Output Artifacts184185| Artifact | Purpose |186|---|---|187| `decision-analysis.md` | Human-readable decision packet using the bundled template |188| `decision-analysis.json` | Optional structured representation for automation and MCP consumers |189| `evidence-ledger` | Stable claim-to-source mapping with freshness and uncertainty |190| `validation-actions` | Ordered checks that resolve remaining assumptions before commitment |191| `adr-handoff` | Concise accepted decision, premises, alternatives, consequences, and review trigger |192193Validate a packet with:194195```bash196python3 skills/architect/salesforce-decision-analysis/scripts/check_salesforce_decision_analysis.py --input path/to/decision-analysis.md197```198199---200201## Related Skills202203- `architect/solution-design-patterns` — supply the domain design patterns and platform tradeoffs used as evidence.204- `architect/architecture-decision-records` — freeze the accepted choice and premises after human approval.205- `architect/well-architected-review` — evaluate an implementation or workload, not a single pre-commitment choice.206- `standards/decision-trees/` — apply narrow canonical routing before inventing a generic matrix.207- Specialist decision skills — use the product-specific decision skill when the repository already owns the exact branch.208209See `references/examples.md`, `references/gotchas.md`, `references/llm-anti-patterns.md`, and `references/well-architected.md` for worked packets and review guidance.
Run npx skillmds add pranavnagrecha/salesforce-decision-analysis in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.
Structure and evaluate a consequential Salesforce choice before the team commits: frame the decision, separate hard constraints from preferences, compare viable options with evidence, test score sensitivity, and recommend a reversible next step. Trigger keywords: compare Salesforce options, evaluate alternatives, make a platform decision, decision matrix, weighted decision. NOT for documenting an already accepted choice — use architect/architecture-decision-records. NOT for a narrow technology branch already covered by a canonical decision tree — apply that tree first. It is listed under Coding & Dev Tools on SkillMD.
This skill has not completed SkillMD's automated safety review yet. Capability flags: executes scripts. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.
This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.
Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.
PranavNagrecha (@pranavnagrecha) published this skill. Their other Agent Skills are listed on their SkillMD profile.
PranavNagrecha