> For the complete documentation index, see [llms.txt](https://atlas.anywhere.now/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://atlas.anywhere.now/contact-center-configuration/building-your-callflow/via-dialogue-studio/business-hours-and-holidays-nodes.md). # Configure business hours and holidays in Dialogue Studio Configure Business Hours and Holidays nodes in Dialogue Studio for time-based flow routing, separate from UCC opening-hours records. Configure the Business Hours and Holidays nodes in Dialogue Studio to route messages by time and calendar rules. They do not configure the UCC's [Business Hours and Holiday Records](/contact-center-configuration/building-your-callflow/business-hours-and-holidays.md). Use the controls available in your installed node version. Check [Connect and Unify applicability](/set-up-dialogue-cloud-neo/connect-vs-unify.md) before applying related UCC or SharePoint configuration. ## UCC Opening Hours and Flow Routing The nodes do not replace or disable UCC Business Hours or Holidays configured in SharePoint. For normal incoming voice calls, the UCC checks its opening state before starting the Dialogue Studio flow. When the UCC is closed, the call follows UCC closed-state handling instead of reaching the flow. An in-flow node cannot override this check. Exceptions depend on the connect model: * **Connect:** A side-entry endpoint with **Always open** enabled can bypass UCC Business Hours and Holidays. This setting does not override `TemporarilyClosed` or overflow checks. Other routing and flow-entry conditions still apply. Configured outside-hours routing can provide separate exceptions. * **Unify:** The endpoint's **Always open** setting does not bypass the incoming-voice opening-hours check. If the UCC is closed, it plays the configured closed message and ends the call before starting Dialogue Studio. See [Incoming phase](/contact-center-configuration/building-your-callflow/via-dialogue-studio/incoming.md#when-this-phase-runs) for the checks before the incoming trigger runs. ## Select the Time Source Both nodes can evaluate their default input time or a time supplied by a message property, flow context, or global context. The default is labeled **Message timestamp** in Business Hours and **on input of message** in Holidays. Choose the source deliberately. A supplied timestamp lets the flow evaluate that time rather than assuming the current time. Confirm that the supplied value represents the intended instant. Select the timezone explicitly when routing depends on local opening hours or holidays. Business Hours uses **UTC** if its timezone is empty. ## Business Hours Configure **Schedule rules** in the order you want them evaluated. | Control | Behavior | | ----------------------- | ---------------------------------------------------------------------------------------------------------------------- | | **Timezone** | Converts the evaluated time to the timezone used by the schedule. Empty means UTC. | | **Time** | Selects the default message/input time or a property/context value. | | **Schedule rules** | Each schedule rule selects weekdays and a start/end time window for its output. | | **Otherwise** | Optional catch-all fallback. Only one effective Otherwise rule is supported; place it last. | | **Stop on first match** | When enabled, only the first matching rule emits a message. When disabled, matching rules can emit independent copies. | Select at least one day for every schedule rule. Its end time must be strictly later than its start time. Invalid rules prevent deployment. This node does not accept an overnight window as one rule. Split it across the relevant days. Do not copy the UCC schedule-record rule that permits an end time on the next day. Check the Otherwise branch and all wires after adding, removing, or reordering rules. Without Otherwise, a message matching no schedule can be dropped. With Stop on first match disabled, design downstream actions for more than one matching output. ## Holidays Choose **Country**, then the applicable **State** and **Region** if offered. These selections determine the holiday calendar and timezone. If several timezones are offered, select the appropriate one. Configure the Time source separately. Add rules in their intended evaluation order: | Rule or Control | Configuration | | ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Days** | A date range with start/end times. **Repeat yearly** repeats the range each year. | | **Holidays** | Select holiday types: **Public**, **Bank**, **School**, **Optional**, or **Observance**. Optionally narrow to a named holiday. A time window can restrict the match to part of that day. | | **Stop on first match** | Enabled: emit only for the first matching rule. Disabled: matching rules can emit copies independently. | | **No-match output** | The first output is used when no holiday rule matches. Wire it to the normal-day path. | For Days rules, the end date/time must be strictly after the start date/time. For a same-day range or a holiday time window, the end time must be later than the start time. Invalid rules prevent deployment. Changing the country, state, or region can change the available holiday calendar and timezones. Recheck your selections after changing them. ## Validate the Routing Test a normal opening time, a closed time, a matching holiday, and a non-matching date. Include overlapping rules when Stop on first match is disabled. For voice flows, verify both layers separately: UCC opening-hours handling before the flow and node routing after the flow starts. A call stopped by the UCC's closed-state handling does not test the node's closed-hours or holiday output. Verify the chosen timezone and supplied time value. Confirm that unmatched traffic follows the intended fallback, and that multi-output copies cannot trigger duplicate routing actions unintentionally. Return to [Core Nodes](/contact-center-configuration/building-your-callflow/via-dialogue-studio/core-nodes.md) for the routing overview. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://atlas.anywhere.now/contact-center-configuration/building-your-callflow/via-dialogue-studio/business-hours-and-holidays-nodes.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.