Fit Gap Analysis Against Org

Fit-Gap Analysis Against Org

This skill activates after requirements have been gathered and the team needs to convert that backlog into a build plan that respects the actual org's edition, licenses, installed packages, and existing automation. It produces a deterministic per-row classification, effort tier, risk tag, and downstream-agent handoff. It does NOT elicit requirements (handled by admin/requirements-gathering-for-sf) and does NOT pick the technology to use for the GAP cases (handled by architect/solution-design-patterns plus standards/decision-trees/).

The output of this skill is the routing manifest for the rest of the build pipeline: Standard and Configuration rows go to agents/object-designer/AGENT.md, Low-Code rows to agents/flow-builder/AGENT.md, Custom rows to agents/apex-builder/AGENT.md, and Unfit rows trigger an architecture-escalation review.

Before Starting

Gather this context before scoring a single row:

• Org edition and enabled features. A "Standard" row in Enterprise Edition becomes a "Configuration" or even an "Unfit" row in Professional Edition. Probe the org with Setup → Company Information → Organization Edition and Setup → Object Manager to confirm features (e.g. Forecasting, Knowledge, Service Cloud Voice) are actually licensed and enabled.
• Installed AppExchange packages. A managed package may already deliver 70% of a "Custom" row's behavior. Run Setup → Installed Packages and reconcile against the requirement before classifying as Custom.
• License SKU counts. A Standard feature with a per-user license cap (e.g. CPQ user, Service Cloud user, Industry Cloud user) becomes a GAP for any user persona that does not have that license. Check Setup → Company Information → User Licenses + Permission Set Licenses and cross-reference with the requirement's persona.
• Existing automation on the in-scope objects. A new requirement that conflicts with an existing trigger or record-triggered Flow is not free to build, regardless of classification. Inventory Setup → Process Automation → Flows and Object Manager → Triggers per in-scope sObject.
• AppExchange policy. Some customers refuse paid managed packages on principle. That single constraint can force a row from "Standard via package" to "Custom build" — and changes the effort tier dramatically.

Core Concepts

The 5-Tier Classification Rubric

Every row in the fit-gap matrix gets exactly one tier. The tiers are an ordered ladder — pick the highest (least invasive) tier that genuinely satisfies the requirement, given the org's actual configuration.

The Effort Tier Formula (S / M / L / XL)

Effort is not the same as classification. A Custom row can be Small if it is an isolated trigger; a Configuration row can be Large if it touches 30 page layouts and 12 record types. Use the formula:

effort = base(tier) + scope_multiplier + risk_multiplier

Cap at XL. Round S+0 → S, S+1 → M, S+2 → L, S+3 → XL.

The Risk-Tag Taxonomy

Every row that has any of the following is tagged. A row may carry multiple tags; the matrix lists them all.

The Canonical Handoff Row Shape

The matrix is produced as both a markdown table (for humans) and a JSON list (for downstream agents). Each JSON row is shaped:

{
  "requirement_id": "REQ-042",
  "title": "Auto-route inbound leads by region within 5 minutes",
  "tier": "Low-Code",
  "effort": "M",
  "risk_tag": ["governance"],
  "recommended_agents": ["flow-builder"],
  "recommended_skills": [
    "admin/lead-routing-rules-design",
    "flow/record-triggered-flow-patterns"
  ],
  "appexchange_alternatives": [],
  "decision_tree_branch": null,
  "notes": "Requires re-using existing assignment rule pattern; no Apex needed."
}

For Unfit rows, recommended_agents is ["architecture-escalation"] and decision_tree_branch must point to the relevant tree (e.g. standards/decision-trees/integration-pattern-selection.md#etl-vs-realtime).

Common Patterns

Pattern 1: Greenfield Sales Cloud Implementation

When to use: New Sales Cloud org, ~15–40 requirements, mix of Standard and Low-Code expected.

How it works:

1. Probe the org's edition (typically Enterprise) and confirm Salesforce Inbox, Forecasting, Pardot/Account Engagement licensing.
2. Score each requirement; expect 50–60% Standard, 25–30% Low-Code, ~10% Custom, ~5% Unfit.
3. Hand Standard rows directly to object-designer; batch Low-Code rows to flow-builder per sObject; queue Custom rows for apex-builder.

Why not the alternative: Skipping the Configuration tier and lumping everything into "Standard" or "Custom" loses the ability to estimate effort. Configuration rows are the bulk of any greenfield admin's actual workload.

Pattern 2: Service Cloud Expansion Onto an Existing Sales Cloud Org

When to use: Customer already has Sales Cloud, is adding Service Cloud.

How it works: Probe for Service Cloud user licenses, Knowledge enablement, Omni-Channel licensing. Many "Standard" Service Cloud features become license-blocker GAPs because the customer only bought Sales licenses.

Why not the alternative: Treating "Service Cloud features" as Standard without probing licenses is the single most common failure mode in fit-gap.

Pattern 3: Vertical Cloud (FSC, Health Cloud, Industries) Project

When to use: Customer has Industries Cloud or vertical edition.

How it works: Vertical clouds ship managed packages that re-classify otherwise-Custom requirements into Standard. Always reconcile against the installed Industry packages first; many Custom rows collapse to Standard or Configuration.

Decision Guidance

Recommended Workflow

Step-by-step instructions for an AI agent or practitioner activating this skill:

1. Intake the requirements list. Confirm every row has a stable requirement_id, a title, a description, and a source persona. Reject incomplete rows back to admin/requirements-gathering-for-sf rather than guessing.
2. Probe the target org. Capture edition, enabled features, installed managed packages, license SKU counts per persona, and existing automation on the in-scope sObjects. Without this probe step the matrix is a guess, not a fit-gap.
3. Classify each row into one of the five tiers (Standard / Configuration / Low-Code / Custom / Unfit), using the rubric above. Pick the highest tier that genuinely satisfies the requirement given the org's actual state.
4. Attach an effort tier (S / M / L / XL) using the formula base(tier) + scope_multiplier + risk_multiplier. Cap at XL.
5. Attach risk tag(s) from the taxonomy: license-blocker, data-skew, governance, customization-debt, no-AppExchange-equivalent. Multiple tags are allowed.
6. Hand off rows to downstream agents. Standard + Configuration → object-designer; Low-Code → flow-builder; Custom → apex-builder. Populate recommended_skills per row using the skill IDs from agents/_shared/SKILL_MAP.md.
7. Flag every Unfit row for architecture review. Each Unfit row must cite the decision tree branch in standards/decision-trees/ that the conflict belongs in, and must NOT proceed to a builder agent until that escalation closes.

Review Checklist

Run through these before publishing a fit-gap matrix:

• Every row has exactly one tier from the 5-enum.
• Every row has an effort tier (S/M/L/XL).
• Every row has at least an empty risk_tag array; tags are drawn from the canonical taxonomy.
• Every Standard row is reconciled against the org's actual edition + license counts, not a generic Salesforce-Help description.
• Every Configuration row names the specific Setup areas that will be touched.
• Every Low-Code row has not silently absorbed something that needs Apex (callout, multi-object cascade, > 200-record bulk path).
• Every Custom row has recommended_agents populated.
• Every Unfit row has an architecture-escalation note and a decision_tree_branch reference.
• AppExchange alternatives have been searched for any row with tier ∈ {Custom, Unfit} unless the customer policy explicitly excludes managed packages.

Salesforce-Specific Gotchas

Non-obvious platform behaviors that cause real fit-gap mistakes:

1. Process Builder is not still "Standard". Process Builder is end-of-life. Any row classified as "still standard automation via PB" is wrong; route to Low-Code (Flow) or escalate.
2. License caps invalidate Standard rows. Out-of-the-box Knowledge access for a Service Cloud agent is Standard only if the agent has a Knowledge-enabled license. Otherwise it is license-blocker Unfit.
3. Sandbox vs production feature deltas. A feature enabled in a partial-copy sandbox is not necessarily live in production. Always probe the target org, not the sandbox the team has been demoing in.
4. Permission cliffs turn Standard into Configuration. A "Standard" feature that requires Setup Customize Application access for end users effectively becomes Configuration + a permission-set authoring task.
5. AppExchange alternatives go stale. A package listed on AppExchange may be unmaintained. Confirm last-update date and supported edition before counting it as Standard.

Output Artifacts

Related Skills

• admin/requirements-gathering-for-sf — produces the input this skill consumes.
• architect/solution-design-patterns — owns the technology choice for any GAP row this skill flags.
• architect/license-optimization-strategy and architect/org-edition-and-feature-licensing — owns license + edition decisions when a row carries license-blocker.
• architect/omnistudio-vs-standard-decision — owns OmniStudio fit-gap when the project is OmniStudio-led.
• standards/decision-trees/ — every Unfit row must cite a tree branch.