Grouped Action deleting some column values

[Lindsey_Lindow]

I apologize for the long post, but this is an odd one, so I'm trying to be as thorough as possible:

Intermittently, after firing a Grouped Action, it works as intended (at first), but then immediately deletes some column values.  The issue cannot be reproduced on-demand, so I contacted support and couldn't get a definitive answer. Eventually they stopped responding all together, so I hope someone has experienced something similar and can point me in the right direction.

My app is used for progress tracking and payroll in an auto shop that details and photographs vehicles for dealership websites.  The detailers are paid a fixed amount for every vehicle they clean, and after cars are detailed, they're assigned to a photographer, who is paid a fixed amount for each vehicle photographed.

The shop manager adds a row for each vehicle to table named CAR LOG.  App users only need to input their User ID and update the status when complete, then payroll logging SHOULD happen in the background as part of a Grouped Action named COMPLETE & SEND TO PAYROLL:

1. Action-A:  "Data: set the values of some columns in this row"
   • sets the value of [STATUS] to "Complete"
2. Action-B:  "Data: add a new row to another table using values from this row"
   • adds a row to table named PAYROLL LOG using values from [DATE], [MAKE], [MODEL], [COLOR], [VIN], [USER ID]

In order to prevent users from claiming the same vehicles multiple times on payroll, the Grouped Action is only available if:

• AND(ISNOTBLANK([USER ID]), [STATUS] <> "COMPLETE")

I check the backend spreadsheet daily and intermittently, a duplicate is present in the PAYROLL LOG table.  When this occurs, I locate the corresponding row in the CAR LOG table to view the edit history and find that immediately after [STATUS] was set to "Complete", the value gets deleted.  App users see that the status is not showing complete, so they perceive it as a failed sync and invoke the Action again, resulting in a duplicate row on the PAYROLL LOG table.  Additionally, when this occurs, the values are also deleted from [USER ID], [EMPLOYEE NAME] and [CHANGE TIMESTAMP].

[Suvrutt_Gurjar]

Such issues could be due to several reasons and could need deeper analysis, so suggesting the below just based on shared information.

1. Instead of applying the condition to the grouped action, you could possibly apply it to the action Action-A -  AND(ISNOTBLANK([USER ID]), [STATUS] <> "COMPLETE") 
2. For the Action-B,  you could possibly try [STATUS]="COMPLETE" as condition?

The above is not tested.

[Steve]

---

@Lindsey_Lindow wrote:

Intermittently, after firing a Grouped Action, it works as intended (at first), but then immediately deletes some column values.  The issue cannot be reproduced on-demand, so I contacted support and couldn't get a definitive answer. Eventually they stopped responding all together, so I hope someone has experienced something similar and can point me in the right direction.

---

In my experience, a common cause for this behavior is the use of an action to add a new row, but the new row's key column is the same as that of an existing row, so the new row replaces the existing row, possibly clearing column values that the old row had but the new row doesn't.

Another possibility is that you have bots that are being triggered by these changes.

I've escalated your experience with Support internally. Can't say it'll help, but it's something I can do.

[Lindsey_Lindow]

Thank you for responding to my post.  There are times when the same vehicles are sent to us again (example: cars that get covered in bird droppings while sitting on the sales lot).  For this reason, I knew using vehicles' VIN as the key would not be wise, so I made a dedicated key column with UNIQUEID() to set the value as new rows are added, so I'm hoping a duplicate key value won't occur.  Also, the only two bots I have are both currently disabled.  I'm sure that readily being able to reproduce the issue would be helpful in finding the source of the problem, but it's very intermittent. The backend spreadsheet currently has 1057 rows and the issue has only occurred on 12 of them.

[Lindsey_Lindow]

In regards to your experience of a common cause being the use of an action to add new rows, I assume the same would apply if a bot performs the action instead of the user?

[Steve]

Correct.