Tip on the new “Update Usages” features if you have a “Error” in AppSheet
If you’ve tried using the new “Update Usages” feature and it didn’t work, the issue might not be a bug in AppSheet but rather hidden errors in your app.
When AppSheet detects errors in an application, the “Update Usages” feature won’t execute. This includes not only visible errors in the interface but also underlying errors in bots, which only appear when you run a test in “TEST”.
My Experience
While fixing my app using the New AppSheet Naming Standard Protocol, I found issues like duplicate views, unused virtual columns, and inefficient expressions. I thought that fixing these would make the “Update Uses” feature work, but it still didn’t.
I then decided to check the bots and found errors in actions of type “Run an action on a set of rows”. Even though the actions seemed to execute correctly, during the “TEST” run, the app couldn’t find the primary ID. This was considered an error, even though no error message appeared.
Solution for my case
Let me give you an example. In an action of the type “execute an action on a set of rows,” the actions are executed from one table to another table, and we must choose an execution range. If we test the process many times in the bot, it works perfectly, even if the action’s execution condition is “true.” But the reality is that for AppSheet, if those cells on which we are applying the action do not exist, although the process works and, if it does not detect rows, it will do nothing, the particular action will give an error since it cannot find the id(s) on which to apply it. In those cases, it doesn’t hurt to add the action condition ISNOTBLANK({list of rows on which the action is executed}). This forces the testing of the action in the bot to be successful because the action is not executed if the list of rows on which it should be executed is empty.
Another example is when we add a row from one table to another table that is not managed manually, through an action. This, apparently (and I say apparently because it is simply an observation), does not work as an “initial value.” When the column we are adding appears in the database as “required” and this is added by action, it could generate errors because it is a value that is not being loaded. Then it will say “a required value has not been added” or something like that. It is solved by removing the “required” condition.
Small warnings that are not seen because the app does not show them as an error but can generate problems when using this “Update Usages” function.
I hope this explanation is helpful, and I really appreciate that you were the only one who replied to this post. You’re a great teammate! While I haven’t explained all the possible errors, the important thing is to be clear that if an error exists, it’s likely that new functions won’t run correctly.
Results
After fixing these hidden errors, the “Update Uses” feature worked perfectly. Renaming columns is now a truly satisfying experience—what we used to do manually now happens in seconds, without human error!
Final Thoughts
Some developers might think this feature is buggy and that (as it’s a new feature) the team is working on it, but in reality, the problem is due to hidden bugs in the bots. If you plan to use “Update Uses,” make sure your app is free of bugs, including those that only appear in “TEST.”
Hope this tip saves you time and headaches. Happy developing in AppSheet! 
