Adding Microsoft Form into a Power Automate/Apps Solution

[kky1]

Hello community!

I've a general question which I actually posted to the Power Automate community a few weeks ago but never got a response so thought I would post here in case anyone knows the answer. In additon to using Power Apps for more robust application, I've also built a lot of Microsoft Forms that trigger various flows for offices to capture and store form responses in an automated fashion. We have so many of these that we've invested in a DEV and PROD environment.

I would like to organize these cloud flows, Microsoft Forms (both the link to edit the form and the link to get responses) and the Power BI dashboards into a solution in DEV and transport as a package to PROD.

Is it possible to add a Microsoft (MS) form into a Solution? (I've googled how to add the MS Form but am not getting any good results on if this is possible and how to do it)

Thank you,

@kky1 

[Syndicate_Admin]

Happy to hear it!

[kky1]

@Jronash - I thought I'd post to let you know that I was able to use the existing flows with MS Form trigger by manually exporting/importing my test Solution. I then turned on the flow and tested and it triggered! 🙂 So, maybe not using the pipeline in this specific scenario will work!

[kky1]

Thank you for this wonderful advice! I'll give this a test (holding my breath for a miracle that the flows aren't removed), but if they are, I at least know what I need to do next!

[Syndicate_Admin]

Ok, makes sense.  I'm using Pipelines, so it's possible that your experience will be different from mine, but if I were in your position, this is what I'd try next:

Try putting one of your Forms flows into a solution and import it into PROD.  If it lets you do this and everything seems to work, then great, you're good to go!  But I'm guessing it's not going to allow you to add a flow with a Forms trigger to a solution.  In that case, there are still ways to make it work, but it's going to be a more painful process.

Your options are either to re-create the flow as a new flow in your solution, or to remove the Forms trigger from your existing flow, bring it into your solution, and then add it back.  Both of these options are less than ideal, as I'm sure you know.

If you decide to create it as new, I'd suggest creating it in the DEV environment, and follow the steps I outlined before.  Start with a basic "When a button is pressed" trigger and then export/import that into PROD.  Then go back to DEV, change the trigger to Forms, and export/import to PROD again to be sure it imports correctly before you put in the work of rebuilding the rest of the flow.

If you decide to try to re-use your existing flow, you will have to remove the Forms trigger.  As you mentioned, this is going to remove all of your dynamic content and you're going to have to replace it with something temporarily so that you can save the flow again.  This might be more work than just re-creating from scratch, but you know your flows better than I do.

Once the Forms trigger is removed, try putting it in your solution in DEV again, and then follow the same process as before.  Export/Import into PROD without the Forms trigger, then go back to DEV and add the Forms trigger back, export/import to PROD again, test.

Hope things go smoothly for you.

[kky1]

For the work I've done in DEV, I haven't used Pipelines. When I need to make an upgrade to a flow/canvas app in DEV, I manually export the Unmanaged Solution and then import in PROD.

[kky1]

In this scenario, I inherited these flows/MS Forms which are currently in the company's default environment (neither DEV nor PROD). I'm trying to organize the flows into solutions by unit/office and migrate as Unmanaged Solution to DEV, then add in the connection references/environment variables, etc., and then migrate again as a Managed Solution to PROD. My hope then in the future is if there needs to be edits to the flows, they'd be done in DEV and upgraded in PROD. 

Alternatively, I've read blogs where people just exported/imported each flow and re-established the connections, but not sure if that's a good long term solution.

I apologize for not being very clear and again thank you for your guidance!

[Syndicate_Admin]

Let see - you said you were using DEV and PROD environments, but I guess I don't know for sure how you are moving things between the two of them.  Are you using Pipelines?  Or do you have a more manual process?

[kky1]

This is probably an obvious question, but with your workaround, it sounds as if the flows need to be created within the solution in DEV? I've inherited all these flows/forms and so was hoping for a solution where I wouldn't have to create from scratch. If I remove the existing trigger, the flow actions referencing my triggerBody will break and I won't be allowed to save the flow.

[kky1]

@Jronash - thank you so much for this detailed explanation! Yes, there is a flow that triggers from these forms. I've begun storing the MS Form IDs as environment variables but didn't realize it might not carryover anyway with the flow trigger. I sincerely appreciate the heads up and your workaround!

[Syndicate_Admin]

@kky1 

I forgot to report back, didn't I?  

First of all, there are two things here that might affect you.  The first is your original question - can you add a Form to a Solution, and the second question that you may or may not run into is whether or not you can even add a flow with a Forms trigger to your solution.  (I'm assuming that you are using some flows to handle form submissions?  But that's just an assumption of course.)

For your first question, the answer is no - you can't add a form to a Solution.  If you want to have DEV / PROD environments that utilize Forms, you'll need to have two versions of each form.  One for Dev, and one for Prod.  Once you have those, you can store the form ID in an environment variable and use it in your flows whenever you need to reference that form.  That will allow you to create flows that fire for the Dev Form in the Dev environment, but only fire for the Prod Form in the Prod environment.

If you don't have any flows that fire when these forms are submitted, then you don't have to worry about any of that.  And yes, in that case, using an environment variable to let your developers know where the forms are located is a great idea.

If you DO have flows with Forms triggers in your environment, the next thing you're going to find out is that when you try to move them to PROD using your pipeline, they disappear.  That's the limitation I highlighted in my previous post.  Fortunately, I was able to find a work around for this:

Here's what I ended up doing.

1. Create a flow with a generic trigger, like "When a button is pressed".  Add a second action so you can save it, and then use the pipeline to deploy it to your PROD environment.
2. Now remove the trigger and add your Forms trigger.  Instead of selecting the form from the dropdown, use the environment variable you created that has the form ID in it.  Deploy it to your other environment again and this time the Forms trigger should go with it and the flow will stay put.

[kky1]

Hello @Jronash - For whatever reason I am just now noticing your reply and I appreciate your suggestion. There are approx 30-40 forms and upwards of 50-75 flows that I've inherited that I really would like to package into solutions based on unit/client and export to our PROD environment. Editing every one of these flows is going to be a bear. I haven't found a solution yet and was considering to simply create environment variables to hold the URL of the MS Forms. Basically I just need a way for developers to easily locate the forms that correspond with the flows. Did any of your workarounds work and how time-intensive was it?

[Syndicate_Admin]

I'm working on this exact issue and having problems.  I seem to be able to create a flow with a Forms trigger in my solution in a Dev environment, but when I use a Pipeline to deploy it to Test, the Forms flow doesn't come along.

I found this in the known limitations section:

• Flows using connectors that are 'indexed' cannot be added into solutions. Indexing isn't supported for solution cloud flows yet. Indexing enables the quick retrieval of those flows to display in a menu or list. Indexed connectors include Power Automate instant (button) flows, Power Apps, Teams, SharePoint, Dynamics 365 Customer Voice, Microsoft Forms, legacy Dataverse connector, Dynamics 365, Excel Online, Microsoft Project, Azure IOT Central V2, and Project Online.
  • Workarounds for this limitation:
    • Edit the flow to remove the indexed connector triggers/actions, add it into a solution, and then change it back.
    • Create a new flow in a solution.

I'm going to try some of the workarounds and I'll report back if I'm successful, but I also wanted to see if you had found a solution for this yourself yet?