Documentation

Azure Functions

Required attributes

  • Subscription Id — the Azure subscription containing the Function App.
  • Resource Group Name — the resource group containing the Function App.
  • Function App Name — the Function App resource name (used for discovery and management-plane calls).
  • Function App URL — the host the HTTP trigger is invoked on, without the scheme (e.g. myapp.azurewebsites.net). Polysync builds the invoke URL as https://{Function App URL}/api/{route-or-function-name}.

Function Key is optional: set it only when the Authentication Method is Function Key. It is sent as the x-functions-key header on invokes when present and ignored otherwise — store it in a Secret Vault and reference it rather than entering it directly.

Management operations vs execution

The three identity-based auth methods (Polysync Service Principal, Service Principal, Certificate) can perform management operations — list/import functions (Get Jobs), Sync Parameters and Test Connectivity — because they can obtain a management-plane (ARM) token.

Function Key and Anonymous are execution-only: they have no ARM credential, so Get Jobs, Sync Parameters and the platform-job dropdown are unavailable and Test Connectivity fails by design with:

Function Key and Anonymous authentication cannot be used for management operations. Use Service Principal, Certificate, or Polysync Service Principal authentication to manage Azure Function App via the Management API.

Executions (Execute Now and scheduled runs) still work on those platforms — create their jobs manually (name → platform → job type → External Id). Their Test Connectivity runs an invoke-path reachability probe instead of the management check: any HTTP response from the app host — even 401/404 — proves DNS/TLS/host reachability before the first run.

Authentication methods

  • Polysync Service Principal ⭐ (recommended) — no extra attributes; ensure the Polysync Enterprise Application has access to invoke the Function App via Entra ID authentication.
  • Service Principal — Tenant Id, Client Id, Client Secret. Use when you need a dedicated SPN per app. Rotate the secret regularly.
  • Certificate — Tenant Id, Client Id, Certificate (base64 or path), optional Certificate Password and Certificate Thumbprint. More secure than a client secret.
  • Function Key — Function Key (host or per-function key). Simple but bypasses Entra ID; rotate when leaked. Execution-only — no Get Jobs or Sync Parameters; Test Connectivity probes the invoke path instead. Use a host/master key if this platform must run non-HTTP functions on demand.
  • Anonymous — no authentication; the function endpoint must not require a key. Suitable only for development or internal-only functions. Execution-only — same management-plane limits as Function Key.

Permissions checklist

  • Identity-based auth requires the identity to hold Reader on the Function App — sufficient for the management reads (list functions) and for invoking Entra-authenticated functions (verified live 2026-09-29; an App Service Authentication configuration accepting Entra tokens is still required for the invoke itself).
  • For Function Key auth, store the key in a Secret Vault and reference it rather than pasting it into the Platform attributes.

Why no Managed Identity?

Polysync's multi-tenant SaaS runs in its own Entra tenant, and a managed identity is bound to the customer's tenant — it cannot be assumed trans-tenant. The product's identity story is the Polysync Service Principal, which the customer grants per resource; Service Principal and Certificate cover the customer-managed alternatives. A Managed Identity Client Id attribute that older environments may still show has been removed by migration 014_Remove_AzureFunctions_ManagedIdentityClientId_Attribute.sql.

On-demand (non-HTTP trigger) functions

Timer, queue, blob, Event Hub and Service Bus triggered functions are discovered alongside HTTP triggers and can be run on demand through the Functions admin API (POST /admin/functions/{name}). Polysync resolves a job's trigger from the function's bindings at dispatch on management-capable auth methods; execution-only platforms fall back to the job's HTTP Method attribute. Two things to know:

  • the admin namespace requires a host or master key — set the platform's Function Key attribute to one, or use a management-capable auth method so Polysync fetches the master key automatically;
  • on-demand runs are fire-and-forget: the host acknowledges with 202 and no output values are returned. Track the run in the Function App's portal run history (the job's Monitor link opens the function page).

Orchestration triggers cannot be invoked directly — start them through your Durable client (HTTP starter) function, which returns the statusQueryGetUri protocol Polysync polls. A running Durable orchestration can be terminated by the provider (Durable HTTP management API); the operator-facing Cancel wiring is still pending platform-wide (ENH-050).

Supported jobs

Azure Functions exposes a single Polysync job type. See the dedicated page for parameter handling, output binding, execution flow, monitor URL, and troubleshooting: