The Safe Automation Scoring (SAS) model measures how safe a Salesforce environment is for additional automation expansion.
The Safe Automation Scoring (SAS) model measures how safe a Salesforce environment is for additional automation expansion.
It is designed for three decisions:
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.
20 criteria.5 points.5 when the criterion is fully true.3 when partially true or inconsistently true.0 when false, absent, or not evidenced.Raw SAS = sum(all criterion scores)
Maximum score: 100
| # | 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 |
| 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. |
SAS should never be read without OIS. A team may score reasonably on narrow automation controls while still operating inside a broadly opaque org.
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 |
OIS prevents local optimism from masking systemic fragility.| 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. |
| 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. |
Use SAS when deciding:
The score is most useful when paired with:
OIS for broad operational controlAIORF for AI-specific deployment riskAARM for AI-agent readinessEmail hello@unseen.so to request an AI Readiness Audit.