ProfessorFlow
Release NotesBeginner

Business Hours Toolkit: Four Flow Actions That Know When You're Closed

Four new Salesforce Flow actions for SLA, escalation, and scheduling logic that respect your org's business hours, holidays, and timezone. Live now.

April 17, 20267 min

A Friday at 4:55 PM

Picture a Salesforce support team in Austin. It's Friday at 4:55 PM. The team has five minutes before the weekend.

A Priority 1 case lands in the queue. The Flow that manages SLAs does its thing: CreatedDate + 4 hours. Deadline set for 8:55 PM, that same Friday night. The record saves. The timer starts. The team, unaware, logs off.

At 8:55 PM, the breach rule fires. The on-call manager opens her laptop outside a restaurant and confirms what she already suspects: nobody's been looking at this case, because the office closed at 5 PM. There was never going to be a resolution tonight.

Monday morning, the retrospective is short. "The SLA was wrong." Not the team. Not the process. The number on the record — that was the lie. It was set by math that didn't know the office closes at 5 PM on Fridays.

This is the story of every support org, every field service team, every scheduler, every "we'll get back to you within X hours" promise I've ever seen. Flow is brilliant at arithmetic and completely oblivious to your calendar.

The Business Hours Toolkit is the fix.

Key Takeaways
  • One bundle, four actions. Add business-hours-aware time. Measure elapsed business hours. Check if a moment is open. Find the next open moment.
  • Uses your org's Business Hours record — holidays, weekends, and timezones already handled.
  • Built for the places Flow most often lies — SLA timers, escalations, scheduling, and resolution dashboards.
  • Install the bundle or pick actions individually. Both deploy in minutes.
  • Live now for Spring '26 orgs on Professional through Unlimited.
Invocable actions
4
Lines of Apex you write
0
Deploy command
1
API version
66.0

What Actually Went Wrong

Before the fix, it helps to be precise about the failure.

Loading diagram...

The Flow wasn't broken. The math wasn't wrong. The premise was wrong. Four hours of clock time from 4:55 PM Friday is 8:55 PM Friday. Four hours of working time from 4:55 PM Friday — 9-to-5, Monday-to-Friday — is Tuesday 12:55 PM.

Those are different answers. Until now, Flow only knew how to give you the first one.

The four actions below each teach Flow a different piece of the missing vocabulary. Let's walk through the rebuild in the order the problems actually surfaced.

Monday Morning: Rebuilding the SLA Flow

Add Business Hours: the deadline tells the truth

The old SLA field was a formula: CreatedDate + 4/24. Simple. Wrong half the time.

The team replaces it with a one-line Flow that calls Add Business Hours. The action takes the CreatedDate, the Business Hours Id on the case's entitlement, and an interval of 14400000 milliseconds — four hours. It returns the honest deadline.

A Friday 4:55 PM case now resolves to a deadline of Tuesday 12:55 PM. If Monday is a holiday, Wednesday 12:55 PM. The number on the record finally matches what the team can realistically hit.

Action 1 — Add Business Hours
What "four hours later" should have meant all along.

Give it a starting DateTime, a Business Hours Id, and an interval in milliseconds. Get back a DateTime that sits that many business hours later — weekends and holidays already factored out.

Earns its keep in: SLA deadlines, promise-by dates, first-response targets, project milestone projections.

Calculate Business Hours Difference: the dashboard stops lying

Next target: the CSAT dashboard. For two quarters, it had been reporting "Average time to resolution: 64 hours," a number the support director had been explaining away in every QBR. It counted every second of every weekend.

The team drops Calculate Business Hours Difference into the case-close flow. Feed it CreatedDate, ClosedDate, and the Business Hours Id. It returns elapsed time in milliseconds, seconds, and minutes, so whoever's downstream doesn't have to do the conversion.

The Friday 4:55 PM case that closes Monday 9:10 AM? Raw math: 64 hours. Business-hours math: 15 minutes. Same record. Wildly different story. The dashboard finally tells the one the team earned.

Action 2 — Calculate Business Hours Difference
Elapsed time, minus the weekend.

Two DateTimes in, one Business Hours Id, three unit-flavors of the answer out: milliseconds, seconds, minutes.

Earns its keep in: resolution-time dashboards, first-response metrics, SLA compliance reports, time-in-status fields.

Is Inside Business Hours: the pager stops firing into the void

The high-priority escalation flow — the one that woke the on-call manager on Friday night — is a scheduled flow that scans unresolved cases and pages someone if the SLA is close.

The team adds one step. Before the page fires, Calculate Is Inside Business Hours checks the current moment against the Business Hours Id. If the answer is true, page someone. If it's 8:55 PM Friday, the answer is false and the flow holds. The case is still flagged in queue. But nobody's phone rings for a problem they cannot act on for the next sixty hours.

Action 3 — Calculate Is Inside Business Hours
A one-Boolean question: is anyone actually here right now?

One DateTime, one Business Hours Id. A Boolean comes back. The whole story.

Earns its keep in: on-hours routing, after-hours gating for alerts and outbound sends, conditional automation, queue-vs-pager decisions.

Next Business Date: the callback actually gets made

The product's web form lets anyone request a callback — including someone browsing at 10 PM on a Saturday. For months, those requests had two unhappy endings: call back too late Monday (customer already went elsewhere), or hit an auto-dialer at 3 AM (customer very much there, and annoyed).

The fix is Calculate Next Business Date. Feed it the request timestamp; it returns the next moment the phone line is legitimately open. A 10 PM Saturday request returns Monday 9:00 AM. A Wednesday 11 AM request returns Wednesday 11 AM unchanged, because the line is already open.

The callback flow schedules tasks for that returned time. The first Monday after the change, the morning queue was full of calls ready to dial at 9:00 AM sharp.

Action 4 — Calculate Next Business Date
The "when do we open next?" answer, on demand.

Give it a DateTime and a Business Hours Id. Get back the next DateTime business hours are open. If you're already inside business hours, your input comes back unchanged.

Earns its keep in: deferred callbacks, Salesforce Flow Scheduled Paths that fire at a sensible hour, "we'll reply the next business day" patterns, appointment-booking fallbacks.

The Following Friday

Same team. Same desk. Same 4:55 PM Priority 1 case.

The SLA field now reads Tuesday, 12:55 PM. The queue tags it for Monday's first triage. The escalation flow checks the clock, sees it's after hours, and stays quiet. The customer gets an auto-reply that promises a response Monday morning.

At 9:04 AM Monday, an agent picks it up. The case closes at 9:10 AM — five working minutes after the team came back online. The dashboard tallies it as a five-minute resolution. The on-call manager's phone does not ring all weekend.

Nothing heroic happened. That's the whole point. The automation finally matched reality.

Composing the Four Business Hours Actions

The actions are quietly better together than apart. A handful of Salesforce Flow patterns worth stealing:

Toolkit or Standalone?

Four actions, one deploy — or four standalone components picked à la carte. Depends on how you roll out.

Install the toolkit when…
  • You want two or more of these actions
  • You're building SLA-aware automation and expect to reach for all of them
  • You prefer a single source of truth for business-hours logic in your org
  • You're comfortable deploying four classes plus their tests in one go
Install individually when…
  • You only need one specific capability and want to keep the org lean
  • Your change-management rules favor small, targeted deployments
  • You're solving a single Flow, not rebuilding a platform
  • You want to stage the rollout one capability at a time

Pick Your Starting Point

If you own automation day-to-day
Start with the lie that costs you the most.

If your SLA deadlines use raw DateTime math, Add Business Hours is the one-line fix that changes the most. After that, add Is Inside Business Hours to any alert or escalation that's ever fired at an inconvenient hour.

Install the Salesforce Flow Business Hours Toolkit

The toolkit is a standard SFDX project. One deploy command puts all four classes (and their tests) into your org.

sf project deploy start --source-dir force-app

Open Flow Builder, drop an Action element, search "Professor Flow" — all four actions are there, waiting to be mapped.

Full specs, input/output tables, and the repo live on the Business Hours Toolkit page. Each individual action has its own page too: Add Business Hours, Calculate Business Hours Difference, Calculate Is Inside Business Hours, and Calculate Next Business Date.

Frequently Asked Questions

What This Is Really About

The small lies your Flows tell — "deadline: Friday 8:55 PM" when nobody is there, "resolution time: 64 hours" when it took fifteen working minutes, "escalate now" at 10 PM on a Saturday — quietly erode trust. Support managers defend their teams against numbers that were never true. Customers wait for callbacks scheduled into the dead of night. Pagers fire into empty offices.

The Business Hours Toolkit doesn't add capability. It corrects a lie of omission. Install it, swap one calculation, and watch your automation start telling the truth.

Search

Search components, articles, and tags