Actions and Workflows: Some clarification on Order of Processing and Data Updates available when

I understand that an Action can cause a change that triggers a Workflow. This is useful when attaching an Action to a button or on form Save.

But what about if the Action is a group of Actions? Should I expect that grouped action to finish before any Workflows are triggered? Or are Workflows triggered as soon as any Action is completed that made a change, regardless if in a group?

For example, if I have Action1 and Action2 in a group. Action1 sets a flag which will trigger Workflow1. Will Workflow1 fire as soon as Action 1 is complete or will it wait until the entire group has finished?

Data Updates Available

I also understand that when a Workflow is executed it has available to it the state of the data at the time it fires. In the example above, I assume Workflow1 will fire as soon as Action 1 completes. If so, thjis probably means that the data changes made in Action 2 are not available for the Workflow1 processing. Correct?

Additionally, when Workflow1 is executing, will data updates during each step be made available for subsequent steps. In other words, If the Workflow has 3 Action steps, will data changes made in Action Step 1 be available for use or inspection in Action Step 3?

I believe we need @Phil here with the exact answer.

1 Like

Hi John,

Event triggered workflow rules are always triggered by the arrival of an Add, Update, or Delete request from the client. When the Add, Update, or Delete request arrives at the server we apply the Add, Update, or Delete to the target table. We then invoke the appropriate workflow rule or rules.

An Action performed by the client may results in one or more Add, Update, or Delete request to the server. When the client submits the resulting Add, Update, Or Delete requests to the server, the appropriate workflow rules are triggered by the server. The workflow rules see the updates resulting from the Add, Update, or Delete request that triggered them.

As you said, the workflow rule only sees the data as of the current Add, Update, or Delete request. It has no knowledge of pending Actions and their consequent Add, Update, or Delete requests that may be queued at the client but have not yet been sent to the server.

The answer to your question then depends on how the client processes the client Actions and what Add, Update, or Delete requests the client sends to the server in response to those actions. @Adam is the expert on that.


@Adam When you get a moment could I get your feedback. I’m confused on some things I thought I knew. I’ll try to distill them down to yes/no questions so it should be quick for you.

I think I have the answer to my first question - A workflow WILL trigger as soon as a row is saved. No waiting for grouped Actions to complete.

Other questions:

  1. Will an Action in step 3 of a Workflow, “see” updates made by an Action in Step 1 of the same Workflow?

  2. Same question but for Grouped Actions, will the Third Action in the group “see” changes made by the First Action in the group?

  3. Do Grouped Actions truly operate in sequence? i.e. Action 2 waits for Action 1 to complete, Action 3 waits on Action 2, etc

Hi John,

Maybe I misunderstood your original question.

Some types of actions are performed by the client entirely on the client device. Some types of actions are performed by the server while processing workflow rules.

I thought you were asking about actions performed by the client and when the results of those client actions were sent to the server as an Add, Update, or Delete request. That is why I asked Adam to weigh in.

Based on the three questions you posed just above, it appears you are asking about actions performed by the server. If so, the answer to all three questions is yes. Server actions are performed in order and each action should see the results of previous actions. It is possible that there are bugs that prevent this, but that is the intent.

I say this with some trepidation because the performance implications of writing and re-reading the data after every individual update performed by an action can mean that the actions are very inefficient. When an action causes a change to any value in a worksheet, the worksheet formulas in that worksheet can alter the values of other worksheet cells. As a result we need to write and re-read the worksheet after an action modifies any data value. These repeated writes and reads can be extremely time consuming.

1 Like

How do I know if an Action is run client side or server side? I mean I know some must run server side. But let’s use an example of a Grouped Action. Does it run client, server, or does it depend on the Actions?

Based on your answer of “Yes” to my questions, I am seeing some behavior that doesn’t seem to align. I built a Grouped Action activated by a button where the first Action set a flag. The third step should have made additional updates but behaved as if the flag was not set.

I switched to using a single Action to set the flag and then triggered a Workflow executing the remaining Actions from the Workflow and it all processed as expected.

Something is amiss based on your response so I’ll open a Bug for it.

If it’s run as part of a workflow, it’s definitely server-side; otherwise it’s generally client-side (the likely exceptions being SMS, email, and file generation, which likely interact with servers; can those even be run outside of workflows?).

From earlier:

The workflow triggers when the row arrives on the server. If you have a grouped action that runs on the device, it will complete entirely before the server ever sees anything the grouped action did.

Rows are sent to the server during a sync, which can be passive (in the background, reflected by the numbers in the upper-right corner of the screen counting down) or active (e.g., by pressing the sync button). Rows are sent to the server in the order they were modified from the device. Multiple separate changes to the same row will result in multiple rows sent to the server, each reflecting a separate change.

To be clear, actions are synchronous, meaning the app waits for one to finish before moving on to the next one. They are executed in order.

Syncing can be synchronous (active) or asynchronous (background/passive).

1 Like

@Steve thanks for the great information. This is really useful as I get deeper into AppSheet capabilities.

I am fairly certain I observed behavior contrary to your statement above just this past week. I had a Grouped Action where the first step was setting a flag. A Workflow triggered off of that flag change and was processing before the Grouped Action had fully completed. I guess the question now is what is the expected behavior?

I’ll re-confirm my observation, maybe in a small test app, and then if needed can submit a bug.

1 Like

Steve is right.

All actions, including Grouped Actions, are always triggered by something. The Grouped Actions are performed where they are triggered.

Workflow rules only run on the server. If a workflow rule invokes a Grouped Action, that action is performed on the server.

If a Grouped Action is triggered on the client, by a button click for example, the Grouped Action is performed on the client. The grouped action on the client may perform data changes that result in adds, updates, or deletes.

When the client sends those adds, updates, or deletes to the server, the changes are applied to the tables. Those changes may trigger workflow rules. Those workflow rules may invoke server-side Grouped Actions that you configured as part of the workflow rule. Those Grouped Actions are performed on the server.

In short, the Grouped Actions are performed where they are triggered. That may be either the client or server.


I understand everything you have said it all makes sense.

Where there seems to be a discrepancy is if a Grouped Action fully completes before any Workflows are triggered by adds, updates, deletes made within the Group.

In Steve’s quoted comment in my last post, I understood him to say that because a grouped action is activated by the client, it will complete fully before any Workflows are triggered on the server.

That wasn’t my observation. I had a Grouped action with 4, lets call them “steps”. The first step set a flag, changed from null to TRUE. A Workflow triggers when detecting that this flag changes from NOT TRUE to TRUE. I was finding that the Workflow triggered before steps 2-4 had completed in the Grouped Action. I simply presumed that the changes from the Group were being sent the server as soon as they were made and not sent in a batch.

However, I am now realizing that my tests were done in the editor. Could it be handling the client vs server side states differently than an actual mobile device? I’ll try tests on the device as well.

So, what is your understanding of how Grouped Actions submit changes? Are they submitted as soon as made? Or would they be held in a batch and sent together?

1 Like

Hi John,

I know how the server performs Grouped Actions when processing a workflow rule. That is what I explained above.

I am not sure how the client performs Grouped Actions. @Adam is the expert on how the client behaves.

1 Like

That’s contrary to my own experience and understanding. A workflow isn’t triggered until the updated row reaches the server. In my experience, client-updated rows aren’t sent to the server while the client is still performing actions.

Can you provide more details on the set of actions and workflows that exhibited the behavior you’re describing?

1 Like

@Steve @Phil Actually I’m going to create an app dedicated to testing what we are discussing. Probably today but at least by tomorrow.

I have been performing a LOT of testing this past week on Actions and Workflows to make sure data numbers are being updated as expected. A lot of moving parts. I have encountered a couple of bugs (one Phil has fixed -Thank YOU!! - tho other I’ll be submitting after recreating in a test app), so it could very well be that I have just gotten myself turned around and confused.

Since the consensus from the two of you is different than what I thought I saw, I’d rather re-visit and re-test and report back with concrete info - either way - instead of spending any more time chasing down a rabbit hole that was based on mis-information.

By the way, I really do appreciate the time you two (as well as a few others such as @Aleksi and @MultiTech_Visions) have put in to discuss the issues/observations I have raised this week. It helps a lot and I think, helps create a stronger AppSheet platform through the community which benefits us all on the platform. Thank you!!


I created a test app to understand more of what’s happening. I started writing this up in detail but was getting long. I’ll keep in short. Let me know if the below is what you expect.

I created a Grouped Action activated by a button. There are 4 actions each which update a time in a column. The first action sets a flag that triggers a Workflow that makes a 5th Time update.

When the action, runs, the 4 row updates are sent to the server. However, when the first row update is written, that also sets the flag, The Workflow is triggered and its update is written BEFORE the other 3 updates from the Grouped Action are processed. For example the order and Time updates from a test are as follows:

Order       Column            Time
--------    -----------     ----------
  1          Action1         14:05:38
  2          Workflow1       14:05:51
  3          Action2         14:05:38
  4          Action3         14:05:38
  5          Action4         14:05:38

So Yes the Grouped Action completes before being sent to the server but once on the server, the order in which the updates are applied to the data source are a little unexpected.

Its not a big deal. For me personally and I guess anyone else, its just a matter of understanding how things work to avoid wrong assumptions.

thanks for writing this up, I have been going a little crazy trying to explain what is going on in my app. we have a shopping cart for internal supply orders similar to the example app Order Capture. this uses a parent/child relationship to enter customer + order info in the parent table and individual products + quantities in the child table. it creates kind of a nested set of forms to complete and the end result is you get a set of actions all synced in order after you hit save on the parent table form. first it syncs the row from the parent table, then each child table row individually until complete.

I know this is happening because we created a workflow to send an email triggered by the parent table getting add/updated that would give us order information. it produces the client info and order # correctly, but the list of products is always blank.

when i created a second workflow that instead is triggered by the child table getting add/updated, this returns each product order properly, we just end up with 1 email per product.

with both workflows active, we get the workflow email from the parent table first, then each child table email!

I’m stuck trying to figure out how to either delay sending the parent table workflow email until all records are written or can i force the records to be written in a different order so parent table is written last?

See Sending Email Only After Adding a Parent Record and All of Its Children here:

1 Like

thank you Steve, as always you are very helpful. i will give this a try.

1 Like