EDIT: So I was a little confused - apparently it’s not my old Reports that are broken, but when I clone them, the cloned reports are broken
I have many Reports that use DBs from a Custom Integration (and others).
It seems that if a field that is used by a Report is changed in some way (it’s unknown what kinds of changes can cause this problem), then the Report becomes “broken” because the changed fields are no longer found. I have found no way to fix this problem, once it happens.
Specifically: In my Custom Integration, I changed the list of DBs/Fields that are synced – this appears to have broken all the Reports that reference these DBs.
I deselected some DB’s from the sync for debugging. Later I added all these DBs back to the sync.
But after syncing with all of DBs and fields included, my Reports are now all broken (because of referencing fields that “no longer exist” - even though they do).
Not sure if there is any way to recover/rebuild these Reports that took many, many hours to create.
Or is the only solution to manually re-create all the Reports by hand, from scratch?
And then potentially have the same thing happen again, if some unknown changes are made to the Integration sync parameters? Or something else?
I’ve had the same thing happen to me unfortunately. Recreated everything manually. Reports are extremely powerful but very finicky about fields changing.
Unfortunately, I don’t think there is much that can be done, other than recreating them.
Report views function somewhat like a layer on top of the normal workspace dbs, and their configuration is predicated on a specific db structure. If the structure changes (e.g. field removed) the report has no insight into what happened, and so just breaks.
If a field in a db is deleted and then recreated, then reports do not recognise it as the same field just because it has the same name and data type. It is seen as another field entirely.
Or in the case of a Custom Integration – fields were not “deleted” (from the user’s perspective) but DBs were excluded from sync then re-included, new sync filters were added to the app, and the CI app was “updated”. Do any of these “ordinary” operations result in field IDs changing?
I understand the technical reasons why this could happen, but it is unintuitive that these operations would cause this much damage with no way to undo or restore.
This is too much lost work to just say “there are various things that can do this” . Without fully understanding the risk factors, Reports are too fragile to warrant investing serious time into creating, which makes the Reporting system useless.
Which operations or changes on a Custom Integration (or anything else) have the potential to break Reports (or anything else) in a way that cannot be undone?
I just tested out the case with Excluding/Including DBs in integration configuration and seems like it shouldn’t lead to report corruption.
But excluding fields from integration and re-adding them back will definitely corrupt reports as we re-create fields.
Is there a chance that schema of your custom integration app was changed? It can also result in fields re-creation if you change some ids of fields for example
BUT there are many relation fields to other DBs which were excluded from sync, then later re-included.
only those excluded fields would get broken. If ALL were corrupted then I guess it’s global change, like changed schema or app re-configuration.
Btw, is it something you can easily reproduce? Is there a chance you can create some test reports and retry some steps from your list?
And can you share the piece of code that derives field ids from zoho?
. Without fully understanding the risk factors, Reports are too fragile to warrant investing serious time into creating, which makes the Reporting system useless.
