Hi friends.
Sometimes, we need/want to change a field name, which can cause breaking changes to automation, dependent formulas, etc.
It would be great to see the dependencies of a specific field so that we can determine what relies on the field we intend to modify.
Field renaming should not break anything.
Few exceptions:
Apologies, youâre right. The exception is if the field is deleted, which affects Lookups and Formulas.
As for scripting, I presume Fibery cannot determine if a field is used in a script.
We thought about the same thing.
We experiment a lot with various Databases setups and weâd need some way of doing cleanup (otherwise junk would keep piling up).
If we were to delete a Database it would help to know which other entities and/or databases relate to it.
The relation map on the db config page shows all related dbs.
Or you can check out the workspace map of youâre an admin.
Sure, but I can have a People DB with relation to a Car DB, but no People entity that has an actual relationship to a Car entity.
Meaning that I could safely delete the Car DB even though the workspace map might suggest otherwise.
How often are you deleting databases though?
My experience is that most users settle on a set of databases fairly early on, and database deletion doesnât happen very often.
The choice of what databases to have is a schema decision - either you want to store Car data or not.
If you are planning on deleting the Car DB, why would it matter if there were some Car entities linked to some People entities?
If you think the Car db isnât needed, then it surely doesnât matter what the Car entities might be linked to⌠
Right now we have a Sandbox space where various people in the team can add DB and experiment, so itâs hard to know what connects to what and what is still needed or what is obsolete, junk.
The issue is not with the scheme but knowing âif I rip this thing out of here for cleanup purposes, will it mess things up for someone else who might be needing it?â
That being said, itâs a niche need for us, and add the end of the day we can go in, check entities manually (based on the DB relartionships) and see if any entities make use of that relationship and if not safely delete it
Fair enough. But isnât that the purpose (and risk) of a sandbox - you play around, and things might get broken (especially if others are also doing stuff)? 
For us, itâs more about deleting fields, not databases.
Fair enough. But isnât that the purpose (and risk) of a sandbox - you play around, and things might get broken (especially if others are also doing stuff)?
Yes, until someone says: âyup, this is good, letâs make use of itâ which would take it from âexperimentâ to âliveâ and move those DBs to a dedicated space
Yep, and this FR is all about that, and we do hope to make field deletion a less traumatic process.
In addition to this:
Currently you donât receive a notification when an automation rule uses a deleted field. Or when the automation is broken because of a relation change (1:1 â 1:m or m:m).
You will only receive the notification when the automation actually runs. But some only run once in a while.
For us, as a Fibery partner, this is a pain in the ass. Since we currently donât know which automations are broken.
Would be great if we can have the same solution as we now have in formulas and lookups. When a field is deleted, we receive the error immediately in the inbox.
Agreed. Ideally, when deleting a field, we can see Automations, Lookups and Formulas that depend on the fields before confirming deletion. That way, you can prevent or prepare for deletion.
