How to create an improved Microsoft Teams Files approval process using Azure Logic Apps

Published Feb 12 2021 05:46 AM 6,201 Views

We are all there during some days: Power Automate Premium is the key to the next level but there is no way we could justify that licensing – the ROI is simply not enough. Have you thought that you could be utilizing a Azure Logic App instead?




Following my earlier post ( How to: initiate a document approval directly in team files tab (using Power Automate) ) that required a Power Automate Premium license I recreated that with Azure Logic Apps solution. Please do refer and compare to that blog post these steps to see how they differ. For later mentioned parts you need to follow steps in that post.


What are Azure Logic Apps and do they cost?


First: what are Logic Apps? Let’s take a snippet from Microsoft Azure Logic Apps documentation here.


Azure Logic Apps is a cloud service that helps you schedule, automate, and orchestrate tasks, business processes, and workflows when you need to integrate apps, data, systems, and services across enterprises or organizations. Logic Apps simplifies how you design and build scalable solutions for app integration, data integration, system integration, enterprise application integration (EAI), and business-to-business (B2B) communication, whether in the cloud, on premises, or both.


In short: you are create something almost like a Power Automate Cloud Flow but you do that in the Azure. The user interface is slightly different but almost all essential parts are there: triggers, actions, connections and of course various connector.


The big difference is that you will be paying for all Logic App runs but the bright side is that you don’t have to purchase Power Automate Premium. Of course it pays to do some rough calculation on Logic Apps. In my demos for a week I accumulated less than one euro on Logic Apps costs.. If something you construct is used repeatedly and has lots of loops costs can build up. But if you have a random need for a Premium or custom connector requirements Logic Apps might be a perfect solution. This also depends on number of users you would have to license Premium Power Automates to: yearly investment counts.


Read more about Logic Apps pricing here.


I suggest to start with

  • Create a resource group for Logic Apps so you can easily keep on track of the costs – and also manage your apps
  • Put a budget to Azure in place so your costs don’t suddenly skyrocket
  • Follow costs and cost estimate

Creating Azure Logic Apps -process for file approval requests


Now that we have that householding taken care of we can finally create the Logic App.

Navigate to your Resource Group and click on Add.



Add a Logic App. Use search to narrow the list down.







Note: Be careful how you name your Logic App in the next step because you won’t be able to change it later!





Add Tags if you use them, Review and Create the App. The Logic App is deployed rather quickly and you can then go to the Resource.


Go to Logic App Designer






From there you can start selecting your trigger how the Logic App is activated. Since we are duplicating the earlier post functionality with Azure Logic Apps we choose “When a HTTP request is received”






And now the UI starts to look very Power Automatish





The difference is about available parameters. You need to click on Add new parameter to open menu that is in this (and in many other actions) not visible unlike at Power Automate designer.






Check Method





And you can choose Get from the list.





And now we have the trigger part ready (waiting for a save)!





Then we add other parts. The search for actions is not as good as in Power Automate Cloud Flows but keep on trying – the actions are there!






Let’s populate that with triggerOutputs()[‘queries’][‘FileID’] just like in the earlier blog post.






Add there Get File Properties from SharePoint. In this point we need to add a connection to the SharePoint. Use credentials that you seem to be fit.








Once you have signed in you can define the information how to get file properties.





The FileID is missing. You need to do a bit trick here:

  • Change parameter to integer
  • add it to the Get file properties
  • Change parameter back to string



And click on see more at Variable section in Dynamic content




Choose fileid. And yes! (don’t forget to change the fileid parameter back to string)





At this point we have

  • FileID
  • All file properties
  • Open HTTP request..

Let’s close that HTTP request first. Add Response-action and instruct to close the tab.







Note: here is when you need to progress differently than with Power Automate Cloud Flow approval


This is because Azure Logic Apps doesn’t have Approval-connection. In this phase I decided to make the demo easily: writing the approval request to a SharePoint list in the tenant and and creating a another Power Automate with a when item is inserted trigger there.


First – let’s create that list where we can write the information to. We can use Teams Lists -app for that.





Search for the action in Azure Logic Apps and add Create Item








Now, we need to click on Add new parameter to add list columns to the action.




Choosing Approver, FileID, and Outcome. I actually should have named Approver as Approval Requestor but hopefully it doesn’t confuse too much.





When filling up information you can use Dynamic values from Get file properties. Since we don’t really know who clicked that request approval button we just assume it was the person who did changes the last time.

And that’s it!




Hit save (if you haven’t already) and you have the URL in the trigger action available. Proceed with column formatting as stated in previous post.

Fast forwarding the Power Automate that is created as a trigger to the File Approvals -list looks like this:





Steps are roughly similar to the ones as in the earlier post.

  • The new item is inserted trigger
  • Getting file properties from the Documents (based on the fileID )
  • Updating that file that Approval is processing
  • Storing the file name into a variable
  • Getting a comment from the user that last modified the file why this document needs approving
  • I didn’t add this one but you could figure out who is really the document approver. Perhaps there is metadata that can define that one – or the library / folder itself is tied to a structure that defines the real approver
  • Create the approval request
  • Wait for the approval to conclude. I have found out that it is better to use Create + Wait combination in separate actions compared to the Start & Wait single action. If you need to count your Power Automate executions then a single action might make more sense..
  • Add also the check is it approved or rejected. I didn’t add this either to this demo but this is definitely needed if you are taking any real action after the approval process!
  • Updated the outcome to the list and then to the file itself to a dedicated columns
  • Added a information about approval request to be sent to a channel



With Azure Logic Apps it is possible to go the next level without paying for Premium Power Automates. There are also other create features in Logic Apps that I didn’t even touch on this one: ability to modify the app in Visual Studio for example. And that means it is easy to add to a version control as well..

You need to pay attention to the execution costs and make sure that your Logic Apps stay in the budget. This suits extremely well for low-medium usage actions.


You may have to switch from a Logic App to Power Automate at some point – like we did in this example. Plan carefully how you do the data exchange and where do you store the information & who can access it. The HTTP trigger in this example isn’t the safest one to use (it lacks security) so you need to plan how you either add some security to it or secure it in some other way. In my earlier post I also made some pointers about this: look them up.


Not all connectors / actions are in the Logic Apps but many of them are.


Azure Logic Apps are a great way to extend Microsoft Teams and integrate it to different systems – inside and outside of Microsoft 365 cloud.


This blog article is a repost from MyTeamsDay.Com.


Excellent article @Vesa Nopanen.  Another big difference between Flow and Logic Apps is run duration.  30 days in Flow and 366 days in Logic Apps, Microsoft can be so short term in their thinking sometimes.....


Hey @MrNigel that is very true! If you would like to read more about that, here is another cool blog post:  How to transition from Power Automate to Logic Apps - Microsoft Tech Community

Excellent article @Vesa Nopanen thank you for sharing.


Besides cost, are there other factors that help you decide between Power Automate and Azure Logic Apps?





hey @stormin_30  that is a great question. 


I encourage my clients to not let licensing make the decision what are the right building blocks for the solution they need. 


My rule of thumbs:

personal productivity: Power Automate

mission critical process: shouldn't run in Power Automate in the context of a user, we will need the complete run history and maybe flows that can run longer than 30 days. Azure Logic Apps gives us more mature ways to monitor flows. 

@MrNigel - thank you for pointing it out. I added it to my original blog post.


@stormin_30 I would also think what you are achieving to do and how do you manage that. Solution lifecycle, code maintenance, governance and various other aspects do affect that one. However on Power Automate side there are also easiness, no need to have access to the Azure Subscription (nobody wants to see these run on user's own subscription because they didn't get access to company's own..) and what is the scope / business critical factor. That is why there are lots of (more or less uncontrolled) flows running around. The more aware the consultant is about all these solutions (like Azure Logic Apps) and how they would fit the big picture the better they can suggest the customer what would be the best overall approach.


@Luise Freese : Licensing costs are a strong driving force in organizations. Costs affect decisions and it is our job as consultants to work out the best possible solution that will help customers. Of course it is great if they can think outside of those costs but very often there are strict constraints like licensing (or even any extra running costs) and implementation costs that force to rethink the solution and guide them towards the right way to do things. Azure Logic Apps are a great way to get more done in a more formal & correct way.  

New Contributor

I agree with @Vesa Nopanen on the licensing. I find it naive to think organisation don't look at licensing costs and should just buy into whatever is best for their use-case regardless of licensing models. Everyone does a cost-benefit analysis on project. It's often in their job description!

I'm a big fan of the Power Platform (we have a whole practice around it), but the licensing models around Power Apps and Power Automate has led to a weird "Emperor's new clothes" situation where we are trying to pretend it is alright when really it isn't. The telltale sign of it is we are all developping ways around it whereas we'd just rather work with it if we could. If we wouldn't do that, we'd have to kill 90% of the current projects on the Power Plateform.

The frustrating is : it doesn't have to be that way! PBI by contrast has no free O365 plans but a very low price point. It led to massive adoption and good funding for the product. One thing leading to another, it is now completly dominant in its market...

(Sorry, didn't mean to do yet another PP licensing rant. Pet peeve... -_- )

Occasional Visitor

This is a very good side by side build comparison Vesa! Thanks!


Most SaaS offers have indeed a PaaS counterpart which allow client to choose one path or another to fit their business needs. Cost is undoubtedly one easy factor to point out when making the decision, and I will be super interested to read your follow-up article on the other important aspects like Governance, Support, cost predictability. 


But one thing that we saw becoming true, is that individual Power Platform solution using premium features is often less interesting financially than their PaaS counterpart. But in organizations where Power Platform licenses are deployed widely and many solutions are in production, then the Low-Code will often cost less than the PaaS equivalent. 

With Power Platform licensing (and no, I am not going to into licensing details there because it always depends) model it makes a lot more sense to use Power Platform if the organization is already using that widely and thus adding a new application/process doesn't add to overall costs. When planning for architecture/platform to use there needs to be some vision what's next beyond this one. It is all about ROI calculation and cost-management in a long term - only during first steps it is about a single or few apps/processes so looking at the big picture is very important. 


Azure opens possibilities how you can integrate and extend Microsoft Teams (& Microsoft 365). It is good to be aware what is out there so you can evaluate what would be the best way to implement your business needs and what those options mean and how they will be maintained in a long run.




New Contributor

I agree @Vesa Nopanen with the overall long-term vision, but to an entreprise stakeholder it boils down to saying "once its a sunken cost, it doesn't cost anything anymore". True. But if that argument were a silver-bullet, we wouldn't see so many SPO/DV4T projects every day.


A great part of Azure's success (and other major cloud vendor) is specifically that they don't require a massive org-wide commitment. A stakeholder can simply pop-up a suscription for his/her small needs and let the fees grow with actual usage. It might end up costing MORE in the overall picture, but the value will have been demonstrated every step along the way.


I know it's a debate that happened at least one million time by now. But I saw your post being attacked on Twitter by licensing gurus and felt it wasn't fair for the business as a whole.

I agree fully @fforest-dtr ! The more one spends time capabilities Azure can provide it is a game-changer due to those points you made: start small and you don't have to have a massive commitment. And yes - that debate will go on. 

Besides "sunken costs" there are also costs for maintenance & changes and long term support (by people) that are not so easily calculated. Dataverse for Teams does create great possibilities for extending Teams (without adding to licensing costs) and we will see that being used a lot - up to the point when DV4T environment gets full. It is super-easy to experiment with that and I do that as a lot. One demo/POC I built was how to use DV4T PVA bot combined with Azure Logic Apps to do more beyond a single tenant. #KeepOnExperimenting 


Thank you for your support, especially regarding on the twitter thread. ❤ 

Occasional Visitor

But I totally understand the struggle to bring clarity to a client when looking at building a solution.  Offering an enterprise grade Low-Code platform in a "freemium model" in a product suite as broad and deep as the Microsoft universe will inherently create product overlaps and confusion on the value of certain premium options. 


I guess it is easier to categorize when a project is initiated by a citizen developer where everything pretty much stays within the Power Platform / O365 universe with or without premium features. Especially true with DV4T that really opens up new possibilities beyond lists. 


However, for projects initiated by a CoE or a partner who have access and skills to other tools like Azure, there is more choice. So I guess this will be part of company governance process. Typically we see "integration projects" going to azure as the business model is better suited for large volumes and "automation" projects to Power Automate as the governance and extensibility into D365 and O365 is native. But like pointed earlier, when premium features are required, the first initiative feels less interesting from an ROI perspective. 

Version history
Last update:
‎Feb 12 2021 05:46 AM
Updated by: