WxCC BRE use case for hours of operations?

[david.macias]

I would like to explore if BRE could be used as a DB for hours of operations. However, the lookup needs to have multiple dimension: Schedule name, day of week, and current time. My thinking is that if you can pass those 3 data points to BRE and if it returns data then we're open, otherwise we're closed. This would allow for schedules which open/close in the same day. Unfortunately, I can't tap into an external API, so I'm hoping BRE can make my life easier.

david

[Arunabh Bhattacharjee · Accepted solution]

Hi @david.macias 

Happy belated New Year,

You can use BRE for simple lookups including holiday checks. You can definitely store a string like "Open_Hours" or "Closed_Hours" but the key needs to be unique.

To store multi-dimensional data you can delimit it - say you want to store the EP DN's Open_Hours to go to Queue_Support you can do something like 

1232343456 (key) --> "Open_Hours|0800-1700|Queue_Support|Skill_Service"

Dipping into the DN using the NewPhoneContact.DNIS you can get the entire schedule from BRE.

 For Time of day you would use something like {{ now{} }} 

and then convert the time to say 08:15:00.000Z[UTC] to 0815 and check it against the returned 0800-1700 schedule.

That is possible.

Requires some pebble templated expressions - but will work.

Thing to note is that the BRE is a single Key-->Value pair lookup that needs a unique Key - so using the DN name or Name of the EP to store the schedule might help. OR using a combination of strings that makes the lookup unique.

And them delimit the string with ";" or "|" to store multiple dimensions and split() to retrieve the meta data.

Thanks & Regards,

Arunabh. 

[david.macias]

Happy new year Arunabh! This is exactly what I was thinking. CalendarName_DayOfWeek or BUName for the unique key which would make the need for routing strategies much less. One more question for you. Any thoughts on how to handle multiple open hours? For example, I have a BU that is closed from 800-2000 and opened all other times. One option is to reverse the lookup when it's a lookup for this BU, but it would be nice to have universal hours lookup logic.

david

[Arunabh Bhattacharjee · Accepted solution]

True, the new Business Hours feature does have APIs to be able to create schedules via the GUI or programmatically. So that way you can use the new feature of Business Hours instead to properly define schedules.

For the BRE method, one way is to use a mix of delimiters to make it nested, here is the version of 

. . .

"1232343456": {

"queue": "Queue_Support",

"openHours": ["0000-0200","0800-1200", "1400-1700"]

}

. . .

"1232343456" ---> "Queue_Support|0000-0200;0800-1200;1400-1800"

so you can split("|") for the first set of dimensions 

and then split(";") for the next set and so on.

Since it is a string, it is essentially about parsing the right entities and writing logic for it. 

You can probably also put field identifiers if required with ":"

"1232343456" ---> "queue:Queue_Support|openHours:0000-0200;0800-1200;1400-1800" 

Here you will get the fields in key:value pairs and can split(":") | last OR [index] for the right element.

[david.macias]

I love this approach, thank you! By the way, is the new Business Hours feature still on track for late Jan release?

david

[Arunabh Bhattacharjee]

Yes the general availability of the feature is usually 3-4 weeks after early access of the feature, early access is scheduled for end of next week.
With early access all the partner gold tenants would ideally have this feature available for testing.

If that is on track, with the feedback etc it should be available end of Jan/early Feb for customer orgs.

[david.macias]

That's good to know, is it possible to ask for early access to a customer too? I don't want to get ahead of it, I want our tenant to have it so we can experiment, but ultimately we're going BRE or this feature for our upcoming project and want to ensure all ducks are in a row.

david

[Arunabh Bhattacharjee]

Not yet David - at this point the Early Access phase is beta for partners and other internal tenants to provide feedback just before General Availability to customer orgs. 

Another correction is that Business Hours feature is currently GUI/Flow Designer/Admin persona only - APIs are available but internal, they are not yet exposed for developer personas. They will be exposed later - till then today one would build Business Hours on Webex Control Hub and then invoke those Business Hours via Nodes inside flow - essentially performing the same action we are looking for.

We will maintain those schedules centrally on the business hours UI.

[david.macias]

Arunabh, it is what it is then. Just want to set correct expectations as the project continues. To be clear, do you see the new business hours UI allowing the same functionality we've discussed around BRE? Ultimately, I want to plan where to focus my energy. Do I try to configure all the hours with BRE or use routing strategies today and wait for the new release. I don't expect you to answer the second part, just to tell me if you feel that the release will allow the flexibility BRE will allow.

Thank you!