Azure Functions Integration

[BatterySmooth]

This issue tracks the implementation of an integration for Azure Functions in Elsa Workflows. The module should allow workflows to interact with Azure Functions, supporting triggering of Azure Functions

Tasks

• Create a new module: Elsa.Integrations.AzureFunctions
• Implement Function Services:
  • Trigger Function (this is effectively just an HTTP action)
  • Authorisation/Authentication service
    (could be a simple function code, or AAD/Entra authentication, though the latter is going to be a bit more 'fun')
  • Service for extracting Function body schema from Swagger/OpenAPI endpoint (Optional)
• Implement custom Activity Provider
  This will generate the Activity Descriptions from config/env
• Implement AI Tools (Optional)
  • Tool for AI agents to invoke Azure Functions actions
• Add Unit Tests
• Add Documentation (README.md)

References

• 📖 Azure Functions Overview
• 🛠️ Azure Identity SDK (for AAD/Entra authentication)

Notes

• This should follow the standard structure used for Elsa Integrations.
• The integration should support function code authorisation and (optionally) managed identity authentication for Azure.

Contributing Guidelines

If you're interested in working on this issue:

1. Comment below to claim it.
2. Follow the CONTRIBUTING.md guide.
3. Submit a PR referencing this issue.

[BatterySmooth]

Hi! Saw this was a planned feature in the elsa-core roadmap and I would be keen to work on this.

It might be a bit redundant, since most Functions are HTTP triggered (and so might not really be required), but could open the door for Azure Function management using the Azure Management SDK. The main reason for doing this (as far as I can tell) would be for handling of authentication and possibly for enabling a default check for the function's body schema (if users set up the swagger endpoint for the function).

Let me know your thoughts as to whether you reckon this is worth doing, and if the issue needs updating!

[sfmskywalker]

Hi @BatterySmooth !

Indeed. What might set this feature really apart though from the low level HTTP Request activity is this:

• Each Function would be presented as its own activity from the activity picker. This allows users to simply drag and drop activities to the designer and fill out only the input fields related to the function and not the URL and authentication.
• To achieve this, we would implement a custom IActivityProvider that generates the necessary activity descriptors based of the schema.
• By default, we'd require the developer to setup the necessary connection details like Azure Functions base URL + credentials etc. from e.g. appsettings.json / ENV variables, but a next step could be to leverage the new Connections module, where the user can define the necessary credentials and URLs through the UI. For each connection to an Azure Functions resource, a set of Azure Functions coming from that connection would be made available from the activity picker.

With at least the first two items in place, integrating Azure Functions would be super easy for users to do and a clear advantage over using the lower-level HTTP Request activities.

And perhaps, a future update could leverage the schema to drive intellisense and even JSON schemas to allow users to define variables for inputs and outputs of the appropriate type / schema.

What do you think?

[BatterySmooth]

Hi @sfmskywalker,

Yeah that sounds good! Didn't think about using a custom Activity Provider, nice!

I assume we'll only allow code-authorised functions in the meantime then, and then allow AAD authentication when the new Connections module is implemented?

I can get working on the outline then!

[sfmskywalker]

Yes exactly. Ok, perfect! 🙌🏻
Please let me know if you get stuck with anything or need to discuss etc. etc.
Thanks for taking this on!

[BatterySmooth]

Just to check - I'm assuming that the 'template' activity can't inherit from IActivity then (since that'd get swept up in the base provider)?

[sfmskywalker]

Actually, that should be perfectly fine. All the existing activities are also provided through an activity provider. So, you can totally create a template activity class that implements the necessary logic and input etc, and your activity provider would instantiate this activity and initialize its properties as necessary. You could even implement a fully functioning “invoke azure function “ activity that works as-is, and also have it be used by the provider that adds input descriptors based on the schema of the function.

Take a look at the existing IActivityProvider to see what’s possible.