Overview
This guide covers administrative configuration for SLA Management: creating and managing SLA definitions, configuring module settings, and assigning permissions.Permission Model
Permission Keys
RLS Enforcement
All SLA tables enforce multi-tenant isolation via thepf_has_org_access SECURITY DEFINER function. Only users within the same organization can access SLA data. UPDATE policies include WITH CHECK clauses.
Initial Setup
Step 1: Configure Module Settings
SLA-related settings are stored inpf_module_settings (one row per organization):
Step 2: Create SLA Definitions
- Navigate to Settings → SLA → Definitions
- Click New Definition
- Fill in:
- Name — Descriptive label (e.g., “Lead Response Time”)
- SLA Type —
response_time,resolution_time,follow_up, orcustom - Owning Core — Which module this SLA belongs to (e.g.,
ce,hr,rh) - Trigger Event — The
fw_domain_eventsevent type that starts the clock - Completion Event — The event type that stops the clock
- Target Duration (hours) — The deadline
- Warning Threshold (%) — When to flag as “at-risk” (default: 80%)
- Escalation Config — Optional escalation levels with notification targets
- Priority Overrides — Optional per-priority deadline adjustments
- Click Save
Step 3: Assign Permissions
To assign:
- Go to Settings → Roles & Permissions
- Select the role
- Enable the required SLA permissions
- Save
Database Tables
Event Integration
SLA Management publishes these events tofw_domain_events:
These events can trigger PF-10 notifications for escalation.
Best Practices
- Start simple — Create 2–3 critical SLA definitions before expanding
- Set realistic thresholds — Warning at 75–80% gives staff time to act
- Audit regularly — Review compliance rates monthly; adjust targets as needed
- Least privilege — Grant
definition.manageonly to admins; most staff need onlyview - Use priority overrides — Different urgency levels may need different deadlines