Tag Archive for: SLAs

Acceptance Due Date: The Omni-Channel SLA Sensation You Need

/1 Comment/in /by

One of the oldest challenges in Service Cloud is ensuring your urgent work gets handled first—not just the old work, but the work that is truly closest to violating its Service Level Agreement (SLA).

You might have a customer who paid for a 2-hour response time, and another who is on a standard 8-hour agreement. Prioritizing items that enter the queue at the same time is relatively straightforward today, just using priorities. The real challenge arises over time, when your longer SLAs are approaching expiry, and new shorter ones are still entering your backlog.

Historically, we’ve relied on clever, but ultimately limited & complex uses of Primary and Secondary Priority to try to solve for this – or a lot of manual assignment by supervisors. Now, with the Winter ’26 release, we’re proving a dedicated tool for this: Acceptance Due Date

This feature is a game-changer for any service center dealing with mixed-length SLAs or simply needing to prioritize work by true urgency.

The “Why”: Solving the Mixed-SLA Problem

The issue with traditional Primary Priority is that it’s a static integer (1, 2, 3, etc.).

If you have work coming from different SLA buckets (High Priority = 2 hours; Medium Priority = 8 hours), you might set the 2-hour SLA to Primary Priority 2 and the 8-hour SLA to Primary Priority 5.

This works at the start. But what happens 7 hours later? The work item with P=5 is now an hour from expiry, while the new P=2 item still has two hours to go. The P=5 item is now more urgent, but the system will still prioritize the P=2 item.

The new Acceptance Due Date (ADD), exposed via the Acceptance Due Date field on the Route Work Flow action, solves this by making the time the prioritization factor.

The “How”: Calculating the Acceptance Due Date

Setting this up is straightforward and happens entirely within your Omni-Channel Flow.

Step 1: Calculate the Due Date

When a work item (e.g., Case, Messaging Session) is created, your Flow needs to calculate its acceptance deadline. I recommend using a formula in Flow, of type Date/Time to set the due date/time.

For example you can use these formulas:

  • 5 minute SLA: NOW() + 5 / (24*60)
  • 2-Hour SLA: NOW() + 2 / 24
  • 8-Hour SLA: NOW() + 8 / 24 

Want to use Salesforce SLAs? Check out the section further down this page on integrating with those!

Now, based on your business logic you can select which SLA is the right one for a given work item. Luckily – you are using the worlds #1 CRM, so you should be able to pull information about the person contacting you to work out their service agreements, or spend with you, loyalty status etc. to help you decide which to pick for each inbound work item.

Step 2: Route by the Acceptance Due Date

In your Omni-Channel Flow, when you use the Route Work action, you will now see an Acceptance Due Date field.

Instead of manually setting a date, you pass the dynamic date/time variable you selected in Step 1.

The magic happens when Omni-Channel compares all items in the queue: it will automatically prioritize the work item whose Acceptance Due Date is the earliest (i.e., the item closest to expiration or already expired).

The Technical Gotcha: Unifying Priority for True Urgency

This is the most crucial part to understand and is what separates a successful implementation from a confusing one.

The routing engine uses the following prioritization order:

  1. Primary Priority (Lowest number wins, e.g., 1 is highest priority in Salesforce routing)
  2. Secondary Priority (Lowest number wins – same as Primary) – Optional
  3. Target Acceptance Date (Earliest date wins) – Optional
  4. Date Enters Queue (Oldest work wins)

If you want Acceptance Due Date to be your primary mechanism for determining urgency, you must ensure all work items being compared have the same Primary & Secondary Priority.

Action: Set the Primary Priority field to a single, consistent value for all work items that you want routed by SLA – this comes from your Routing Configuration. You’ll also want to ensure your Secondary Routing Priority isn’t being set – you can find this in the Service Channel settings in Setup for the given channel.

Best Practice: The P=5 Rule (Leaving Room for Firefighters)

For a stable, reliable setup, don’t set your SLA-routed work items to Primary Priority 1.

Suggestion: Start your default SLA-driven Primary Priority value at P=5.

This gives you P=1, P=2, P=3, and P=4 to use for true human-driven overrides. If a supervisor needs to put a true “fire drill” ahead of the Acceptance due date logic, they can manually update that work item’s Primary Priority to 1 or 2, ensuring it bypasses the SLA queue and gets routed first, while the rest of your system continues to function perfectly using the Acceptance Due Date.

By combining the dynamic calculation of Acceptance Due Date with a unified, moderate Primary Priority value, you finally have an Omni-Channel routing system that prioritizes work based on true, calculated SLA urgency.

See it in action!

Want to see it in action? Check out this video from our friend Magulan Duraipandian over at Infallibilbe Techie walk you through how this works:

Bonus! Integrate with Salesforce SLAs

You can integrate this process with Salesforce SLAs – formally known as Entitlements & Milestones. This is only supported for the Case and Work Order objects right now. You can reuse your existing Milestone Types, or create a new specific one for the Acceptance Due Date – it’s up to you. Creating a new one will mean you can re-use your reporting on Milestones to track it, but you can also report on it from the AgentWork record, as detailed in our help docs. To get the target date, follow these steps

  1. Load the ‘Milestone’ object your are using by ‘Name’
  2. Load the ‘Case Milestone’ record with the ‘recordId’ of the Case we’re routing and the ‘Milestone Type ID’ you loaded in Step 1
  3. In your ‘Route Work’ action, use the ‘TargetDate’ field on the ‘Case Milestone’ you loaded in step 2

Done! Just like that, the SLAs you’ve already been using can now drive Routing in Omni-Channel. Magic!

What about reporting if you hitting the target?

One of the most important measures in many contact centers is whether you answered calls within a certain time period, or if you are hitting you SLAs – these can often come with financial penalties if you don’t. While we have SLA Management within Service Cloud that may be more suited to reporting on some of those targets, you can report whether you hit your target acceptance date or not.

The key fields live on the ‘AgentWork’ record, named: ‘Accept Date’ and ‘Target Accept Date Time’. You can add these to a any Report Type that includes the ‘AgentWork’ object. Once you’ve added them, you’ll then want to include them into a report to compare the values.

You then have a choice as to that you want to do in terms of a Row-Level Formula – either create one that outputs Text or a Number. To calculate the Text one, you can use a formula like this: 

IF(ISNULL(AgentWork.TargetAcceptDateTime), NULL, IF(AgentWork.AcceptDateTime > AgentWork.TargetAcceptDateTime, "Target Not Met", "Met Target"))
(substitute 1s and 0s for a number type)
(I suggest filtering out records without a 'TargetAcceptDateTime' value and that aren't closed yet)

At that point you can then choose what to do with this – I’ve created reports where I group by this Row-Level. Then you can use a ‘Summary-Level Formula’ to calculate a percentage of the records in your report that are in each group – giving you the percentage of records that hit the target date.