Azure Logic App Common Scenarios

Azure Logic Apps helps you orchestrate and integrate different services by providing 100+ ready-to-use connectors, ranging from on-premises SQL Server or SAP to Microsoft Cognitive Services. The Logic Apps service is “serverless”, so you don’t have to worry about scale or instances. All you have to do is define the workflow with a trigger and the actions that the workflow performs. The underlying platform handles scale, availability, and performance. Logic Apps is especially useful for use cases and scenarios where you need to coordinate multiple actions across multiple systems.

Azure Logic App Common Scenarios

Every logic app starts with a trigger, and only one trigger, which starts your logic app workflow and passes in any data as part of that trigger. Some connectors provide triggers, which come in these types:

Polling Triggers: Regularly checks a service endpoint for new data. When new data exists, the trigger creates and runs a new workflow instance with the data as input.

Push Triggers: Listens for data at a service endpoint and waits until a specific event happens. When the event happens, the trigger fires immediately, creating and running a new workflow instance that uses any available data as input.

Practical scenarios for polling:

Schedule – Recurrence trigger lets you set the start date and time plus the recurrence for firing your logic app. For example, you can select the days of the week and times of day for triggering your logic app.

The “When an email is received” trigger lets your logic app check for new email from any mail provider that’s supported by Logic Apps, for example, Office 365 Outlook, Gmail, Outlook.com, and so on.

The HTTP trigger lets your logic app check a specified service endpoint by communicating over HTTP.

Practical scenarios for Pushing:

The Request / Response – Request trigger lets your logic app receive HTTP requests and respond in real time to events in some way.

The HTTP Webhook trigger subscribes to a service endpoint by registering a callback URL with that service. That way, the service can just notify the trigger when the specified event happens, so that the trigger doesn’t need to poll the service.

After receiving a notification about new data or an event, the trigger fires, creates a new logic app workflow instance, and runs the actions in the workflow. You can access any data from the trigger throughout the workflow.