Documentation

Logic Apps Workflow Job

The Logic Apps Workflow job type triggers an Azure Logic Apps workflow (Standard or Consumption) by POSTing the Polysync parameter object to the trigger's callback URL. The workflow is identified by its name — Polysync stores that in the Job's External Id.

This job type is supported on the Azure Logic Apps platform.

The provider supports both Logic Apps flavours; the Platform's Logic App Type attribute (Standard or Consumption) selects which API path is used.

Required job fields

  • External Id — the workflow name (e.g., OrderApprovalFlow).
  • Job Type — Logic Apps Workflow (set automatically on import).

Job discovery

  • Standard: GET https://management.azure.com/.../sites/{logicAppName}/workflows?api-version=2025-03-01 (with &$expand=definition to pull the trigger schema).
  • Consumption: Azure SDK LogicWorkflowResource (GetLogicWorkflow).

Only workflows whose first trigger is external-callable (Request / Manual / HTTP) are imported — those are the ones with a callback URL Polysync can POST to. The trigger schema's properties become the Job's parameter list.

Parameter handling

The callback URL is fetched on demand:

  • Standard: POST https://management.azure.com/.../workflows/{workflowName}/triggers/{triggerName}/listCallbackUrl?api-version=…
  • Consumption: equivalent SDK call.

Polysync then POSTs a JSON object built from Input + Input&Output parameters to that callback URL:

{
  "<parameter-name-1>": "<value>",
  "<parameter-name-2>": "<value>"
}
Direction Sent in trigger POST Updated from response
Input ✅ ❌
Output ❌ ✅ (stateful only)
Input&Output ✅ ✅ (stateful only)

Values are sent as strings — the trigger's schema in the workflow definition does its own type coercion. Use the Polysync Data Type to help the editor validate values, but expect them to arrive as strings on the workflow side.

Output parameters

  • Stateless workflows: fire-and-forget. Polysync receives the trigger acknowledgement and reports Success immediately; no output parameters are populated.
  • Stateful workflows (both Standard and Consumption): Polysync polls the run by runId and, on completion, reads properties.outputs. Any top-level property whose name matches a Polysync Output / Input&Output parameter is written back (case-insensitive).

Execution flow

  1. Polysync fetches the trigger callback URL (with a short-lived SAS signature in the URL itself), then POSTs the parameter body.

  2. For stateless workflows the call returns 200 with no run id — Polysync records Status = Success and returns.

  3. For stateful workflows the call returns 202 with a runId (in the response body or Location header). The composite RunId is "{workflowName}/{runGuid}".

  4. Status polling:

    • Standard: GET https://management.azure.com/.../workflows/{workflowName}/runs/{runId}?api-version=2022-09-01
    • Consumption: SDK GetLogicWorkflowRun(runId).

  5. Status decoding (properties.status):

    Logic Apps status Polysync status
    Succeeded / Success / Completed Success
    Failed / Failure / Error / Aborted / TimedOut / Timeout Failed
    Cancelled / Canceled / Skipped Cancelled
    Running Running
    Started / Starting Starting

  6. Cancel is supported for both flavours:

    • Standard: POST .../workflows/{workflowName}/runs/{runId}/cancel?api-version=2022-09-01
    • Consumption: run.Cancel().

Monitor URL

  • Standard: deep link to the WorkflowMonitorBlade with the run path, location, and run properties encoded as URI fragments.
  • Consumption: https://portal.azure.com/#blade/Microsoft_Azure_EMA/LogicAppsMonitorBlade/runid/{escapedRunResourceId}

Best practices

  • Build the workflow's trigger with a JSON schema (Request trigger → Use sample payload to generate schema) so the import populates a real parameter list rather than an empty schema.
  • Use stateful workflows when you need outputs back in Polysync — stateless workflows return no run details.
  • Store any non-trivial logic inside the workflow; the Polysync Workflow Job is just the front door (trigger payload + status).

Troubleshooting

  • Trigger '{name}' is not callable on Execute — the workflow's first trigger is not a Request / Manual / HTTP trigger. Replace the trigger or remove the workflow from Polysync.
  • 401 / 403 fetching the callback URL — the Polysync identity is missing Microsoft.Logic/workflows/triggers/listCallbackUrl/action (Standard) or the equivalent Consumption permission. Grant Logic App Contributor.
  • Outputs not populated for a stateful run — confirm the workflow finishes with a Response action whose body is a JSON object, and that the parameter names in properties.outputs match the Polysync parameter names (case-insensitive).