Hi,
I'm having an "Action failed ColumnX: This entry is invalid" that doesn't make sense to me.
I've a form from "TableA" that triggers an action when is saved. This action is "Data: add a new row to another table using values from this row" to add data to TableB. However, everytime i save this form, it shows me that Action failed for a ColumnX from TableA is invalid.
Problem is:
Hope someone can help me on this one
And thanks in regards
Solved! Go to Solution.
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
@Bioingeniería wrote:
- I'm not using this ColumnX data for this action.
- ColumnX indeed has "valid if" function, but data in it is actually valid so idk why it says is not.
These seem to conflict, you say Column X is not used but then say the data in the column is valid??
Bottom line, when adding a row to a table in an action, that row is subjected to all of the column definitions just as if it was being inserted into a Form View. If a column not set in the action, I think you would normally see the Invalid message because an Initial Value was set and didn't meet the Valid_If criteria in some way - OR - the Valid_If doesn't allow it to be empty.
To say for sure we would need to see how Column X has been configured showing all the properties set.
Sure. ColumnX is a EnumList refered to a Table. Valif if returns a list for the user to select. It is like this:
SELECT(
Inventario Existente[Id_Inventario],
AND(
[Traslacion]="En Almacén",
[Ultimo_Almacen]=[_THISROW].[Almacen_Salida],
NOT([Programado_Traslado])
)
)
This column is required. So user has to select one or more options from this list. Once form is saved, form by itself shows no errors, just the action i mentioned before.
I checked if this form doesn't show any error when there is no event actions called after, and everything works fine.
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
Thank you so much, i followed every step and find the problem. Didn't know why it was not working the way it was tho, so I'd to change the way function was written.
However, I tried to trace errors on audit log but there wasn't any log of it. As far I've experienced with other apps I made, there are never logs from Actions errors, only for bots. Do i have to turn on something on configuration?
Like this one, there is trace for the form saved but nothing after (Action failure).
You're absolutely right — and great job digging in and trying different approaches.
Let’s break this down and clarify everything based on your follow-up:
Issue Summary
You had an action like “Add a new row to another table using values from this row”.
It failed with "ColumnX: This entry is invalid", even though the form saved and the column wasn’t used in the action.
You couldn't find any error logs in the Audit Log for this.
1. Why Audit Logs Didn’t Show the Action Error
You're correct: AppSheet's audit log generally only logs errors from:
Bots (automation)
API calls
Data syncs
BUT: regular Actions triggered by "Form Saved" do not consistently show up in logs unless:
They're part of a Bot process, OR
They cause the entire sync to fail.
> Solution: If you want visibility, consider wrapping your action in a Bot that triggers on “Adds to TableA” instead of relying on the “Form Saved” setting. Then errors will show in Monitor > Automation > Execution history.
2. Why Action Failed Despite “ColumnX” Not Being Used
This is a subtle AppSheet behavior. Even if ColumnX is not used in the target action, it may still be evaluated if:
It's Required and has a Valid_If formula.
It’s referenced indirectly (e.g. in a FILTER() or LOOKUP() elsewhere).
It's used in a Form Saved Event — AppSheet sometimes re-evaluates row constraints when the form closes and triggers actions.
> Fixes to try:
Temporarily remove the Valid_If on ColumnX and test again.
Add ISNOTBLANK([ColumnX]) to a visibility condition or change Valid_If logic to make it fail-safe.
Consider making ColumnX not required during testing.
3. Best Practice: Bot Instead of Action Trigger on Form Save
To get full control and logging:
Create a Bot that runs when a new row is added to TableA.
In that Bot, use your “Add row to TableB” action.Monitor errors from Automation > Monitoring > Execution history.
User | Count |
---|---|
18 | |
9 | |
8 | |
5 | |
5 |