Table expired before everyone responded
You planned a poll, signup sheet, or data collection table, but the deadline arrived while people were still out on PTO or in meetings. Expiration is intentional: it freezes the dataset for reporting. You still have options to extend deadlines, reopen windows, or clone the table for stragglers without losing what you already collected.
Quick check
- Current schedule — Open the table settings and read the exact close time and timezone; compare to participant timezones.
- Owner rights — Only owners or admins can change lifecycle settings.
- Data lock — Decide whether you need to preserve the original snapshot for compliance before reopening.
- Communication — Tell the team after you extend so they retry immediately; stale browser tabs may cache “closed” state.
- Backup — Export or screenshot critical results before major changes if export is available.
Common causes and fixes
How expiration works
Tables typically combine a calendar end datetime with optional “no new rows after” rules. When the clock passes, the API rejects creates/updates that are not owner-level edits. Scheduled reminders tied to the table may also stop. Timezone on the owner’s account usually anchors the deadline unless you overrode per-table.
Extending the deadline
Move the close time forward in settings, save, and verify the banner or status chip updates to “open.” If the UI blocks edits on closed tables, duplicate the table, copy invite links, and retire the old one. Clearly name the new link so analytics stay understandable.
Re-opening after accidental early close
If someone closed early, reopen only if your policy allows mutating frozen data. Some orgs require audit trails; in those cases duplicate instead of reopening. Document the change in your internal change log.
Partial responses
Export current rows, then extend so late responders append without overwriting earlier answers. Warn participants not to delete others’ entries if row-level delete is permitted.
Ties to check-in schedules
Sometimes tables piggyback on check-in timing; shifting the check-in without shifting the table causes mismatched expectations. Align both schedules or decouple them explicitly.
If none of this worked
Before contacting support, gather:
- Table name and owner email
- Original and desired deadline with timezone
- Whether any export is required for compliance
- Whether you need historical immutability
- Screenshots of settings panels (redact sensitive columns)
- Steps you already tried from this article
Then contact Dailybot support from the Help or Contact options in the product or on the website.