What needs improvement with Microsoft Azure Logic Apps?

The OpenAI components in Logic Apps could be more understandable, especially in training data or handling Azure Monitor alerts more simplistically, enhancing interpretability.

Microsoft Azure Logic Apps is good for certain types of workloads, but it doesn't offer many customization options. Considering the current features of the tool, one area I could think of is probably a spot where you can run some kind of script, a task that will just run a script since if it is provided in the tool, one can do much more than what one does currently. In the future, I would like the product to provide a particular task for running scripts.

In MuleSoft, some set views help in transformation, which is very user-friendly and easy to use. In Microsoft Azure Logic Apps, we use Liquid templates, and I feel it can be improved as it does not support all the features that our company wants to use during any complex mapping when we might have to go for custom coding.

Integrating the process with Azure AD is significantly complex, especially when deploying ARM templates and multi-factor authentication (MFA) is involved. This particular area needs improvement. Additionally, enhancing scalability features, such as implementing queuing mechanisms for high-concurrency scenarios, would greatly improve its utility.

The product should integrate more APIs for embedding the overall solution with Azure functions. The API connections with different cloud versions should be easier to use.

The solution should include more connectors. In one of my projects, we faced issues with SAP connectivity. The connector needed to connect the SAP was not compatible with our architecture. We had to create our custom connector for that. Microsoft Azure Logic Apps needs to be enhanced to make it more personal to the integration area. They are moving towards development but not that much towards the integration services part. It should be easier to connect to different third-party services.

An area for improvement for Azure Logic Apps could be enhancing its ability to handle large datasets. When dealing with extensive data, we often have to use Azure Data Factory, which is mostly limited to scheduled jobs.

Not all connectors are readily available, though. There are two types: managed connectors and app connectors. Some connectors require you to provide a username and password to connect to platforms like SharePoint or Salesforce. Due to security constraints, some users may prefer not to use these connectors. Instead, they might opt for the HTTP connector. However, tracking can be a bit challenging. In production, the run history might not be accessible due to security restrictions.

The only thing is, sometimes, when we need a specific connector, it requires an enterprise or paid version. If it were possible to provide the most commonly used connectors for pulling data from different sources free of cost, that would be really nice. For every connector, we have to pay. The cost factor is a problem. For every good connector, we're paying twice – once for the SQL Server connector and again for other data source connectors. It would be concerning if I had to pay for every connector I need. Microsoft can do something about that.

The pricing could be improved.

An area of improvement I've encountered is related to the number of connectors available in Logic Apps. While there are many connectors, I found that the "send email" connector may not work as expected, and one has to rely on Office 365 plugins or other alternatives. This could enhance user experience, especially when considering the additional overhead and licensing requirements associated with Office 365. It also needs to improve security features.

Additional features or extensions could potentially be integrated with Logic Apps.

The solution can integrate with different ETL tools. It can integrate with Azure Data Factory and a more open connecter.

It can be a bit challenging to use.

The visual tool that is used to build integration is quite old. It’s really hard to see all the different models at the same time. It must be modernized, and better support must be provided for the visual tool. The tool must provide support for OpenAPI. We create connectors out of some OpenAPI documentation, but they are really old versions.

Microsoft Azure Logic Apps could have more customization options for connectors.

There are two challenges. First, it's a bit costly at the end of the day. It's difficult to calculate pricing, and that affects the business. That's one challenge. Second, it's asynchronous. So, getting a development team to work on it, making it function properly, is a challenge. Salespeople often have this new notion of sequential programming, so they don't fully understand how it can be used in a disconnected or asynchronous mode. It's difficult for them. It's challenging. In terms of analytics and navigation, using all these modern architectures, it's there, and it works nicely. But if somebody is using a legacy application or needs to make an extension, then it becomes difficult because those applications don't really support asynchronous processes, especially building applications this way. It's challenging to sell those things. So, pricing and handling asynchronous processes are the two main areas that need improvement. The primary challenge is handling the costs, especially the difficulty in providing precise, concrete numbers to the business. This becomes a significant issue because we can't predict what kind of processes will be required. Once you invest, there are various variables in the market, such as manufacturing, and once you get connected, you need a connector, which often comes at an additional premium cost. Every business is sensitive to this aspect. Sorting out the licensing is very complex, particularly when using multiple services. For example, if you want to use Power Apps, Logic Apps, SharePoint, and other services, things become complex and confusing. You can't go to the business and provide a clear budget because businesses prefer a specific number they can allocate. However, it's challenging to provide precise, point-to-point cost estimates because there isn't much detailed information available online. The cost estimates are often high-level. Here is an example. We are building a chatbot, and one part of it is based on the number of requests. We're a company with 7,000 employees. If the chatbot becomes successful, we could have 100 questions or even 20 to 30 interactions per day per user. However, if it's not successful, it might drop down to just 1 to 2 interactions per day from 20 to 30. The cost variation is so significant that it's challenging to present a consistent cost to the business. It could range from ten thousand dollars per month to maybe just one thousand dollars. The range is hard to explain, and in reality, we don't know. And then there are hidden costs. When you try to connect to something, you suddenly realize it's also license-based, user-based, like seven engineers not using it. The price can increase unexpectedly from a couple of hundred dollars to maybe a few thousand dollars per month or even more. This complexity is causing people to avoid using it.

In terms of improvement, it would be helpful to have more descriptive documentation. Since we work in a hybrid cloud model with Azure, AWS, and Oracle, there are instances where we need to interact between different platforms, like Oracle to AWS features, Oracle to Azure, or Azure to Oracle. In such cases, the information available is often limited, and we need to refer to different documentation sources like Azure's API documents or others. It would be beneficial to have scenario-based documentation that helps us understand the integration process more easily. For example, one of my team members had to work on integrating with Azure Blob for data storage. We had to call the Azure REST APIs for that, but the documentation was not clear, making it a bit complicated. We tried multiple REST services, performed trial and error, and eventually got it working. However, having a proper and detailed explanation document would have made it much smoother. Instead of providing everything in one place, having some standard use case documents would be helpful.

If Logic Apps could be built-in as part of Azure Functions, it would be better. We don't need to use it for every case, only for special cases. However, Logic Apps require writing more logic and are more critical in terms of performance. It's not a useful tool. When I use it for bigger cases, I don't think it's much faster. The main issue is performance, especially when dealing with large amounts of data. Performance-wise, that's the only thing Microsoft should focus on.

The product needs improvement in getting direct access to the code and versioning.

I'd like to see more connectors available as well as a more advanced development environment.

It has a lot of integrations, which are quite easy to understand mostly. However, especially when using a function or a parameter, that could be easier as that's not very well-documented, and it's not very clear from the tool itself how to use it. When using parameters or functions, it gets a bit tricky.

The scalability could be improved.

The standard logic app could be simplified. Thats what we would like to see in the next release.

A room for improvement in Microsoft Azure Logic Apps is that it's expensive. Every step is going to cost you money, so if someone is not doing the steps carefully, at the end of the day, it will cost a lot of money. Each time you execute a step, the cost will depend on how much you use Microsoft Azure Logic Apps, and how many workflow steps you have. Each time a step needs to be executed, there'll be a cost added to your bill. If the developer isn't careful with how he uses the solution, this can blow up the cost. What I'd like to see in the next release of Microsoft Azure Logic Apps is for the cost and security to be better.

Microsoft Azure Logic Apps can improve by continually updating the connectors to make them better. In a feature release, they should add a designer interface in the advanced settings.

It's a skill that must be learned. I find the current interface useful, but I could see how others would want the UI bits that are used for creating Logic Apps to be simplified.

The documentation could be better. I think that's the only thing that was causing a normal level of problems. In terms of the documentation, it came from Cosmos DB and an additional product from Microsoft Azure.

I would like the ability to add more features or to become more of a designer first or to be a declarative type of environment. Doing more with Logic Apps through the portal with less code or less script being written would be ideal. It would be beneficial to have less code and tighter integration between different cloud services.

The solution is not user friendly. In the beginning, the solution is easy to use and works fine but when you are doing more advanced tasks it then becomes more difficult.