PROBLEM: QM report area ratings and photos disappearing¶
We’ve had a problem occur at least twice (three times, I think) where one of our supervisors definitely submitted a QM report (complete with ratings, comments and photos for all areas), and then the ratings, comments and photos subsequently disappear.
We know they completed this information originally, because we can see it in snapshots from the day the report was submitted. And also, in a couple of cases, the cleaner in question was able to see the information.
In at least two of these cases, the original records in the ‘QM report line items’ table disappeared, and were replaced by entirely new records (with new record IDs).
This leads me to believe that the problem is probably something to do with how we’re auto-creating the QM reports and QM report line items.
For example, when Josh returned from his long Christmas break in early 2026, he marked approx 100 QM tasks as “Disrupted”, all in quick succession. This placed them all in the view that triggers the automation that creates the next QM task in the series. But because there were 100+ tasks in the view, the automation failed. As a result, Josh couldn’t see any tasks beyond Feb 19 (see BMS-352 - Josh can't see any tasks after Feb 19 Done ).
We fixed the problem that caused this particular automation to fail, but in the cleanup, I discovered a bunch of his QM tasks hadn’t been created, or had been created with the wrong dates (or something like that - I don’t remember exactly). To fix this, I had to do some database and automation hacking to recreate all the necessary tasks. When you do this, the system automatically creates the linked QM reports and QM report line items. I may also have deleted some of the old tasks, which appeared to be dodgy and perhaps they weren’t. And I believe if you delete QM tasks, the system automtically deletes the associated QM reports and QM report line items.
I think this is what caused the problem. The original reports were simply deleted, and what we see later (with no ratings or photos) are the automatically created ‘replacement’ report line items.
To avoid this in future…¶
If I’m right about the above, we can avoid this in the future by being VERY careful with the deletion of old tasks and the creation of new ones.
UPDATE¶
This was not the problem. All of the reports in question were submitted AFTER my database/automation hacking. So it must just be an inherent problem in the automation of the tasks and their reports.
In writing this summary of the problem, I discovered that I did my database/automation hacking a week before Josh submitted those QM reports. So it couldn't have been my hacking that caused the problem.
This is even more concerning, because now I don't have any idea what caused it.
The weird thing is the QM report records are all the same records (with the same record IDs) but the QM report line items (for each area) are different records (with different record IDs). If the problem were that the tasks were deleted and recreated, the QM report records would have been recreated too, so they would have had different record IDs. But it's only the QM report line items that have different record IDs.
This is disturbing because both QM reports and QM report line items are created by the same script. I got Claude to examine the script, and asked it if there is ever a situation in which it might create the QM report line items and not the QM reports. It said no.
So I don't know how we would have ended up with different QM report line items linked to the original QM reports. As far as I can tell by looking at Jira, and remember, I haven't worked on anything that could possibly have impacted this stuff.
What I do believe is that Josh has done nothing wrong. I actually suspect it's an Airtable issue. I suspect they've had some data loss problems (lost some QM report line item records) and they've automatically replaced them with backups from earlier, which had most of the same field values, but (importantly) not the photos or ratings. This would explain the different record ID.
Why they'd do this, I don't know. And proving it would be difficult and not worth our time.
All up, it's just one more reason to get out of Airtable!