1. Confirm the Action Trigger Timing
Since you're using an "Add a row to another table using values from this row" action triggered after form save, AppSheet runs the action after the data is validated and saved. However, some expressions or conditions in the action (or its Referenced Table or Referenced Action) might still reference ColumnX.
What to do:
Double-check each expression in the action, especially:
In the Action definition for TableB.
Any expression used in setting values for the new row.
Any "Only if this condition is true" logic.
Use AppSheet Monitor (in app editor -> Manage -> Monitor) to see exactly where the action fails.
2. Analyze Dependencies (Is ColumnX Referenced Indirectly?)
Even if ColumnX isn't directly used in the action, it might still be:
Referenced in a dependent column that is used.
Involved in valid_if or initial value formulas for columns in TableB.
What to do:
Review each column used in the action for TableB and their formulas.
Check if any of those formulas call a virtual column or field that references ColumnX from TableA.
Also check if any App formulas reference [_THISROW].[ColumnX].
Tip: Use Ctrl + F in Expression Assistant to search for ColumnX.
3. Examine ColumnX's "Valid_If" Logic
Even though the data is saved in TableA, ColumnX's Valid_If expression might still cause the error if:
It's context-sensitive (e.g. CONTEXT("View")) and behaves differently when the action runs.
It relies on enum/valid values that arenโt available after the form closes.
It depends on a related value that is not yet available at the time of the action.
What to do:
Wrap your Valid_If expression in a safe context check: IF(CONTEXT("ViewType") = "Form", [YourValidIfLogic], TRUE)
Try disabling the Valid_If temporarily and testing the form + action again.
Check if any dereferences like [RelatedItem].[ColumnX] break during the add process.
4. Use Logs for Precise Error Tracing
The error message should appear in Audit History or the Monitor tool.
What to do:
Go to Manage > Monitor > View App Log.
Filter by the recent failed attempt.
Click into the failed action and inspect:
Which exact column or expression caused it
Whether any field had a #ERROR! before saving to TableB
5. Test with a Minimal Setup (Isolate the Action)
Sometimes the quickest way to debug is to create a simplified test case.
What to do:
Clone your current action.
Create a simplified version that only passes 1-2 fields from TableA to TableB.
Temporarily remove any "Valid_If" from ColumnX.
Save a form and check if the error persists.
If it doesnโt break: gradually reintroduce fields or expressions until the issue reappears โ that tells you where the problem lies.
6. Consider App Formula / Initial Value Behavior
If any column in TableB being added has an App Formula or Initial Value that references [ColumnX], it could cause issues even if itโs not explicitly passed.
What to do:
Check all columns in TableB (especially Virtual Columns or calculated ones).
See if any of them use: LOOKUP([_THISROW].[ColumnX], ...)
If so, wrap with error-safe functions like: IF(ISNOTBLANK([ColumnX]), LOOKUP(...), "")
7. Check for Any Workflow Bots / Events
If a Bot or Workflow is triggered after saving, and the automation refers to ColumnX (or its invalid state), it might trigger the error after the data is saved.
What to do:
Check any Bots, Events, or Processes triggered on Adds to TableA.
Temporarily disable them and test
LinkedIn
Twitter
