The Case for Basic Scheduling Limits

What I mean by Scheduling Limits: straightforward and reliable methods to control when users (and/or their users) can schedule and edit “events.” The most commonplace example of limits is disallowing scheduling in the past.

Setting start date must be after now conditions and relying on a post date/time selection rich text error message is a janky workaround. Especially if that validation is processed in GS with lag.

Scheduling limits would set the window available for scheduling through use of a date/time or event picker. A built-in option that’s checked/unchecked, not achieved through a labyrinth of filters and ITE columns.

Example UI: Attempting to schedule a zoom call for yesterday, today. Dates in the past revert back to present day.


In the context of Task List type apps, this isn’t critical. Most apps rely on visual - grey out - cues to signal a date/time has passed but that the user can add past tasks.

On the other hand, for booking and scheduling apps, free-range pickers are problematic.

To be clear, the recently introduced event picker is an enhancement over the traditional date/time component. It combines two steps into one, makes it possible to worry less about end dates preceding start dates, end dates and start dates on different calendar days, and more.

Yet, the bulk of scheduling limits made possible via sheet formulas and Glide columns are here to stay, and so is the lag.

Two things would be a welcome improvement to the event picker:

1. An on/off mechanism to limit scheduling. Perhaps the default is free-range with the option ☐ allow past events

2. Clearing previous dates in pickers. We can’t reset user-specific columns but is the option to increment date type ones to a null value a possibility?

Because I’d love to pitch a viable booking “experience” that doesn’t look like this:




And I’m still having some troubles with relations to recognize the date-time format…

1 Like

It’s now added to the feature request app.

1 Like