Best practice for modeling Merchant business hours in CSM

[luishuallpa]

Hi Community,

I'm looking for guidance on the recommended design approach for modeling Merchant business hours in ServiceNow.

Use case
In our implementation, a Merchant is represented as an Account. Each Merchant corresponds to a single physical location, for example:

A 7-Eleven store
A Walmart store
A KFC restaurant
A small neighborhood convenience store or local grocery shop
Each Merchant has one or more POS devices installed, and field technicians may need to visit the site to perform maintenance or resolve incidents.

One of our requirements is to store the Merchant's business hours so technicians can easily identify when the location is open before scheduling or performing an onsite visit.

The challenge is that business hours can vary significantly depending on the type of Merchant. Large retail chains may have standardized schedules, while small neighborhood stores often have unique operating hours, different days of operation, or multiple business hour intervals throughout the day.

Some examples include:

Monday–Friday: 08:00–18:00
Monday–Saturday: 09:00–18:00
Monday–Sunday: 10:00–22:00
Monday–Friday: 08:00–12:00 and 14:00–18:00
Monday–Friday: 08:00–18:00, Saturday: 09:00–13:00
Tuesday–Sunday: 07:00–16:00
24x7
Future considerations
At the moment, the business hours are mainly intended to be displayed to field technicians (they use a 3rd party software integrated to SN). However, we may eventually need to:

Validate that onsite visits are scheduled within the Merchant's business hours.
Determine whether a Merchant is currently open or closed.
Use the Merchant's business hours as part of SLA calculations or business rules.
My question
What would be the recommended design approach for this scenario?

I'm considering several options:

Add a reference field on Account pointing to cmn_schedule.
Create custom fields on Account (days of the week + start/end time).
Use another OOTB capability (such as Business Calendar or another standard model) that is intended for this type of requirement.
Has anyone implemented a similar requirement?

If so, what approach did you choose, and what are the pros and cons of your design?

My goal is to follow ServiceNow best practices while keeping the solution scalable for future requirements such as SLA calculations, visit scheduling, and other business processes that may depend on the Merchant's business hours.

Thanks in advance for your recommendations!

[Vikram Reddy]

Hello I would strategize it in this way,

1. Add a reference field on Account pointing to cmn_schedule (your first option), rather than a field on cmn_location, since in your model one Merchant equals one Account equals one physical site. If you later support multi-location merchants, that's when the reference would move down to Location instead.
2. Don't create one schedule per Account. Build a small library of shared schedules for the common patterns (Mon-Fri 08:00-18:00, Mon-Sat 09:00-18:00, 24x7, etc.) and point every Merchant that matches onto the shared record. Only build one-off schedules for the small independent stores with genuinely unique hours. This keeps cmn_schedule from ballooning into thousands of near-duplicate records.
3. For "is the Merchant open now" or validating a proposed visit window, use the server-side GlideSchedule API (GlideSchedule.isInSchedule(GlideDateTime)) against the Account's schedule rather than writing your own date-range comparisons.
4. When you get to SLA calculations, the same cmn_schedule record can be dropped straight into the SLA definition's Schedule field so breach math counts only business hours as covered 

IMPORTANT: GlideSchedule.isInSchedule can behave unexpectedly when a schedule has a parent/child schedule chained onto it, or when you rely heavily on Excluded-type entries. Keep your Merchant schedules flat (no parent schedules) unless you have a specific reason to layer them, and test isInSchedule against real dates before you build any SLA or validation logic on top of it.

Thank you,
Vikram Karety
Octigo Solutions INC