With Appointment Booking, is it possible to update a Appointment Booking Service Configuration's time zone mid-flight even with active appointments?Issue User Thaddeus Bottomsworth was looking to update an Appointment Booking Service Configuration's time zone while there were active appointments. Unfortunately, on attempting this, he received an error, "Active appointments found. Before updating the Timezone, clear active appointments affected by the change." This was being blocked by Business Rule "Check active appointments". Thaddeus wanted to know what the risks were of updating the field with active appointments running, if it was possible to do so, and if ServiceNow had any recommendations regarding this process. Release Zurich Resolution ServiceNow Support cannot recommend updating via script on the live configuration while you have active appointments. The current block via the Business Rule substantiates Support's stance. For now, Thaddeus was counseled to leave the current service configuration as-is for appointments already booked against it. It was suggested that Thaddeus could create a new Appointment Booking Service Configuration with time zone = Appointment Location (location), point new catalog/booking traffic at the new config, and let existing appointments finish on the old config. That is the approach KB0953615 documents instead of editing the live record ( ref: KB0953615 ). It was later explained that if Thaddeus absolutely must change the current configuration record, he will need to satisfy the product rule first. In that case, he should start by clearing the active appointments affected by the change (complete them, or cancel/reschedule them onto a config that already uses the desired time zone), then update time zone through the form so the business rule can run. If after reading all of the above Thaddeus and his team still wanted a scripted bypass, it was shared that they could proceed at their own risk. It was also noted that the effort would need to be supported explicitly by their own team, and not ServiceNow Support (since it is customization and formally against Support's recommended path forward). Thaddeus would take the normal steps for customization/implementation, such as: Reproduction and full testing only in sub-prodExplicit comparison of existing appointment UTC vs local start/end before and afterReschedule, cancel, portal calendar, notifications, and new slot generation after the changeNo production change until those results are reviewed The TLDR for Thaddeus and his team is as follows... The risk of updating time zone with active appointments is not documented outright, but official knowledge says do not do it, and the Out of Box (OOB) business rule is the enforcement of that. Scripting around the rule is unsupported. The documented alternative is a new service configuration, or clearing affected active appointments and then changing the field (time zone) normally.