New to Kestra?
Use blueprints to kickstart your first workflows.
Receive user provisioning requests via webhook, validate payloads in Python, and run PowerShell provisioning steps with automatic retries using Kestra.
Give identity provisioning a real front door. An HR system, ITSM tool, or portal posts a JSON request to a secured webhook; the flow validates the payload, stamps it with a request id, and then executes the provisioning sequence: create the user, assign groups, register the account in the directory graph, and call downstream APIs. The whole provisioning block retries failed steps automatically, which the included addToGraph stub demonstrates by failing twice before succeeding on the third attempt.
user_provisioning_webhook trigger (io.kestra.plugin.core.trigger.Webhook) accepts a POST secured by the IDM_WEBHOOK_KEY secret; a payload JSON input with the same shape supports manual runs and testing.validateRequest task (io.kestra.plugin.scripts.python.Script) parses {{ trigger.body ?? inputs.payload }}, rejects requests missing userPrincipalName or displayName, generates a requestId with uuid.uuid4(), and exposes every field as task outputs.sendEmailProvisionRequest task is a Log placeholder for your notification of choice.provisionUser task (io.kestra.plugin.core.flow.Sequential) wraps the provisioning steps with a constant retry policy (behavior: RETRY_FAILED_TASK, maxAttempts: 5, interval: PT2S), so only the failing step is retried, not the whole sequence.createUser and addToGroup (io.kestra.plugin.scripts.powershell.Script) are stubs for your New-ADUser/Add-ADGroupMember or Microsoft Graph calls; addToGraph simulates a flaky directory API using taskrun.attemptsCount; callProvisionAPIs (io.kestra.plugin.core.http.Request) shows how to hit downstream systems; and sendProvisionDone returns the confirmation with the request id.Identity provisioning scripts tend to fail halfway: the user exists but has no groups, or the license call timed out silently. Kestra's RETRY_FAILED_TASK behavior retries exactly the failed step with its context intact, the webhook trigger provides a secured, standard entry point, payload validation happens before any change is made, and every request is an execution you can search by request id.
IDM_WEBHOOK_KEY: shared key guarding the Webhook trigger.IDM_WEBHOOK_KEY secret to your Kestra namespace.payload to watch validation, retries, and completion.io.kestra.plugin.core.flow.Pause approval gate for privileged groups or license plans.io.kestra.plugin.email.MailSend or Slack.expirationDate by chaining a second flow.concurrency limits and let Kestra backpressure requests.