Can I edit a cloud flow while it’s running?

The execution of the cloud flow can take a very long time. Hours or even days. Various approval workflows are a typical example of this.

But does the long execution of the flow prevent it from being updated? What happens if the flow is edited while its execution is still running?

As a bonus, we find out what happens if rows are added to Dataverse or SharePoint while flow, which starts from new rows, is turned off.

Modifying the flow in the middle of the execution

Our example flow takes about 10 minutes to complete. Let’s run it.

Let’s add a new action to the flow (Step 0).

Then we restart the flow. Now we have two executions running

After the flows are completed, we can check what the flows did. The first flow looks like this.

Whereas the second flow looks like this.

So flow can be modified even if its execution is in progress. Running flows are completed with the actions flow had when it was started. Running flows are not affected by the changes.

You can therefore bring a solution package containing flow into the environment, even if the flow has ongoing runs in the target environment.

Excellent.

Updating environment variables

So how does an environment variable behave if its value changes in the middle of the flow execution?

A new environment variable is created for storing the email address (notification email).

We use the value of the environment variable at the end of the flow.

Let’s start flow.

After that, we update the value of the environment variable.

The execution of the flow is still in progress. In practice, it takes several hours before it reaches the point where the value of the environment variable is used.

Which environment variable value does the flow use? The value that the environment variable had when flow started, or the value that the environment variable has at the time when the environment variable is used in flow for the first time?

The answer is: the value of the environment variable when the flow has started.

Shutting down flow in between executions

We have a flow that triggers when a new row is added to the Dataverse table.

Three new lines are added, so three runs are started.

What happens when the flow is turned off?

New runs are not started, but the ones in progress are completed beautifully.

Restarting flow

Let’s turn the flow on again. When the flow was off, new rows were added to the table. Does the flow trigger because of them after starting? No.

So that’s how it works with Dataverse.

What if we do the same test with a SharePoint list?

We create a new flow that triggers when a new row is added to the SharePoint list.

We add two new items to the SharePoint list and the flow starts.

Next, we turn off the flow. After this, two new items are added to the SharePoint list.

Finally, we turn the flow on again. What on earth! After a few minutes, those new items trigger the flow. Items that were created when the flow was turned off.

Why do Dataverse and SharePoint triggers work differently?

It’s about the implementation of the trigger. It can be

• Polling, the trigger regularly checks whether there have been any changes since the previous check that it should react to. A SharePoint trigger is like this.
• Webhook, the trigger is triggered directly from the target. The Dataverse trigger is like this.

If the flow’s trigger is polling, upon startup, it processes all events since the previous check (before turning off the flow).

If the flow’s trigger is a webhook, it processes all events after the start.

A significant difference to consider when turning the flow off and on.

How do I know which implementation the trigger represents?

Behind the three dots, you can look at the trigger’s code (peek code).

If the trigger is polling, there is a recurrence interval defined. From the picture, we see that with SharePoint trigger the check is done every minute.