Setting Up Azure Function Lifecycle Actions (LCA) with Microsoft Entra ID Authentication

Overview

Azure Function Lifecycle Actions (LCAs) let you run custom logic in your own Azure environment when specific Reltio events occur (e.g., validating or enriching data on save). This article covers two common points of confusion during setup: the "Create Connection" option in the Console, and LCA execution timeouts.

"Create Connection" shows Azure as unavailable

In Tenant Management → Lifecycle Actions → Create Connection, you may notice Azure is greyed out with a tooltip reading "Not supported yet. Planned for a future release." This is expected — that wizard is a separate, native connection flow that doesn't yet support Azure. It does not mean Azure Function LCAs are unsupported.

Azure Function LCAs with Microsoft Entra ID authentication are fully supported today, but through a different setup path described below rather than that wizard.

Setup Steps

1. Request your tenant-specific Reltio Azure App ID. Submit a Zendesk support ticket requesting the Azure App ID for your tenant and environment. This is a one-time setup per tenant.
2. Create a Service Principal in your Azure AD using the App ID provided:

   az ad sp create --id <reltioAppId>

This requires Global Administrator or Application Administrator rights in your Azure AD.
3. Enable authentication on your Azure Function App:

• In the Azure Portal, go to your Function App → Settings → Authentication.
• Set the Identity Provider to Microsoft, using the existing app registration (the Reltio App ID).

4. Restrict access to Reltio's App ID:
   • Under Additional checks → Client application requirement, select Allow requests from specific client applications, and add the Reltio App ID.
5. Expose an Application ID URI for the app registration (e.g., api://<Your Application ID>), and set that URI as the accepted audience in the identity provider settings.
6. Return your Azure tenant/directory ID and Function App ID to Reltio support so we can complete the configuration on our end.

Note: Azure Function LCAs currently support Java as the only runtime, and use the BinaryJSON protocol for request/response.

Sample code

A sample repository demonstrating LCA logic is available on request — if the linked sample repo in other documentation is inaccessible, contact support and we'll provide the sample code directly.

Troubleshooting timeouts (errorCode 17007)

LCA executions have a configurable timeout enforced on Reltio's side via the tenant's physical configuration. If execution exceeds the configured value, the call fails with errorCode 17007.

Key things to know:

• The timeout budget covers the full round trip — including the HTTP call to your Azure Function and back — not just your function's internal logic time.
• Since Azure Function LCAs run on Java, cold starts on Azure's Consumption plan can take well beyond the default timeout (sometimes several seconds after a period of inactivity). This is often the actual cause of a timeout, not slow function logic.
• Before requesting a longer timeout, test cold-start vs. warm-call latency for your function. If cold starts are the bottleneck, consider Azure's Flex Consumption or Premium plan (which support pre-warmed instances) as a more durable fix than repeatedly increasing the timeout.
• If you still need the timeout adjusted, submit a support ticket with your tenant ID and observed execution times, and we can update it for you.
• For batch updates (e.g., via Data Loader), entities may be sent to your Azure Function in a single batched invocation rather than one call per entity — the timeout applies to the full batch, not per-entity, so design your function to handle multiple entities per invocation.