After yesterday’s post about migrating from SharePoint Designer to Microsoft Flow I will start today with a series of posts with practical examples of losing the Work in your Workflow and make things just Flow.
I’m going to start with an easy workflow, but I’m planning to attack more complicated workflows in the following examples.
Migrate to Microsoft Flow example
So my example in SharePoint designer will run when list items in SharePoint are changed. More specifically I will clone the list item when the column test column is set to clone.
So my workflow will trigger when the item is created or modified. Then all the fields are copied to a new list item making sure that we don’t copy the test column value as that would trigger more processes to start. Maybe this would be a nice test, but this time I’m not going to push the system too hard.
Within SharePoint Designer my workflow now looks like this:
The Create new item copies all the column values. For the test column I’m going to set the value to “cloned by SPD”
Now it is time to replicate the same within Microsoft Flow.
Within no time I’ve build the following Flow:
Creating the item is a easy as well. Simply select the site, list and values for all of the columns and all is done:
This is where you can see the big difference between Flow and Workflows. As i ran the SPD workflow, I can now see my status column for the workflow that was added to the list. Flow doesn’t add a column. If you want to know if your flows were successful you will have to go to the run history in Flow.
This shows the separation that Workflow Manager 1.0 was supposed to bring is now really happening with Microsoft Flow. So no need for workflow history lists in SharePoint anymore.
When you click on the history of one of the flows that clones my list item you will now see what the Create Item actually did.
How often did you include a Log action in SharePoint Designer just to spit out some information helping you to debug the workflow? Flow simply gives you the details in the run history.