Consider using Apex instead of formula.
Here's why as of January 2021 (SFDC API Version 50.0) . (@ for edits):
Be skeptical of using formula fields for datetime difference calculations
because of a limitation with formula fields, quoted below:
Important: Be aware of timezone conversion issues when using formula
fields to calculate datetime differences:
Within the Salesforce application, dates & date/times are stored and
managed in UTC (Universal Time Zone or Greenwich Mean Time). Date and
Date/Time field values are converted and displayed in the timezone
specified in your user personal information settings. However, in a
formula, NO TIMEZONE CONVERSION IS PERFORMED. This means, unless you happen to be in London, your date calculations will be off by the
number of hours you are shifted away from GMT (and don't forget about
daylight savings time).
An (imperfect) formula and why its bad:
The problem with formula is, as of January 2021 they have the limitations mentioned above. This next example is imperfect like the one above is imperfect: "Find the Number of Business Hours Between Two Date/Times" here https://developer.salesforce.com/docs/atlas.en-us.usefulFormulaFields.meta/usefulFormulaFields/formula_examples_dates.htm
As of January 2021 it seems that declarative Formulas (incl. flows/workflows/process builder, etc ) are limited in that they cannot access setup menu's concept of BusinessHours (ie
$Setup.DefaultBusinessHours doesnt exist and will not compile/save into a formula).
A system admin could solve using Apex:
Many google results settle for a imperfect solutions using long-written formulas that hardcode/assume one timezone and working hours, but they often dont control for holidays and are not a perfect solution for all user time zones. Formulas have strict length limits too so you cannot easily write formulas that handle for all those realities. Therefore until the GA Roadmap matures its declarative featureset, Apex is more accurate/durable at the moment for this question.
As always, test your apex before publishing it, and follow best practices You dont want unhandled exceptions/errors, or anything to break. To any apex newcomers, be sure to follow good "Error Handling" practices, and "Testing" and follow all the developer guides before attempting apex solutions to avoid scenarios where something fails, now or later, that potentially break your users or processes, or their dependencies. Test before you publish, and consider shipping apex with an on/off etc and recovery plans.
Keep in mind whether the timing of the calculation is flexible within your requirement; you could gain benefits (tradeoffs, really) by using async apex vs/opposed to sync apex. For example a consideration for using synchronous apex is the fact that any exceptions/errors in sync apex are potentially seen on-screen by the user, more often id say than async apex failures are seen. If the calculation can afford to be delayed, it should be, to reduce likelihood/probability that a user sees an error, unless of course its essential to show them any error immediately (ie mission critical to their operation). There is no one right approach, but do study the apex source docs of the specific version # first and foremost. One of many async apex patterns would be in a
future call called appropriately from your trigger framework or that of a managed package. The main logic could perhaps call