Purpose
The Safe Automation Scoring (SAS) model measures how safe a Salesforce environment is for additional automation expansion.
It is designed for three decisions:
- whether the current org can absorb new automation safely
- where the environment is structurally fragile even before AI is introduced
- how to prioritize remediation before adding more workflow logic, AI agents, or integration-driven actions
SAS is intentionally narrower than the full Operational Intelligence Score (OIS). OIS measures broad operational clarity and control. SAS focuses specifically on whether the automation surface is stable enough to expand.
Scoring Method
- There are
20criteria. - Each criterion is worth up to
5points. - Score
5when the criterion is fully true. - Score
3when partially true or inconsistently true. - Score
0when false, absent, or not evidenced.
Raw SAS = sum(all criterion scores)
Maximum score: 100
The 20 Criteria
| # | Criterion | Evidence | Points |
|---|---|---|---|
| 1 | Active automations are fully inventoried by object and event. | Central register covering Flow, Apex, Process Builder, Workflow Rules, and scheduled jobs. | 0/3/5 |
| 2 | Revenue-critical objects have documented order-of-execution rationale. | Collision map, sequence notes, and owner sign-off. | 0/3/5 |
| 3 | Legacy automation has a retirement or containment plan. | Tagged retain, retire, replace decisions. | 0/3/5 |
| 4 | Every critical automation has a named technical and business owner. | Owner matrix and review cadence. | 0/3/5 |
| 5 | Fault paths and failure handling are documented for critical automations. | Error routing, retries, manual fallback, alerting. | 0/3/5 |
| 6 | Critical fields used by automation have business definitions. | Field dictionary with owner and downstream use. | 0/3/5 |
| 7 | Critical automation inputs meet population and quality thresholds. | Population analysis, validation coverage, exception handling. | 0/3/5 |
| 8 | Duplicate semantic fields affecting automation are eliminated or controlled. | Merge plan, system-of-record mapping, decision log. | 0/3/5 |
| 9 | Integration write-backs into automated objects are mapped. | Source, target, frequency, payload, and owner. | 0/3/5 |
| 10 | External systems changing automated records have alerting and failure ownership. | Monitoring records, incident routing, runbooks. | 0/3/5 |
| 11 | Permission boundaries for automation principals and service accounts are documented. | Profiles, permission sets, connected-app scope, owners. | 0/3/5 |
| 12 | Privileged change rights are limited to a controlled set of roles. | Access review and segregation-of-duties evidence. | 0/3/5 |
| 13 | Process logic and exception handling are documented for automated workflows. | SOPs, decision trees, approval logic, edge-case handling. | 0/3/5 |
| 14 | Operators know when automation should fire and when to override manually. | Runbooks, enablement material, support playbooks. | 0/3/5 |
| 15 | Critical automation changes are tested in sandbox before production. | Test scripts, deployment records, approval evidence. | 0/3/5 |
| 16 | There is a rollback or disable plan for high-impact automation. | Rollback checklist, feature toggle, version rollback path. | 0/3/5 |
| 17 | Automation performance and exceptions are actively monitored. | Dashboards, alerts, backlog triage, owner review. | 0/3/5 |
| 18 | The org can answer "why did this automation fire?" within a defined SLA. | Explainability artifacts, response playbook, sample incident records. | 0/3/5 |
| 19 | Change governance includes documentation updates and post-release review. | CAB records, documentation updates, release retrospectives. | 0/3/5 |
| 20 | Automation expansion decisions are tied to business risk appetite, not only delivery demand. | Governance review, approval criteria, policy statement. | 0/3/5 |
SAS Tiers
| Tier | Score Range | Meaning | Typical intervention |
|---|---|---|---|
| Fragile | 0-24 | The org is not safe for new automation. Existing logic likely contains hidden collisions, unknown owners, or uncontrolled side effects. | Freeze expansion and begin audit-led recovery. |
| Unstable | 25-44 | Some controls exist, but automation expansion will likely create incidents faster than the team can explain or contain them. | Remediate inventory, ownership, data quality, and rollback gaps before adding net-new logic. |
| Operational | 45-64 | The org can absorb targeted automation in bounded areas, but hidden risk remains on critical surfaces. | Add automation only where controls are explicit and monitored. |
| Governed | 65-84 | The org has the operating discipline required for continued automation growth. | Expand carefully with formal review and explainability artifacts. |
| Optimized | 85-100 | Automation is not only functional, but governable, explainable, and managed as a strategic system. | Use as the baseline for responsible AI and higher-order orchestration. |
OIS Integration Rules
SAS should never be read without OIS. A team may score reasonably on narrow automation controls while still operating inside a broadly opaque org.
Adjustment rule
The final reported SAS Tier cannot exceed the cap implied by OIS:
OIS band | Maximum SAS tier allowed |
|---|---|
0-40 | Fragile |
41-60 | Unstable |
61-75 | Operational |
76-85 | Governed |
86-100 | Optimized eligible |
Why the cap exists
- If overall operational visibility is low, automation safety cannot be genuinely high.
- A narrow workflow may look controlled while its surrounding dependencies remain undocumented.
OISprevents local optimism from masking systemic fragility.
Example Score Readouts
| Scenario | Raw SAS | OIS | Final tier | Interpretation |
|---|---|---|---|---|
| Good automation hygiene inside a still-messy org | 72 | 58 | Unstable | Local controls are improving, but overall org opacity still makes expansion unsafe. |
| Mid-market org with partial documentation and weak rollback | 53 | 67 | Operational | Safe for targeted improvement work, not broad automation acceleration. |
| Mature enterprise with strong governance and monitoring | 88 | 90 | Optimized | The org can expand automation and proceed toward AI readiness from a controlled base. |
Rubric With Examples
| Tier | What it feels like in practice | Example condition |
|---|---|---|
| Fragile | No one can confidently state what will fire after a record change. Operators fear touching production because side effects are unpredictable. | Multiple active layers on the same object, no rollback path, service accounts with unclear rights. |
| Unstable | The team can usually ship changes, but relies on memory, quick fixes, and heroic debugging when incidents happen. | Inventory exists for some flows, but exception handling and integration impacts are still patchy. |
| Operational | Most critical automation is known and manageable, but safety still depends on a few expert operators and partial documentation. | Core workflows are mapped, but explainability and governance are inconsistent outside top-priority areas. |
| Governed | Automation behaves as part of an operating system, not a pile of tickets. Ownership, testing, monitoring, and change review are present. | High-impact automations are documented, monitored, and governed before expansion. |
| Optimized | Leadership can expand automation because the org is explainable, measurable, and structurally controlled. | The team can trace why logic fired, who owns it, how it changed, and what risk it introduces. |
Decision Use
Use SAS when deciding:
- whether to approve a new automation wave
- whether an inherited org is safe for optimization work
- whether AI or agentic workflows have a stable automation substrate underneath them
The score is most useful when paired with:
OISfor broad operational controlAIORFfor AI-specific deployment riskAARMfor AI-agent readiness