I apparently have made close to 100 (Power Automate) flows over the last 3 years or so that ping Epicor.
Well, now we are planning to switch the URL that they connect to, to separate the traffic. Just the slug part (the domain.com/endpoint part) will change; obviously the other stuff is standard Kinetic-REST syntax.
I don’t expect this to be quick, and that’s fine. I’ll live.
But my question is, how could I have done this better if I had known that this would happen?
Like, in Postman I can set an environment variable and then it’s easy to change everything. Any analog in the “Power Platform” world?
Not sure about PowerAutomate, but in Logic Apps, there are parameters that can be used to build your URL. Maybe you can steal something from there? If nothing, it would be cool to have one for production, test, pilot, etc.
I have not tried it yet. I saw that it’s a separate subscription for it (over and above the Power Automate licensing), so I lost my spine at that point.
But I guess you are saying there may be a similar idea in the Power Automate world?
So, it depends. . There is a concept of an ARM template, which is an ugly Json version of the resource. In this case, if you put all of your workflows in one ARM file, you can use a template variable that gets assigned to the various parmeters in each workflow.
Another, much simpler option is to write an Azure Function that accepts an environment string and returns the server. That would work with an http widget in PowerAutomate too.
Another idea I had was to just make some simple “SharePoint List” with the data and read it into my Flow.
That’s not as code-ish as both of your ideas, but I imagine it would work. It just seemed a little arbitrary. What if the list gets deleted, etc.
Like “Collections” in Postman?
<rant>
So why doesn’t Power Automate have that natively?
It seems like it needs to embrace that concept of collections. Like I said, I have roughly 100 Flows just scrambled into one big puddle. I rely on naming conventions in hopes of finding anything. I would love to group them somehow and then add parameters variables to those collections. </rant>
At what point did I have to start thinking like a software developer?
I saw a few people suggesting SharePoint lists online and while I think it’s a very viable idea I personally prefer Jose’s approach. But that could just be me and my frustrations with SharePoint as a whole.
Whether it’s a SharePoint list or a simple file it will definitely just be a band-aid fix for what I agree should be a basic feature in Power Automate. I have nowhere near as many flows as you and I agree that it would still be a pain to update them all. Additionally, using any proposed solution adds another flow block or two to grab and maybe parse the result.
If they introduced “environment variables” that were always available in the suggested dropdown options it would eliminate the need for blocks in every single flow that you have utilizing this solution. It should also pull the value quicker than going out to SharePoint or your server’s file system. It’s one of many wishes I have for Power Automate, a great tool with many pain points.
I haven’t looked into them too much, but Power Automate does have the concept of “Solutions” which seems to allow you to group flows based on your project or type of flows.
ARM templates (which can also be described by BICEP), are the actual definitions used by Azure to change the infrastructure. They describe resources and services and Azure implements them from the JSON ARM file (ARM = Azure Resource Manager).
The reason I proposed an https callable function was to make it easy for PowerAutomate to get it. If I serve a file from a local web server, I’ll have to expose that call to PowerAutomate some way.
. There is a concept of an ARM template, which is an ugly Json version of the resource. In this case, if you put all of your workflows in one ARM file, you can use a template variable that gets assigned to the various parmeters in each workflow.
