Flows and PowerApps go hand in hand recently. They can transform many different business processes such as Employee Onboarding/Offboarding, Nominations, Permissions, Site Creation, etc.
A great way to utilize Flows and PowerApps in tandem is to allow a PowerApp to initiate a Flow and feed the Flow that information which is already provided in the PowerApp Form.
Creating the PowerApp
In this example, we are going to create a simple blank PowerApp that will have two fields: Subject and Body.
If you haven’t guessed already, the PowerApp will contain a button that when clicked will initiate a Flow that consumes the information entered by the user into the Subject and Body fields and send an email to whoever the Flow has defined as a recipient (you could theoretically go a step further here and define the recipients in the PowerApp but I’ll leave that up to you).
Your new PowerApp should contain at a minimum two Text Input fields. You can make one of them multi-line if you’d like for the Body. Ours looks like the image below.
Next, we will add a simple button to the PowerApp labeled “Send Email”.
With the button highlighted/selected, navigate to the “Action” tab and click on “Flows”.
You’ll notice in our example, one Flow already appears. This is because any Flow you have created in this environment that has a plain trigger of “PowerApps” will be consumable in the PowerApps themselves.
Creating the Flow
For this example, click on “Create a new flow” to start the Flow Creation process. We want to make a simple two-step Flow so click on the first template available which is the PowerApps to Custom Action flow template.
Next, we will want to create a single new step called “Send Email”. You can define yourself or anyone you’d like as the recipient and when clicking on the “Subject” or “Body” property, you will be given the dynamic content property of “Ask in PowerApps”.
If you use that property for both values, you should then be presented with something like the image shown below.
Setting Up The Action Button
Save your Flow and head back to the PowerApp we created earlier.
If you close and re-open the “Flows” panel, your new Flow should now be available. While you still have the “Send Email” button selected, click on our new Flow to add it to the button. Once added, you will notice that the “OnSelect” property has been filled in with the action of “SendEmailfromPowerApp.Run(“.
The name of this action may vary based on what you named your Flow. You will also notice that it is asking for two parameters. These parameters are the Subject and Body we asked for in the Flow.
We can now feed the Text value from the first Text Input in for the first value and the same for the second.
With this, the PowerApp and Flow should now be integrated. If you run the app, fill in the values and click on “Send Email” your Flow should kick off emailing your recipient with the values you input for Subject and Body.
Read Next: How to Create Filtered Relational Drop-downs with Choices in PowerApps
Relational drop-downs are something that come up quite frequently but aren’t always straight forward.
PowerApps gives you a relatively friendly manner of creating simple relational drop-downs when using the “Depends On” functionality but this falls apart when utilizing anything but simple fields (text, number, etc.) and trying to further drill down into filtered results. You may have noticed that when you start trying to use Choice fields to filter your drop-downs on, it is not inherently possible.
In our example, we will work off a mock Products list in SharePoint. The SharePoint Products list will be made up of the following columns (yours can vary):
- Product Type – Choice field – Choices: HDD, CPU
- Title – Text (Product Name)
- Manufacturer – Choice field – Choices: Timlin, Generic
- Configuration – Choice field – Choices: 250GB, 500GB, x1, x2
Below is a screenshot of how this list looks and some sample data we have input for testing.
Once your list is setup, we can hop straight into PowerApps. If you aren’t familiar with how to get started, simply click on the “PowerApps” button followed by the “Customize Forms” button.
We arranged our fields in the PowerApp to go in the following order: Product Type, Manufacturer, Configuration and Title.
The end goal of this is to have it so the end-user will go through the menu one by one and be provided a final filtered list of products that follow the selected Type, Manufacturer, and Configuration.
You might notice from the screenshot of the layout of the PowerApp above that there are duplicate fields. The reason for this is that the more advanced filtering we will be doing on the fields does not work when using the out of the box choices column in PowerApps.
To circumvent this, we unlock each of these data cards and add a “Dropdown” control (to make things easier, set “AllowEmptyField” to true in the properties of each drop-down we add).
Currently, the fields are disabled just as a visual aid but in normal circumstances, you can set the value of the fields to the value of the drop-down and have them hidden in the background so nothing is visually different to the end-user. In our example, Product Type won’t need to be filtered in any way so we can leave that card alone.
Our options in Product Type are CPU and HDD.
In this instance and given the sample data above, when we select “CPU” we will want to see both the Timlin and Generic manufacturers (we will filter this even though each manufacturer has a CPU, there will be instances in production where a manufacturer will exist that does not offer a CPU product).
To filter the Manufacturer drop-down based on the Product Type, we can set it’s “Items” property to the following formula (keep in mind that the numbers or names of the Data Cards may vary on your application):
Distinct(Filter(Products, ‘Product Type’.Value = DataCardValue2.Selected.Value),Manufacturer.Value) – DataCardValue2 is associated with Product Type
Using the “Distinct” operation, we ensure that we do not pull back the same manufacturer more than once. The second parameter following the filter (Manufacturer.Value) is the return value, which in this case is the Manufacturer value that we want.
The Filter operation is ensuring that we are only getting products in the list that match the product type we selected in the first field. One other thing we want to do on this drop-down is to set up a variable that stores the filtered results so we can easily filter our next field. To do so, we can change the “On Change” operation to the following formula:
Set(ManufacturerFilteredProducts, Filter(Products, Manufacturer.Value = DataCardValue4.Selected.Value)) – DataCardValue4 is associated with Manufacturer
This will provide us with the list of products we have filtered on Product Type and on Manufacturer.
Next, we will want to set up our Configuration drop-down to only show us products that have the Product Type and Manufacturer the user has selected. To do so, we can set the “Items” property on the Configuration drop-down we added (the control, not the field) to the following:
Distinct(Filter(ManufacturerFilteredProducts,’Product Type’.Value = DataCardValue2.Selected.Value),Configuration.Value)
We should now have a drop-down with only the results that match the Product Type and Manufacturer the user chose in the previous two fields.
Lastly, we will want to make sure that when a user chooses a configuration that the product names that appear in the “Title” drop-down are those that match all of the previous filters. To do so, we set the “On Change” property of the Configuration drop-down to a new variable (FinalFilteredProducts).
This variable will filter the results we stored in ManufacturerFilteredProducts based on the Configuration value the user chooses and store the results for use in the Title/Product Name field. We can do this via the formula below:
Set(FinalFilteredProducts, Filter(ManufacturerFilteredProducts, Configuration.Value = DataCardValue3.Selected.Value)) – DataCardValue3 is associated with Configuration
Finally, we want to make sure that the only Titles we get back are for products that are related to all three previous drop-downs. This is simply just the Title rows in the FinalFilteredProducts variable we just created. To do this, set the “Items” property on the custom Title drop-down to the following:
FinalFilteredProducts.Title
This should produce a fully filtered list of choices for the products (as shown in the original screenshot). Given the sample data, if a user were to look at SSDs made by Timlin with a 250GB capacity, the only title we should get back is the “Timlin 250GB SSD”, which we do (shown below).
Interested in diving in deeper to Filtered Relational Drop-downs? Reach out to our team here to set up a free consultation call.
To start, what do I mean by ‘Linked and Unlinked PowerApps for SharePoint’? In short, you can create a PowerApp for a SharePoint list directly from the list itself (as shown below). When doing so, the PowerApp is directly linked with that list and is ready to go for submitting items.
The other way of creating a PowerApp that will handle data submission to your SharePoint list is by creating a blank PowerApp and adding the list as a data source via a Form element.
Each of these approaches has their pros and cons, and we are going to go over these differences, so you can determine which solution works best for whatever it is you are trying to do with PowerApps and SharePoint.
Linked PowerApps
A linked PowerApp will be the easiest and most user-friendly way of creating a PowerApp that is directly associated with a SharePoint list in your environment.
It will, by default, contain all fields that are currently present in the SharePoint list from which it was made. These fields can be removed or hidden at will, but any required fields will need to remain on the PowerApp and its respective form.
One con to this approach is the fact that you are now restricted to using a Phone Layout and only a Phone Layout. There is no out-of-the-box way (currently) to directly create a larger PowerApp (tablet layout) that will be associated with a SharePoint list. You will still have the ability to customize your application in the Phone Layout just as you could customize any other PowerApp, but you will be limited to the phone resolution and aspect ratio. Attempting to increase the application size in app settings will only increase the container, not the content within the application itself.
Unlinked PowerApps
The unlinked approach is a more technical approach to creating a PowerApp for a SharePoint list. This involves creating a blank Phone or Tablet layout PowerApp and adding the list as a Data Source. The easiest and quickest way to do this is to add a “Form” element and set its data source to the list you are attempting to work with.
This approach will grant you the ability to make larger PowerApps that will still post data to your SharePoint list. The main concern here is not being able to create new entries in the SharePoint list, but to edit entries that have already been created.
In a linked PowerApp, the list item will already be fed into your PowerApp and be ready to edit. In an unlinked PowerApp you will need to configure custom parameters that pull in the item that is being selected.
This definitely adds a level of complexity to the form/PowerApp, but depending on how large of an application you are looking to develop, this may still be your best approach.
Interested in this solution for your SharePoint investment and working with the Timlin team? Request a 30-minute free consultation here.