Access Control & Approval Gates for Workflows
Decide who can trigger a workflow and who has to sign off before it runs. Add approval gates that pause a workflow until someone approves — in the platform, in Slack, or by merging a pull request.
Automation is only as safe as its guardrails. The moment a workflow can restart a deployment, open a pull request, or provision cloud infrastructure, two questions matter more than anything else: who is allowed to trigger this, and who has to sign off before it runs.
Today we're adding both to Kestrel Workflows. You can now scope who is allowed to trigger a workflow, and drop approval gates anywhere in a workflow that pause execution until the right people approve — from the platform, from Slack, or by reviewing and merging a pull request.
Who can trigger a workflow
For on-demand developer request workflows — the ones your team kicks off themselves rather than ones that fire on an infrastructure signal — you can now restrict exactly who is allowed to run them. On the request trigger, two dropdowns control access:
- Allowed Users
Restrict the workflow to specific people. Leave empty to allow all users.
- Allowed Groups
Restrict the workflow to one or more groups from your organization. Leave empty to allow all groups.
Define and manage your groups in the User Groups tab of the Organization Management page, then reference them here to grant a whole team access at once.
You can layer these with the request's own scoping — Allowed Clusters, Allowed Namespaces, Allowed AWS Accounts, Allowed Zones, and more — so a self-service workflow can be safely opened up to a team while still being fenced into the exact resources they're permitted to touch.
Approval gates, three ways
Drag an Approval Gate block onto the canvas anywhere you want a human in the loop. The block pauses the workflow and branches into two paths — Approved and Rejected — so you decide what happens next in either case. Pick one of three approval types:
Manual (In-App)
Pause until an authorized user approves in the Kestrel dashboard. Best for changes your platform team should green-light from one place.
Slack
Send an interactive request to a Slack channel — your team clicks Approve or Reject right where they already work, no context-switch required.
PR / MR Approval
Tie the gate to a pull request. The workflow continues when the PR is approved or merged, and stops if it's closed — so your existing code-review process becomes the approval step.
Define exactly who must approve
For manual and Slack gates, the Require Approval From editor lets you build approval rules out of individual users and groups. By default, anyone in the org can approve. Add people or groups to a rule and all of them must approve; add a second rule and either rule can satisfy the gate. That gives you everything from "any platform admin" to "both the on-call lead and a security reviewer."
PR-based approvals, in detail
Many platform changes already flow through GitHub or GitLab, so it makes sense for the merge to be the approval. Kestrel supports both behaviors:
- Wait for PR/MR Approval — the gate resolves when the pull request is approved via review.
- Wait for PR/MR Merge — the gate resolves when the pull request is merged.
Merging a PR approves the step; closing it without merging rejects it. These gates are webhook-driven, so the workflow resumes the moment the event lands in GitHub or GitLab — no polling, no manual nudging.
Every blocked run, in one place
The Pending Approvals page collects every execution that's waiting on a human across your whole organization. Each row shows the workflow, the approval type, the required approvers, and how long it's been waiting.
From here you can Approve or Reject manual and Slack gates directly, View Execution to see the full run for context, or — for PR gates — Review PR to jump straight to the pull request. A Recent Approvals section keeps an auditable history of who approved or rejected what, and when.
Role-based by default
Building, activating, and approving workflows is scoped to your platform administrators, while app developers get a focused view for submitting developer requests — governed by the Allowed Users and Allowed Groups rules above. So you can safely open self-service automation to your whole engineering org without handing everyone the keys to production.
Getting Started
Open any workflow in the builder, drag an Approval Gate into the graph, choose a type, and wire up the Approved and Rejected paths. For access control, open a developer-request trigger and set Allowed Users and Allowed Groups. Slack-based gates require a connected Slack workspace; PR-based gates require a connected GitHub or GitLab repository.