My check-in entry disappeared after editing
You open a submitted check-in, change an answer, save, and part or all of your entry looks gone. This matches known behavior tied to how edits are merged in certain time windows: rapid saves, cross-device edits, or edits close to report compilation can drop fields or overwrite them with empty state. Engineering tracks this class of issues under the CORE workstream; the guidance below reduces data loss while fixes roll out.
Quick check
- Avoid back-to-back saves — Wait for a clear “saved” confirmation before closing the tab or switching devices.
- Edit from one device — Finish the edit on the same browser or app session you started; do not interleave mobile and desktop while the spinner is active.
- Copy long answers first — Paste into a scratch note before major rewrites so you can restore text if the UI returns blank.
- Stay outside compile windows — If your team posts a rollup at a fixed time, avoid editing in the few minutes before and after that moment.
- Screenshot before risky edits — For blocker or metric fields, capture the prior state if leadership relies on it.
Common causes and fixes
Known behavior: edits inside sensitive time windows
Under some conditions, saving an edit replaces the stored response with a partial payload. The UI may show empty blocks even though you typed content. This is more likely when the edit happens immediately after submit, when multiple tabs are open, or when automation reads the response at the same moment you save. We classify this as a CORE-related bug and prioritize fixes that make merges idempotent.
Workaround: After any edit, re-read each required field before you leave the page. If something cleared, re-type from your scratch copy, then save once. If blockers or structured fields exist, set them again after text edits (same pattern as Editing my check-in is deleting my blockers).
Client cache or stale form state
Your browser may show an old version of the form while the server already rotated to a new template. Hard refresh the Dailybot web page, reopen the check-in from the link in chat, and verify whether the data returns. If it does, the loss was display-only. If it does not, continue with recovery steps below.
Template or question changes during your edit
If an admin publishes new questions while you edit, the save path can map answers incorrectly. Ask whether a template change went live. You may need to submit a fresh response against the new question IDs. Owners should avoid publishing template changes during active response windows when possible.
Accidental delete or blank overwrite
Sometimes the issue is a blank field saved on top of good content. Use undo in the field if still focused, or restore from your scratch copy. If the check-in allows multiple submissions per period, you can add a follow-up message in thread noting the correction.
If none of this worked
Before contacting support, gather:
- Check-in name and approximate time of the edit (with timezone)
- Whether the loss affected free text, blockers, or attachments
- Device and browser (or mobile app) used
- Whether anyone else edited the same response (managers sometimes adjust answers)
- Screenshots of the empty state and any error toast
- Steps you already tried from this article
We use these details to correlate with CORE tickets and may be able to restore from server logs in some cases.
Then contact Dailybot support from the Help or Contact options in the product or on the website.