SLA Command Centre — Supriya Nagesh

The Problem

No visibility until it was too late

Sai Dance Academy's support team was managing parent and student cases across three locations — payment issues, enrollment queries, costume orders, schedule changes. All logged in Salesforce. None of it monitored.

A parent's payment error sat unresolved for four days. By the time the team responded, the parent had already posted about it on social media. The team had no early warning system — breaches only surfaced in retrospective reports, when the damage was already done.

Operations Manager Priya needed to know which cases were at risk before they breached — not after. And she needed it without running manual reports every morning.

The Solution

A proactive SLA system — built entirely declaratively

A real-time SLA Command Centre using Salesforce Service Cloud's native Entitlements & Milestones framework. Automated alerts at 75% SLA usage, escalation flows that notify managers instantly, a formula-based health indicator on every case record, and a live dashboard — no Apex, no packages, no external tools.

Key Innovation

SLA Health — live status on every case

Instead of making agents open reports, I built a formula field that calculates SLA health in real time directly on the case record. Every case shows one of five states:

🟢 On Track 🟡 At Risk 🔴 Breached 🔴 Escalated ✅ Closed

The formula tracks the First Response window — the most critical SLA checkpoint for parent satisfaction — and updates automatically without any manual refresh.

SLA Design

Three tiers — mapped to real case types

🔴

Urgent — Payment failures, access issues First Response: 4 hours · Resolution: 8 hours · Warning at 3 hours
🟡

Standard — Enrollment queries, schedule changes First Response: 24 hours · Resolution: 48 hours · Warning at 18 hours
🟢

General — Feedback, newsletter requests First Response: 48 hours · Resolution: 120 hours · Warning at 36 hours

What I Built

Five components working together

⚙️

Entitlement Processes & Milestones Three Entitlement Processes (SDA_Urgent_SLA, SDA_Standard_SLA, SDA_General_SLA) each with First Response and Resolution milestones. The SLA clock starts the moment a case is created.
🔔

Automated 75% Warning Actions Milestone Warning Actions fire email alerts to the assigned agent at 75% of each SLA window — giving time to act before breach. Tested end-to-end with real cases.
🔄

Auto-Entitlement Assignment Flow A single Record-Triggered Flow uses Get Records (no hardcoded IDs) to automatically assign the correct Entitlement to every new case based on Priority. Zero manual work for agents.
📣

Escalation Rules with Manager Notification Time-based Escalation Rules auto-reassign cases to the Operations queue and notify Priya (Operations Manager) when cases remain open beyond threshold hours. Criteria include Status = New to prevent closed case triggers.
📊

Real-Time Service Cloud Dashboard Three-component dashboard: case health donut, breach risk by agent bar chart, and 30-day SLA compliance trend. Running user set to Operations Manager for consistent data across all viewers.

End-to-End Flow

From case creation to resolution

Parent submits case

→

Auto-Entitlement Flow assigns SLA tier

→

SLA clock starts

75% elapsed

→

Warning email → agent

→

SLA Health → 🟡 At Risk

Threshold hours passed

→

Escalation Rule fires

→

Priya notified + case reassigned

Implementation

How it was built — step by step

1

Enabled Entitlements & configured page layouts

Enabled the Entitlements feature in Service Cloud settings. Added Entitlement Name and Case Milestones related list to the Case page layout. Created three Entitlement records linked to their respective Entitlement Processes via the SLA Policy field.

2

Built three Entitlement Processes with milestones

Created SDA_Urgent_SLA, SDA_Standard_SLA, and SDA_General_SLA — each with First Response and Resolution milestones. Added Warning Actions at 75% of each window to trigger the email alert.

⚠️ Challenge: Milestones become locked after first use — cannot be edited. Resolved by creating a test process for configuration changes and documenting this as a production consideration.

3

Built the Auto-Entitlement Assignment Flow

A single Record-Triggered Flow on Case creation. Uses a Decision element to check Priority, then Get Records to fetch the correct Entitlement (no hardcoded IDs — production-safe), then Update Records to set EntitlementId on the case.

4

Created the SLA Health formula field

Formula field on Case tracking the First Response window using ISPICKVAL() for picklist comparison. Returns five states: On Track, At Risk (75%+), Breached, Escalated, Closed. Updates in real time on every case record.

⚠️ Challenge: Salesforce restricts picklist fields in IF() statements — must use ISPICKVAL() instead. Also updated Priority picklist from High/Medium/Low to Urgent/Standard/General to match the SLA design.

5

Configured Escalation Rules

Three rule entries (Urgent: 6hr, Standard: 36hr, General: 96hr) each with Status = New criteria to prevent escalation firing on closed cases. Actions reassign to SDA Operations Escalation Queue and notify the Operations Manager.

6

Built reports and dashboard

Three reports using Cases with Milestones report type: open cases by milestone status, breach risk by owner, and 30-day compliance trend. Assembled into a Service Cloud dashboard with running user set to Operations Manager.

⚠️ Challenge: MilestoneStatus not directly filterable in reports — used Violated and Completion Date fields instead. Date filters also behave differently in this report type.

7

End-to-end testing with real cases

Created 14 test cases across all three priority tiers. Verified auto-entitlement assignment, SLA Health formula transitions, Warning Action emails (including spam folder behaviour in dev org), escalation rule firing, and dashboard data population.

Honest Engineering

Decisions made & limitations found

Real builds involve real tradeoffs. Here's what I encountered and how I handled it:

Decision

Dropped duplicate alert guard Flow — used formula field instead

MilestoneStatus is not accessible on the Case object in Flow Builder, and CaseMilestone-triggered Flows have significant field access restrictions. Rather than over-engineer a workaround, I built the SLA Health formula field which provides equivalent real-time visibility. The duplicate guard is documented as a production enhancement using Apex.

Known Limitation

Milestone completion cannot be automated purely with configuration

Salesforce's Flow Builder cannot access MilestoneName on the CaseMilestone object, making declarative milestone completion automation impossible. Salesforce's own documentation recommends Apex for this. Documented as a future enhancement — the core SLA tracking and alerting works correctly without it.

Decision

Used explicit 24/7 business hours on Urgent Resolution milestone

After the milestone was used by the first test case it became locked — a known Salesforce behaviour. Rather than rebuild the entire Entitlement Process, I updated the Business Hours setting to explicit 24/7 which is functionally identical to the default for Urgent cases. Noted in documentation.

Decision

Added Status = New criteria to all Escalation Rule entries

Without this, escalation rules were firing on closed cases and sending duplicate alerts. Adding Status = New ensures rules only apply to genuinely unattended cases — standard best practice in production orgs.

Future Enhancement

Email-to-Case planned as Stage 6

Auto-creating cases from parent emails to support@saidanceacademy.com is the natural next step. Kept out of scope for this build to maintain focus on the SLA monitoring system.

Salesforce Features Used