This is the final post in my series of building a modern SharePoint Solution. In this post, I will demonstrate starting a Microsoft Flow from a PowerApp. There are many reason’s why you would want this, but the most often used would likely be to allow the user to update an entry, save it and hold off sending it until they have all the information in place. There are alternatives of course; like having a Flow wait for a value to change, but I prefer the user experience a button submission gives you. Special note: Because Flow doesn’t currently allow for multiple triggers for a flow, we won’t be able to use flow created in Part 9 of this series. However, I do suggest you not remove not remove it because this allows multiple ways to kick off the WF.
Posts in this series:
- Preparing SharePoint
- Integrating PowerApps as a Custom List Form
- Customizations All List Form PowerApps Should Have
- Setting a SharePoint People Picker Field Programmatically in PowerApps
- Cascading Drop-down Lists and People Picker in PowerApps
- Create a Flow to be Started Manually
- Creating a Multiple Approver Microsoft Flow
- Sending a Tweet from Microsoft Flow
- Starting a Microsoft Flow from a PowerApp (this one)
Starting a Microsoft Flow from a PowerApp
- From within your PowerApp click on the Flow button in the Action section of the ribbon
- In thesidebarr that opens, click on + Create a flow
- PowerApps will be added as the trigger for your flow (note: the trigger is a bit misleading, but that is actually the PowerApp trigger).
- The workflow is going to be exactly like the one we did in Part 9. There is one significant difference. We are going to have to get the item ID from PowerApps, not from SharePoint as we did in the previous post.
- Add the SharePoint – Get item action. This time when you add the ID to the Id field, you won’t be presented with the SharePoint list item ID. You will only have Ask in PowerApp. This means that Flow is expecting the value it needs to come from the PowerApp. When you click on this option, Flow actually inserts the option (Getitem_Id) into the Id field of the action. This means it is expecting the Id to come from the PowerApp.
I won’t cover the rest of the flow steps here. You an review them in Part 9 of this series. To get this Flow to run, we need to pass the ID of the list item to the flow when called.
- Back in the form, click on Insert -> Button
- Change the text of the button to Submit Request
- Next, add the flow to the PowerApp and associate it to the button by ensuring the button is selected and clicking on Action and Flows from the ribbon.
- Select the flow you just created. You will see a message the flow is being added to the PowerApp. Then it will tell you to update the parameters
- You will notice the formula bar at the top has been changed to OnSelect and the formula is the beginning of a call to your flow. If you try to add something like ThisItem.ID, it won’t work. This is because the button is outside the context of the gallery so the ThisItem object is not available (try adding it to a data card inside the form. Works properly doesn’t it?)
- We need to back up a bit add the ItemID to the form. It’s because of this, the button only works from the Edit form (I’ll discuss this at the end of this post). Click on the form object (not screen) and on the properties slide out click on the Data selection in the properties tab
- Scroll down the object selection window that slides out and place a checkmark beside ID.
- Next, since we don’t actually need to show the field (but you can if you want of course) we are going to hide it, but updating the visible property to false.
- Go back to the button and update the OnSelect Formula to be TwitterApprovalFromPowerApp.Run(ItemIDValue.Text)
- You can now run the button and it will execute the flow.
Starting Workflow from New Form
As shown in this post you can’t kick off the flow from the new form because you don’t yet know the Item ID. You can get around this by firing the flow in the edit form transition. I’ll write about doing this in my next Flow post.
Final Thoughts
This is the final post in my series, but not the last for this application. I intend to use this solution to build other posts to show you the things you can do with PowerApps and Flow. One of the items I don’t like about the default setup for using PowerApps to customize a SharePoint form is that the data cards are cumbersome on the canvas. I will show a better way in my next PowerApps blog. The intention of this series was to show you how easy it is to build a low-code solution in SharePoint with the tools that Microsoft has built. There are great enhancements all the time so things are going to get better and more efficient. I hope this series helped you.
Thanks for reading!!
Comments