The single most common way an amenity closure silently fails to happen.
Last updated
If you take one thing from this set, take this: linking an amenity and setting the dates does not close anything. The closure sits as Pending until somebody confirms it, and a pending closure is invisible to the booking rules. Residents and staff can carry on booking straight through the window.
Because the tab looks finished. The amenity is listed, the dates are right, the timeline shows the closure. Everything reads as handled. The interface says so directly, warning that the dates are still bookable until you confirm, but the shape of the screen suggests the work is done.
Choosing Confirm Closure runs the conflict check, asks whether to cancel overlapping bookings or only block new ones, and then moves the closure into a state the booking rules actually enforce. Only confirmed and active closures block anything.
Before you consider a job scheduled, reopen the Asset Impact tab and confirm the closure status is not Pending. It takes five seconds and it is the difference between a blocked calendar and a resident standing outside a closed gym holding a confirmation email.
If plans change before you confirm, a pending closure can simply be removed. Nothing was ever enforced, so nothing needs undoing and nobody was told anything.
The closure appears in the timeline with its status. It becomes active over the window, and completes afterwards, at which point the amenity returns to normal. If the work finishes early, revisit the closure rather than leaving an amenity closed for days it does not need to be, which is its own kind of complaint.