Documentation

AI Foundry Pipeline Job

The AI Foundry Pipeline Job job type re-runs an Azure Machine Learning Pipeline job in an Azure AI Foundry hub / Azure ML workspace. The imported job is a template run, identified by its job name (stored in External Id). Every execution submits a clone of it — the same step graph (jobs, with their registered components), settings, outputs and experiment — with the task's input values overlaid on the pipeline-level inputs.

This job type is supported on the Azure AI Foundry platform.

Required job fields

  • External Id — the template pipeline job's name (set on import).
  • Job Type — AI Foundry Pipeline Job (set automatically on import).

Optional setting: Compute Name — imported from settings.default_compute; when set it replaces the pipeline's default compute (steps that name their own compute keep it).

Job discovery

GET /jobs?api-version=2026-07-01&jobType=Pipeline     (every nextLink page is followed)

Pipeline steps log to their own child runs, so the importer reads the template's child runs to declare the pipeline's outputs.

Parameter handling

Source on import Polysync parameter Direction
pipeline inputs.<name> (literal or data) <name>, default = the template's value / URI Input
pipeline outputs.<name> <name> Output
MLflow metrics and tags logged by the template's steps <key> Output

Input values are sent as { "jobInputType": "literal", "value": "<text>" }, or as a replacement uri for a data input. An empty value keeps the template's value. Steps receive the values through their ${{parent.inputs.<name>}} bindings.

Direction Sent in inputs Read back after the run
Input ✅ ❌
Output ❌ ✅
Input & Output ✅ ✅

Execution flow

  1. GET /jobs/{externalId} reads the template. If it is missing, the run fails clearly and nothing is submitted.

  2. PUT /jobs/polysync-{guid} submits the clone, minus status, services and system properties, tagged polysync_template. The new name becomes the Polysync RunId.

  3. Status is polled with GET /jobs/{runId}, using the same status table as the Command Job.

  4. When the run ends, times and any failure message come from the run-history API.

  5. On success, outputs are read from:

    • the pipeline run's own MLflow data, then each child step run in start order (the first value for a key wins);
    • the uri of any pipeline output with an explicit path.

    Azure ML can index a step's metrics a few seconds after the pipeline reports Completed. While a declared Output parameter is still missing, Polysync re-reads for up to 30 seconds.

  6. Cancel: POST /jobs/{runId}/cancel.

Monitor URL

https://ml.azure.com/runs/{runId}?wsid=/subscriptions/{subId}/resourcegroups/{rg}/workspaces/{workspaceName}

Best practices

  • Expose everything a task should control as a pipeline input, and bind the steps to it with ${{parent.inputs.<name>}}. Polysync only sets pipeline-level inputs.
  • Give MLflow keys unique names across steps. When two steps log the same key, the earlier step's value wins.

Troubleshooting

  • Status Failed — the message names the failing step's error. Open the Monitor URL for the graph and the step logs.
  • An Output parameter stays empty — no step logged that key, or the output has no explicit path. Azure ML reports no URI for default-path outputs.