Forum Discussion
Which tool is right for me? (Powerapps, Sharepoint List Form, Excel Survey, etc)
I have a couple of projects I'm working on right now where I need a simple form to collect data from users.
We have O365 E1 so lots of tools are available to us, but I'm not sure which one is the right one for the job, or how best to piece them together if needed. Also, we're a small organization with jack of all trades style IT, we don't have a dedicated sharepoint guy or such, so it needs to be fairly simple to set up. Can someone get me pointed in the right direction?
A little more detail about each project:
1) We currently have a "send text" powershell script which creates a simple form window asking for a phone number and message, with a submit button at the bottom. Users fill out and submit the form, and the content of their message is sent to the specified number as an SMS message using Twilio. I want to replace this script with something more portable, and which might be supported by someone other than the guy (me) who wrote it. I see that MS Flow has a connector for Twilio, so I think that side is easy enough. I just need to figure out how to collect the data from the user and pass it through Flow.
2) We're trying to improve our employee onboarding. I have a powershell script which handles most of the account creation, but getting the data to that script has been a pain. It's coming from multiple sources in multiple forms, and then our helpdesk person is entering it all into a spreadsheet/csv file which the powershell script pulls data from. There's a lot of human error involved though, both in the original data and the entry into the spreadsheet. I want to create a form that collects the data, with several fields as drop downs, and saves it somewhere that allows me to pull it in to my powershell script to take from there.
What should I be using for each of those to create the forms and to store the data to make it available for the next steps?
Edit: I should note that I did already read the Forms for Sharepoint, What are Your Options article by Haniel Croitoru, but while it nicely summarizes the differences between the options, it didn't help me decide what I need here.
Hi Steve,
There are definitely more than one option available to solve your dilemma. What's great about the E1 is that you can use a variety of tools based on the needs. It's important to consider the pros and cons of each though.
1. You're right about using the Microsoft Flow Twilio connector to send the message, which is quite straight-forward to use and doesn't require any technical expertise really. In terms of the form, you could use a SharePoint list to capture the text (for archiving purposes as well) or use PowerApps. The latter would provide a nice interface for users to use on their mobile devices, but is a bit heavier on the processing as it requires the PowerApps app to be installed wherever you use the forms. Another consideration is cost. Based on the Microsoft Flow Pricing Plan, you can send up to 750 SMS messages per month with a delay of up to 15 minutes per message.
2. For the onboarding case, in order to cut out the potential errors introduced by a helpdesk person would mean having a workflow that can talk to the other systems to retrieve the necessary information or possibly even execute some of the tasks. Again, you could go with a SharePoint list and enhance the form with PowerApps. However, in my experience, provisioning is often an asynchronous tasks where some tasks have to wait until upstream tasks are complete as they depend on information coming from them. If the PowerShell script is taking care of all then, then you're set. You could also look into using Azure Functions to perform the PowerShell work for you so the process becomes more automated. Have a look at the article on Using Azure Fuctions in PowerApps.
However, if you're looking to further automate the process and be able to track progress, I would lean towards a solution like Nintex, which is great for such complex workflows.
Unless there is a very compelling reason for you to use SharePoint Designer or Infopath, I would probably recommend going down the PowerApps/LogicApps/Flow route as this is where Microsoft is investing their efforts now.
Hope this helps. Please feel free to reach out to me as I always like to discuss these kind of problems and solution with peers... #processgeek :)
- I actually didn't realize that flow charged per run, I thought it was simply included with E1. Regardless, these individual messages are fairly low volume, so I don't think the limit would be a problem. For our higher volume text messages we have an automated process that works well for us currently.
The thing about the text message project is that I don't need, or want, to keep the data after the messages have been sent. Any storage of the data should only be temporary as it is passing from the web form to twilio. Sending it to a sharepoint list just to delete it as soon as the messages are sent seems like a bit of a waste. Still, it might be viable.
I also see that flow supports a service called 'typeform', which seems like it might be just what I'm looking for, a dead simple web form to collect user input for this. The only concern is whether I could get that approved for use. Everything O365 is already covered by the necessary agreements and approvals. A minor correction regarding Flow limitations: with the plan comes with Office 365, you can have an aggregated number of runs 2000 runs * number of users in your tenant (instead of 750/user) with 5 mins frequency (instead of 15 mins). So even better. :)
- There's no silver bullet here - each has pros and cons, and each comes with their own level of complexity.
I would however suggest that using a SharePoint list you have a better level of data access and integration with other services, whereas anything collected in Excel lives inside the file and is an extra step to retrieve / integrate.
PowerApps you only need to do if you want a desktop or mobile based app for the end user.
I would start with a SharePoint list, wrap a Flow about it, and then decide how you want the front end to look like - whether continue using the SharePoint list entry form or take it a step further.
