Home / admin / stakeholder-raci-for-sf-projects

stakeholder-raci-for-sf-projects

Use this skill when building, reviewing, or refreshing a RACI (Responsible / Accountable / Consulted / Informed) matrix for a Salesforce project so that every Salesforce-specific decision — data model change, automation tier choice, security model, integration boundary, deployment, license/edition — has exactly one accountable owner and a documented escalation path that downstream agents can route to.

• v1.1.0
• Salesforce Spring '25+
• Updated 2026-09-04
• Operational Excellence
• Security
• Reliability

• raci
• stakeholder-management
• governance
• escalation
• decision-rights
• business-analysis

Open the skill folder on GitHub

Stakeholder RACI for Salesforce Projects

This skill activates when a Business Analyst, project manager, or admin lead needs a deterministic method for assigning decision authority on a Salesforce project — and a routing table that the repository's runtime agents can use when they emit REFUSAL_NEEDS_HUMAN_REVIEW. The output is a RACI matrix tailored to the Salesforce decision surface (data model, automation tier, security, integration, deployment, licensing) with explicit escalation rules per accountable cell.

Before Starting

Gather this context before drafting the matrix:

• Phase and version-lock cadence. A RACI for discovery is not the RACI for build, and neither is the RACI for hypercare. The matrix must be version-locked per phase or it becomes stale within weeks. Confirm the phase you are modelling and the next planned re-review date.
• Named individuals vs. roles. Salesforce projects fail when "the architect" or "the admin" is a placeholder — a single physical person must carry the A. Confirm whether the project is staffed enough that every stakeholder role on the canonical list maps to a named person; if not, surface the gap rather than papering over it.
• Customer vs. partner ownership boundary. On consulting-led implementations, the most damaging RACI mistake is leaving A-cells with the systems integrator after go-live. Establish up front which A-cells transfer to the customer at hypercare and document the transfer date.
• Regulatory overlay. HIPAA, FINRA, PCI, GDPR, SOX each impose a non-negotiable A on a compliance officer for specific decisions (PHI access, trade record retention, cardholder data, data subject rights, financial reporting controls). The compliance officer's A is not negotiable, even if a sponsor wants to push it elsewhere.
• Existing CAB. If the org has a change advisory board, the CAB is typically C (consulted) on deployment decisions and may hold A on production deploys for high-blast-radius changes. Capture its cadence and quorum rules — RACI escalations that miss CAB cadence stall.

Questions to Ask Before Configuring

Ask these before drafting a single cell. Each one exists because a specific failure recurs — the matching gotcha is named in the last column so you can see what the answer is protecting you from.

What a proper matrix adds over just naming an owner per workstream: every irreversible Salesforce action — refresh, load, hotfix, release-update activation — has exactly one named person who can authorise it, a clock that fires when they do not, and a decision log an auditor can read a year later.

Core Concepts

The Salesforce Decision Surface

A generic project RACI lists deliverables. A Salesforce RACI lists decisions — because a Salesforce build is a stack of irreversible-or-expensive-to-reverse decisions, not a stack of artifacts. The canonical decision categories every Salesforce RACI must cover:

1. Data model change — adding/changing/deleting standard or custom objects, fields, relationships, record types, or external IDs. A decision here ripples through reports, integrations, and security.
2. Automation tier — picking Flow vs. Apex vs. Agentforce vs. Approvals vs. Platform Events for a given requirement (see standards/decision-trees/automation-selection.md).
3. Security model — OWD, role hierarchy, sharing rules, profiles, permission sets, permission set groups, restriction rules, and field-level security (see standards/decision-trees/sharing-selection.md).
4. Integration boundary — REST vs. Bulk vs. Platform Events vs. CDC vs. Pub/Sub vs. Salesforce Connect vs. MuleSoft (see standards/decision-trees/integration-pattern-selection.md), plus the contract with the source/target system.
5. Deployment — what gets promoted, when, with what backout plan, and through which sandboxes (see admin/sandbox-strategy).
6. License + edition — which user license, which add-on (Service Cloud, Sales Cloud, Agentforce, CPQ, OmniStudio, Experience Cloud), edition tier, and feature license assignment.

Every row in the matrix is one of these categories — or a sub-row scoped to a specific object, integration, or release. Resist adding deliverable rows ("build the Account page layout") — those belong in a work-breakdown structure, not a RACI.

The Ten Required Activity Rows

The six categories above are how you think about the surface. The rows you actually write are the ten activities below — the ones that are irreversible, expensive to reverse, or driven by a date Salesforce sets rather than one you set. scripts/check_raci.py requires every slug to appear at least once; a missing slug is an error, because a required decision with no row is a decision with no owner.

Sub-rows share a slug: a regulated programme writes two data-model-change rows (regulated data and everything else) with different As. The automation-tier and license/edition categories stay as optional extra rows — they are decisions, but they are reversible, so they do not carry the same "nobody owns this and the platform is about to act" risk the ten do. A filled version of all ten, with escalation rules and the executing agent per row, is in references/worked-examples.md.

The Canonical Salesforce Stakeholder Roster

The matrix columns come from a fixed roster:

Keep architects split across Security architect and Integration architect — collapsing them into a single "Architecture" role is one of the most common RACI mistakes on Salesforce projects.

R / A / C / I — and the One-A Rule

Additional rules specific to Salesforce projects:

• No A on a Consulted role. If someone is C, they cannot also be A — that contradicts the one-A rule.
• Every row must have at least one R. A row with only A/C/I means the work is unowned.
• An advisory body (CAB, steerco, design authority) is C, never A. They review; the named accountable person decides.
• The data steward is C at minimum on every data model row, even when a process owner holds A.

Escalation Rules: The "When Does This Go Up?" Question

A RACI without escalation rules is a wall poster. For every A-cell, document:

• Trigger — what condition forces escalation (e.g., A and C disagree, time-box exceeded, blast radius exceeds threshold).
• Target — who the next-level decision-maker is (typically the sponsor or steerco).
• Time-box — how long the A has to decide before escalation auto-fires (e.g., "data model change pending >5 business days escalates to sponsor").

Escalation rules without a time-box silently rot — the project blocks but no alarm trips.

Mapping RACI to Agent Refusal Codes

The repository's runtime agents emit refusal codes from agents/_shared/REFUSAL_CODES.md when they hit a condition that explicitly requires human judgment. The RACI is the routing table that converts a refusal code into a named person.

Canonical mapping:

Every BA / admin runtime agent's escalation step should look up the refusal code, find the row, and ping the A — with the C on the same row in the loop.

Common Patterns

Pattern: Greenfield Sales Cloud RACI

When to use: First Salesforce implementation, single-org, no managed packages, single-region.

How it works: Sponsor (CRO) holds A on scope and license. Process owner (VP Sales Ops) holds A on data model and automation tier. Security architect holds A on security. Integration architect holds A on the one or two inbound feeds. CRM admin lead holds A on day-to-day config. Compliance officer is C on data model and security; not on the critical path.

Why not the alternative: Rolling A on the data model into the sponsor in a greenfield is tempting but wrong — sponsors do not have time to decide on every field, and the data steward / process owner is closer to the data semantics.

Pattern: Regulated Industry RACI (HIPAA / FINRA / PCI)

When to use: Health Cloud, Financial Services Cloud, payment-card-handling, or any project where audit findings could be material.

How it works: Compliance officer holds A on retention, audit trail, and any decision touching regulated data. Security architect holds A on FLS and sharing for regulated objects. Data steward is C on every row touching regulated data and may hold A on data classification. Sponsor's A on scope must include explicit acceptance that the compliance officer can veto a feature.

Why not the alternative: Treating compliance as C on regulated data lets the project ship with a control gap — and the audit catches it six months later. Compliance gets A on the controls; the process owner still owns the business outcome.

Pattern: M&A Multi-Org RACI

When to use: Two or more existing Salesforce orgs being merged or federated post-acquisition.

How it works: Two business sponsors (one per legacy org) reporting to a combined steerco; the steerco holds A on org-strategy decisions (merge vs. federate vs. coexist). Each org keeps its own CRM admin lead and process owner with split A on day-to-day decisions. Integration architect holds A on the cross-org integration pattern. A new "data steward (master)" role emerges to hold A on the master data model post-merger.

Why not the alternative: Naming a single sponsor too early in an M&A causes one side's stakeholders to disengage. The split-A pattern is uncomfortable but mirrors the actual organizational state until the merger is complete.

Decision Guidance

Recommended Workflow

1. Fill the intake sheet and build the register. Copy

   templates/stakeholder-raci-for-sf-projects-template.md; record phase, org topology, regulatory overlay, managed packages, delegate groups already in the org, and the partner's hypercare exit date, working the ## Questions to Ask Before Configuring table into it. Then name a person for every roster role with org unit, Salesforce persona, user licence, and decision rights — the six columns in references/worked-examples.md §1. An unnamed role is a project risk to escalate, not a placeholder to fill later.

2. Write the ten activity rows. Copy templates/raci-matrix.md, keep the ten required slugs, and

   add sub-rows only where a category needs splitting. Apply the one-A rule, the no-A-on-a-C rule, and the every-row-has-an-R rule as you fill cells.

3. Attach an escalation rule to every A, and an escalation path to the programme. Trigger, target,

   time-box per row; level, forum, chair, time-box per escalation level. references/gotchas.md §4 is why the time-box is not optional.

4. Map each R to its executor. Fill executed_by with the repo path of the agent, skill, or

   decision tree that carries out the row — see the table in ## Core Concepts and references/worked-examples.md §5.

5. Lint the artefact. Run

   python3 scripts/check_raci.py --file <path>/raci.yaml --repo-root <repo> --strict. Errors are structural (missing A, missing R, missing required activity, missing escalation, unresolved executed_by); fix them before circulating. Warnings are judgement calls — read them, then decide.

6. Reconcile the matrix against the org. Retrieve the delegate groups and diff them against the

   permission row (references/worked-examples.md §6). A difference is a decision made outside the governance path.

7. Review, version-lock, log. Capture the sponsor sign-off date, the next review date, and the

   phase in the artefact header. Record decisions as they are made in the decision_log shape — the next phase gets a new version, not an in-place edit.

Review Checklist

Run through these before publishing the matrix:

• [ ] All ten required activity slugs have a row (check_raci.py errors on a missing one)
• [ ] Every row has exactly one A
• [ ] No row has A on a C role
• [ ] Every row has at least one R
• [ ] Every R/A/C/I value is from the enum (R, A, C, I) — no blanks, no commentary
• [ ] Every A cell has a written escalation rule with trigger + target + time-box
• [ ] The escalation target on each row is someone other than that row's A
• [ ] A programme-level escalation_path exists with level, forum, chair, and time-box per level
• [ ] Every executed_by path resolves to a real agent, skill, or decision tree in the repo
• [ ] Delegate groups in the org have been retrieved and diffed against the permission row
• [ ] Every refusal code in agents/_shared/REFUSAL_CODES.md that requires human review resolves to a named A
• [ ] No A is held by the implementation partner past the planned hypercare exit date
• [ ] Compliance officer holds A (not just C) on regulatory-control rows for HIPAA/FINRA/PCI/GDPR/SOX projects
• [ ] Data steward is at minimum C on every data-model row
• [ ] Architecture is split into security and integration columns — not collapsed
• [ ] Phase and version are stamped on the matrix
• [ ] Sponsor + steerco review date is captured, next review date is scheduled

Salesforce-Specific Gotchas

Non-obvious project-governance behaviors that cause real production problems:

1. A migrated to the consulting partner and never transferred back. During implementation the SI's lead architect carries A on integration and security because they own the design. If A does not transfer to a named customer employee before hypercare ends, the customer has no decision-maker post-go-live and every change request blocks until a partner is re-engaged.
2. Compliance officer demoted to C on regulated data. Project teams find compliance's review cycle slow and quietly leave them as C. The system ships, audit fires, and the gap forces a remediation project that costs more than the original build.
3. Single-sponsor RACI on an M&A. Naming one sponsor too early disenfranchises the other org's stakeholders. They disengage from steerco, requirements drift, and the merger fails to consolidate. Use a steerco-as-A pattern until the legal merger closes.
4. AppExchange owner missing from the matrix. Decisions touching a managed-package namespace (Conga, DocuSign, CPQ, FSL, NPSP) require the package owner's input — they know what the next package release will break. Omitting them produces decisions that get reversed by the next package upgrade.
5. Escalation paths without time-boxes. "Escalate to sponsor if blocked" with no clock means the team waits indefinitely for the A to decide. A 3–5 business-day time-box should be the default, with shorter for security and longer for license-tier decisions.

Seven more — the sandbox refresh approved by someone who does not own the data in it, "the Salesforce admin" as A for everything, integrations whose owners are outside the matrix, release-update activation owned by nobody, the data load signed off by the tool operator instead of the record owner, delegate groups that contradict the permission row, and one role meaning two different people in a multi-org programme — are in references/gotchas.md §9–§15, each with the platform behaviour that makes it bite.

Output Artifacts

Reference Files

Related Skills

• admin/requirements-gathering-for-sf — use first, to identify the stakeholders before assigning their authority
• admin/change-management-and-deployment — covers the CAB operating model that the RACI references
• admin/change-management-and-training — covers end-user adoption, which is downstream of the RACI
• admin/permission-set-architecture — covers the technical authority model for permission set assignment
• admin/delegated-administration — the permission row made concrete: the delegate group that either matches this matrix or contradicts it
• devops/release-management — the release train the go/no-go, hotfix, release-update, and preview rows sit inside
• admin/sandbox-strategy — feeds the deployment-row decisions on which sandboxes a change traverses
• standards/decision-trees/automation-selection.md — the tree the automation-tier A cell consults
• standards/decision-trees/sharing-selection.md — the tree the security-model A cell consults
• standards/decision-trees/integration-pattern-selection.md — the tree the integration-boundary A cell consults
• agents/_shared/REFUSAL_CODES.md — the refusal-code enum the matrix maps to
• agents/_shared/AGENT_CONTRACT.md — why an agent's Citations block and confidence score are usable as decision-log evidence
• agents/org-health-assessor-v2/AGENT.md — reports the pending release updates and org-level findings the matrix must assign owners to
• agents/release-readiness-reviewer/AGENT.md — produces the evidence the go/no-go A signs

Package files

• references/examples.md
• references/gotchas.md
• references/llm-anti-patterns.md
• references/well-architected.md
• references/worked-examples.md
• templates/raci-matrix.md
• templates/stakeholder-raci-for-sf-projects-template.md
• scripts/check_raci.py