EspoCRM SLA timers and escalations with BPM: when your team needs them
A support or service team that promises response times will miss them whenever a case sits unread in a queue. EspoCRM can run SLA timers and escalations through the BPM process engine in its Advanced Pack, so a case that goes past its deadline can notify a manager or move to someone else without a person watching the list. The Advanced Pack is an official add-on, and it is included in all EspoCRM Cloud plans. If you self-host, you need to license and install it yourself before any timer or escalation logic can run.
The question is whether a timed escalation is worth building or whether a simple notification is enough. A plain workflow notification suits teams where a person checks the queue several times a day and the cost of a missed response is low. A timed BPM process earns its place when the deadline must hold even if nobody opens the case, when escalation has more than one step (for example, notify the case owner, then the team lead, then reassign), or when the response target differs by case type or customer tier. Ask who owns each step, what happens when the owner is on leave, and whether the escalation path needs an audit trail of who was told and when.
Before you build, confirm three things in your own environment. Check that your Advanced Pack version supports the timer events and user task behavior you plan to use, because process features can differ between releases. Confirm that cron or the scheduled task is running on a self-hosted instance, since background jobs depend on it. Decide how the process tracks the case state so that a reply or status change stops the timer and does not trigger a false escalation. Testing these paths with a few sample cases before rollout is the step that most often exposes gaps.
Which escalation design fits your service model
This table compares the main configuration choices for SLA timers and escalations in EspoCRM: how the timer is triggered, what the escalation does, how the due time is calculated and how an escalation stops. Read each row against your service model, then confirm the listed behaviors in the Advanced Pack BPM documentation for your installed version before you commit to a design.
| Decision | Option | Trade-off | Choose it when |
|---|---|---|---|
| Timer trigger | BPM timer event on the case process | Each case gets its own timer and runs as a process instance, so the due time and state are visible per case. Confirm how timers survive restarts and how many open instances the installed version handles comfortably. | You need a per-case clock with a visible process history and a defined path for each stage. |
| Timer trigger | Workflow-based check on a schedule | Simpler to reason about and easy to audit against a list report, but it checks in batches, so a breach can be detected later than the due time. Confirm the scheduling interval and how the check is run by cron. | Tolerance for detection delay is acceptable and the breach rule can be expressed as a list condition. |
| Escalation action | Notify the manager | Keeps ownership with the current assignee and adds visibility. Confirm which notification channel the installed version supports from a BPM script task and how recipients are resolved. | The team needs awareness of breaches but case ownership should stay unchanged. |
| Escalation action | Reassign to another user or team | Gets overdue work moving, but changes the owner and can hide the original delay. Confirm how the assignment field and team are set from a formula and whether the previous owner is kept in the log. | Overdue cases must move to a queue that has capacity, and reporting can show the handoff. |
| Escalation action | Notify and reassign together | Gives the new owner context and tells the manager what changed, at the cost of two actions that must fail safely. Test the order of the steps so a failed notification does not block the reassignment. | Your SLA has named second-line owners and managers need a record of every handoff. |
| Due time calculation | Fixed hours from case creation | Easy to explain and test, but ignores business hours, holidays and time spent in pending states. Confirm how the installed BPM timer is defined and whether it can pause. | Response windows are flat and run around the clock, such as automated acknowledgements. |
| Due time calculation | Formula script on the case | Can subtract non-working time, use priority or account tier and store the calculated due date on the record. Formula Script runs in workflows and BPM, but the scheduling of a formula-computed due date must be confirmed against the timer configuration. | Priority, customer tier or business hours change the target, and reports need the due date as a field. |
| Stopping on response | Interrupt the timer when a response is logged | Clean for the customer and the team when the trigger reliably fires on the response event. Confirm which record event (such as a new note or status change) the installed version can catch and how a sent email is recorded against the case. | Responses arrive through a defined channel that writes to the case, such as email-to-case or a logged call. |
| Stopping on response | Check for a response inside the escalation step | Works when responses are not reliably signaled, but can escalate a case that was answered minutes earlier. Add a guard formula that reads the first response time before any action runs. | Responses come through several channels and some do not create a catchable event. |
How SLA design changes by team structure
A single queue is the simplest shape. One case type, one response target, and one team that picks up work. The timer usually starts when a case is created and stops on the first agent reply or status change to a waiting state. Escalation normally has one step: notify the queue lead when the timer fires, then reassign to a named backup team if the case stays unanswered. Because every case shares the same clock, the main design question is what counts as a response. Automated acknowledgment emails, internal notes and status changes can all stop or reset a timer by mistake, so the process must test which actions count.
- Start condition: Confirm whether the timer starts on creation, on email-to-case intake or on a specific priority value.
- Stop condition: Decide if an internal note stops the clock or only a customer-visible reply does.
- Escalation target: Name the queue lead or a shared overflow team, and make sure the assignment works when that person is absent.
- Business hours: Ask whether the target runs on calendar time or on working hours, and how holidays are handled.
The most useful test is a set of cases created at different times of day, with replies sent through each channel your team uses. Check that every timer stops, fires or resets exactly as your written policy says.
When several teams handle different products or customer tiers, the timer depends on the case category and the customer agreement. Each team may have its own response target, its own business hours and its own escalation path. The design usually needs a lookup from case type or account tier to a target value, so one process can serve all teams without copies. The escalation target also changes: a billing case might escalate to a finance lead, while a platform outage escalates to on-call engineering. Team membership in EspoCRM, set through teams and roles, determines who receives each notification and who can take over reassigned work.
- Target lookup: Store response targets in one place, such as a configuration entity, rather than hard-coding values into each branch.
- Team mapping: Map each category to one owning team and one overflow team, and record both in writing.
- Role permissions: Confirm that overflow team members can open and edit reassigned cases, since visibility rules can block them.
- Exception handling: Decide what happens when a case has no category, because it cannot match a target.
Test each category separately and include one case with missing data. Also test a reassignment across teams to confirm that the new owner receives the notification and the old owner no longer sees active work.
For sales teams, the timer usually tracks first contact on a new lead rather than case resolution. The clock starts when a lead is assigned or captured, and it stops when a logged call, meeting or outbound email is recorded against that lead. Escalation tends to be lighter and faster: notify the owner, then the sales manager, and then optionally reassign the lead to another representative. The risk here is that activity may be logged inconsistently, so a rep who contacts a prospect but forgets to record it will see the timer escalate anyway. Ownership changes from assignment rules can also restart or confuse the clock, so the timer and the assignment logic must be designed together.
- Start event: Decide whether the timer starts on lead creation, on assignment or on a qualifying source.
- Qualifying activity: Define which logged activities count as first contact and whether automated emails count.
- Manager escalation: Set who receives the manager alert and whether the alert repeats.
- Reassignment rules: Confirm that reassignment updates the owner used by the timer and does not create a second timer.
Test with leads captured from each source, and include a rep who logs contact late. Verify that the timer reflects the logged activity, not the time the call actually happened, and document that difference for managers.
Across all three shapes, the parts that need the most testing are the boundaries: the start event, the stop event, the reset rule and the handoff between owners. A design can look correct on a single happy-path case and still fail when a case changes category midway, is reopened after closing, or is moved to another team while its timer is running. Concurrency matters too, because timers and scheduled jobs run in the background, and a job that is delayed or queued can fire an escalation after the work has already been done. The EspoCRM background job process depends on cron or a scheduled task, so the test plan must include how quickly timers are evaluated in your hosting setup.
- Reopen and reclassify: Test cases that move back to open or change category while a timer is active.
- Delayed jobs: Measure how late a timer can fire when background jobs are backed up, and set expectations with the business.
- Duplicate notifications: Confirm that repeated runs do not send the same escalation email many times.
- Audit trail: Check that each timer start, stop, escalation and reassignment is visible in the process log.
- Load: Run a realistic volume of open cases through the process before go-live.
Ask your implementation partner for a written test matrix covering these cases, and confirm which results your own managers will sign off on before production use.
How to set up SLA timers and escalations in EspoCRM BPM
This sequence takes a team from confirmed Advanced Pack access to a tested BPM process that starts a response timer on each case, escalates overdue work to a manager and reassigns it when the target passes.
Confirm the Advanced Pack is installed
An administrator checks that the Advanced Pack is installed and enabled, since Business Process Management and workflows come from that extension. Confirm the BPM administration area and the process designer are visible to the admin account. If you run self-hosted EspoCRM, confirm the extension version matches your EspoCRM core version before you build anything. The step is done when a test process definition can be created and saved without errors. Hosted plans include the Advanced Pack, so confirm with your plan which edition you have.
Define response targets for each priority
Your service lead writes down the response target for each case priority, along with the event that starts the clock, such as case creation, and the statuses that stop it, such as first response or resolution. Agree who owns each target and who is notified at each escalation level. Record the targets in a shared document that the build team can reference. Keep the numbers out of the process logic until they are approved. The step is done when every priority has a signed-off target, a start event and a stop condition.
Create the process model with timer and escalation events
In the BPM designer, build a process started by case creation or a relevant status change. Add a timer event that waits for the response target to pass, then an exclusive gateway that checks whether the case is still open and unanswered. On the overdue path, add an escalation step that notifies the manager and a reassignment step. Keep a separate path that ends the process when the case is answered or closed. Validate the diagram and save it. The step is done when the model validates and each path has a defined end.
Write due-time and stop logic in Formula Script
Use Formula Script in the process to calculate the due time from the case priority and creation timestamp, and to evaluate whether the stop condition is already true when the timer fires. Keep the logic readable: one expression for the due time, one for the stop check, and a clear mapping from priority to target. Test each expression in the formula evaluation context before you connect it to the model. The step is done when a sample case produces the expected due time and stop result.
Set up manager and team assignments
Configure which user receives the escalation notice and which team or user receives reassigned cases. Use team membership or a field on the case rather than hard-coded user IDs where possible, so changes to staff do not require a process edit. Confirm that the reassignment target has the permissions needed to see and update the case. The step is done when a test escalation sends a notification to the right manager and assigns the case to the intended team or user.
Confirm cron runs the scheduled jobs
Timer events depend on background jobs. Confirm that cron, or the scheduled task runner your hosting uses, executes the EspoCRM job script at the interval the server configuration documents, and that the process engine is running under the same web user as the application. Check the job log for entries after the first run. Without cron, timers will not fire and escalations will never happen, so this check matters more than the diagram. The step is done when the job log shows recent background activity and the scheduler runs without errors.
Test with on-time and overdue sample cases
Create sample cases in a test instance or a non-production copy. Run one case that is answered before its target, one that stays open past the target and one that is closed before the timer fires. Confirm the on-time case ends the process without escalation, the overdue case notifies the manager and reassigns the case, and the closed case stops the timer. Review the process log for each run. Use illustrative test data only, and do not use live customer records. The step is done when all three cases behave as specified and the log shows the expected path for each.
Document the process and hand over operations
Write a short runbook covering the response targets, the process owner, the escalation contacts, the cron requirement and how to review the process log. Record who can change targets and how changes are tested before release. Schedule a periodic check of the job log and a test case run after any EspoCRM upgrade or extension update. The step is done when the runbook is stored with the process definition and the support team can explain the escalation path without the build team.
Where SLA clocks and escalations usually go wrong
Most SLA failures come from clock logic, not from the escalation step itself. A timer that runs on calendar hours will breach a case on a Saturday morning that nobody on the support team could have worked, and a timer that ignores time zones will fire at the wrong hour for a team split across regions. Before building anything in the BPM process, decide how the response clock is defined: which hours count, which holidays are excluded, which time zone governs each queue, and whether the clock pauses while the case waits on the customer. None of these exist as a single switch in a generic timer, so each one needs a designed rule and a test that proves it.
The other failures show up after go-live. A case that is reopened after closure may start a second timer while the first process instance is still in its history, so the same case can be escalated twice. A status change to a waiting or resolved state may not stop the timer if the process only listens for one trigger. A process that restarts after an edit, a failed step or a deployment can re-fire escalations that already went to a manager. Each of these needs an explicit test case with a named starting state, the action taken, and the expected number of notifications and reassignments afterward. Confirm with your build how the platform handles each one, including whether a closed or reopened case creates a new process instance or resumes an existing one.
The last risk is operational. Timers and escalations run only if the background job runner executes. EspoCRM's server configuration requires cron or a scheduled task for background jobs, so an escalation that never fires can look like a process that never started. Ask whether the cron entry exists on every environment, including staging, and set up a check that alerts when scheduled work stops. Treat a silent failure as the most likely production defect, and test it by pausing cron in a non-production environment and confirming that your monitoring reports the gap.
Security and access controls for escalation rules
An escalation rule moves cases, notifies managers and reassigns work, so it carries more authority than a typical workflow. The controls below cover who can change the process, who sees the cases it touches, which identity runs it, and how changes are recorded. Check each one before the first timer goes live.
Restrict who edits process models
Changing a BPMN timer duration or an escalation target changes who gets paged and when. Limit edit rights on process definitions to a small named group, separate from people who only run or monitor processes. Review every change to a timer or target as you would a configuration change. Ask your EspoCRM partner which roles are needed to publish, edit and deactivate a process, and confirm that a process can be disabled without deleting its history.
Govern formula script changes
Formula scripts that compute due dates, priority or escalation thresholds run inside the same logic as the process, so a wrong script can reassign cases silently. Restrict who can write formulas in the Entity Manager and workflows, and test each change against sample cases before deployment. Keep a written record of the intended behavior so that a reviewer can tell whether a script still matches it.
Scope case visibility by role and team
An escalated case should be visible to the people who must act on it and to the managers who escalate it, and to no one else. Map each escalation level to a role and team, then check that reassignment targets can actually open the case under their own permissions. A reassignment to a user who cannot see the record will stall the timer without an obvious error. Test visibility with a non-admin account for each level.
Scope API users that start processes
Integrations that create cases or trigger timers through the REST API should run under dedicated API users with narrow role permissions. Choose HMAC authentication where your integration supports it, since the EspoCRM docs describe it as the most secure option and basic authentication as not recommended. Confirm the API user can start the intended process and nothing else, and rotate its credentials on a schedule you can name.
Keep admins out of escalation handling
An administrator who also works the queue can reassign or close escalated cases with rights no agent should have. Assign escalation tasks and manager notifications to standard user accounts, and keep admin accounts for configuration only. Disable password recovery for admin accounts and require two-factor authentication for them, as the EspoCRM security docs recommend. Confirm that someone other than the admin can recover access if the admin account is locked.
Audit process and record changes
When a case is reassigned by a timer, the reader needs to know which rule fired, when, and what changed. Review the process log for each escalation path, and confirm that changes to process definitions are traceable to a named person. Decide how long logs are kept and who may read them, since escalation history often shows staffing and performance details. Ask your partner how the log is exported for an auditor or a dispute.
Questions buyers ask before building SLA escalations
What drives the cost of a timed escalation design in EspoCRM?
The main driver is how many SLA rules you need and how many paths each one takes. A single response-time timer on cases is a small piece of work. Separate rules for priority levels, customer tiers, business hours and several escalation levels multiply the number of timer events, gateways and notifications that must be designed, built and tested. Cost has three parts: the design workshop where SLA targets and manager chains are agreed, the build in the Advanced Pack's BPMN process engine, and the test cycle with real case data. Ask any quote to itemize these three parts and to state which items are one-time and which recur, such as updating rules when targets change.
How long does a build and test cycle usually take?
Duration depends on how many SLA tiers, escalation levels and team structures are in scope, and on how quickly your team confirms the targets. The Advanced Pack, which provides the BPM and workflow engine, is included in all EspoCRM Cloud plans, so licensing does not add a waiting period, but self-hosted instances still need the Advanced Pack installed and configured. Ask for a timeline in the written scope that separates design sign-off, build, test with recorded cases and cutover. Timelines should be confirmed against your own environment and change process rather than assumed from another deployment.
What does our team need to provide for the SLA design?
The design depends on decisions only your organization can make. You need the response and resolution targets for each case type and priority, the definition of when the clock starts and stops, and the business hours or calendars that apply. You also need the team structure: which teams own which cases, how agents are grouped, and who covers absences. Finally, provide the manager hierarchy that receives notifications at each escalation level, including backups for when a manager is away. Without these inputs, the process model cannot be finalized, so confirm them in the discovery stage before any build starts.
Can a skilled internal admin build SLA escalations alone?
Yes, a competent EspoCRM administrator can build a basic timer with a notification, because BPM processes are configured in the application and the Formula Script language is documented. The harder parts are testing timer behavior across time zones and business hours, handling cases that are reassigned or reopened mid-timer, and keeping the process model consistent with the service policy. Ask yourself whether anyone on your team can maintain the process after the first build and document the reasoning behind each gateway. An outside partner is most useful for design review, test planning and handover, and the split of work should be written into the scope.
What changes when our SLA model changes later?
A change to targets, priorities or escalation levels usually touches the process model, the formula logic that calculates due times, and the notification recipients. Small changes such as a new target value are cheap if the rules were built with parameters. Structural changes, such as adding an escalation level or a new team, require a new design, regression testing of existing open cases, and a decision about whether in-flight processes follow the old or new rules. Ask for a change procedure in the handover that states who approves changes, how they are tested, and how running processes are handled.
What recurring work comes after the escalations go live?
Recurring work includes reviewing escalation logs, updating manager hierarchies when staff change, checking that notifications are delivered, and applying EspoCRM upgrades to the process engine. Background jobs must run through cron or a scheduled task, as the server configuration requires, and a stalled job can silently stop timers from firing. Ask for a monitoring check on that job and a named owner for each recurring task. Ongoing support and upgrades can be arranged as a retainer, and its scope should be written separately from the initial build.
What risks should we check before turning on automatic reassignment?
Automatic reassignment of overdue work changes who owns a customer issue, so the rules must be tested against edge cases before go-live. Check what happens when no eligible agent exists, when a case is already being worked, and when the reassignment target is on leave. Confirm that every reassignment and notification is recorded so that managers can audit decisions. Restrict who can edit SLA rules, since a wrong change can reroute an entire queue, and align those permissions with your access model and role design.
Limits to confirm in your environment
SLA timers and escalations depend on how the Advanced Pack's BPM engine behaves in your installed version and on your own hosting. Each card below is a question to settle with the vendor documentation or a test instance before a design is promised, since the answers change how timers, calendars and escalations are built.
Timer event precision in your version
Ask how precisely a BPM timer event fires once its duration elapses, and whether it is evaluated on a schedule or on demand. The answer decides whether a four-hour response target can be enforced to the minute or only checked at the next background run. Confirm the behavior in the Advanced Pack version you will install, and measure it on a test case with a known start time before writing any SLA into a contract.
Business-hour calendars
Ask whether the process engine supports business-hour or holiday calendars natively, or whether you must calculate working time with formula logic. Most response targets are measured in working hours, so a native calendar saves design work, while formula logic means you own the holiday table and the edge cases around weekends, time zones and shift changes. Write the calculation down before the build starts.
Escalation behavior across upgrades
Ask how running process instances, timers and their definitions are handled when the EspoCRM version changes. A case that is halfway through an escalation path can break if the process model or the scripting behavior changes between releases. Plan a test upgrade on a copy of production that includes open cases with pending timers, and confirm the timers still fire on the expected dates afterward.
Concurrent timer volume
Ask how many open timers the engine can hold and process per run without delay, and how the database grows as process instances accumulate. Support teams with high case volumes can create thousands of pending timers, so measure the load with realistic volumes in a test environment and check whether completed instances are archived or purged.
Background job hosting
Confirm that your hosting runs the scheduled job runner reliably. EspoCRM requires cron or a scheduled task for background jobs, and a missed run delays every timer and escalation without an obvious error on screen. Check how your Docker, Nginx or Apache setup starts the job, how failures are logged, and how you will be alerted when runs stop.
Notification delivery for escalations
Ask whether manager notifications and reassignment steps depend on outbound email, and what happens when mail delivery fails. An escalation that only sends email can go unseen if the mail server is misconfigured, so confirm delivery settings, test a manager notification end to end, and decide whether an in-app notification or task should back up each email.
How DeployOpen scopes and delivers EspoCRM SLA escalations
DeployOpen plans, builds, tests and documents EspoCRM SLA timers and escalations inside infrastructure you control. Engagements are fixed-scope, so the timers, escalation paths and deliverables are agreed in writing before the BPM process is built.
How we scope
- We list the case types, priority levels and response targets that the written scope covers, using your agreed service definitions.
- We map which teams, managers and queues receive each escalation step and who may reassign overdue cases.
- We confirm the EspoCRM version, Advanced Pack licensing and hosting environment so timer and cron behavior is planned correctly.
How we build
- We model the case timers, escalation events and reassignment steps as a BPM process in the Advanced Pack, with formula logic for due dates and status.
- We configure notifications to managers and assignment fallbacks, then test boundary cases such as cases closed just before deadline and reopened cases.
- We verify that scheduled background jobs run on your server, so timers fire on time without manual intervention.
How we hand over
- We deliver the process definition, a configuration record, test results and a description of each timer and escalation path.
- We document the operational runbook, including how to pause a process, adjust a response target and review the process log.
- We walk your administrators and service managers through the process so they can change routing rules without rebuilding it.
How we support
- Ongoing support, upgrades and testing of the process are available as a retainer after handover.
- We review the process when EspoCRM is upgraded or when extensions and PHP versions change, with a plan agreed in writing.
- We confirm changes to response targets or team structure through a written change request before they reach production.
