Skip to main content

Workflows

๐Ÿ“„๏ธ Retry the failed steps of a failed execution

Creates a new execution that re-runs only the action nodes that failed (and the ones skipped because of that failure) against the original execution's data items; succeeded steps are not repeated. The new execution has `trigger.kind: retry` and `retry_of` set to the root of this execution's retry chain (this execution's ID, or its own `retry_of` when this execution is itself a retry). Only executions with status `failed` are retryable, and only while the workflow is active; a second retry while one is still running is refused with `409`.

๐Ÿ“„๏ธ Catalogue of JML steps available per connected platform

Returns, for every connection a JML step can act on, the step kinds it supports โ€” derived from the registered remediation recipes and provisioning targets, so the palette only offers what the engine can dispatch. Each entry maps directly onto a `JMLStep`: `type`, and for grant/revoke the `granting_type`, for provision the `target`, for notify the `channel`, for ticket the `provider` โ€” plus the `phases` it may be authored in and the `params` its recipe reads. The response also carries the notify channels and ticket providers the compiler accepts, so the builder never keeps its own copy of either list. `builtin_steps` publishes the output descriptors of the step kinds that never appear under a connection (ticket, webhook) โ€” one entry per (type, provider) pair, so the builder never keeps its own copy of what those steps produce either.