Onboard a team with one workflow.
A workflow is a trigger and a set of tasks, and every run is recorded. Onboard a team across every tool you run, or call an API, run an agent and wait for an approval.
Free forever plan, no commitment, in your own cloud account.
Built from the real interface. Open the workflows view in the live demo. No sign-in.
- Today
- 1 day or more78% of engineering teams wait this long for help from the platform team.Port, State of Internal Developer Portals, 2025
78% of engineering teams wait a day or more for SRE/DevOps assistance; Only 22% report getting issues resolved within one day; 16% experience maximum wait times of a week or more
Engineering teams surveyed by Port; sample size not published on the page - With Wayfinder
Wayfinder timings are from our reference deployment and demo flows, not from customer studies.
- 5 minOne workflow run creates the cloud account, access, tools and dashboards for a team. Timed on our reference deployment.
Triggered by platform-eng for team payments. Every task runs as sa:team-onboard.
- Vend the AWS accountacme-payments, Workloads OU, guardrails applied1m 12saccount 4417
- Create the workspace and environmentsdev, staging and prod, with networking and DNS attached2m 04s3 environments
- Scope the team accesspayments-eng from your identity provider, roles per environment18sno standing admin
- Connect the team’s toolsGitHub team, Artifactory repo, Jira project, Slack channel41s4 integrations
- Stand up monitoringDatadog dashboard and monitors from the platform template33s9 monitors
- Publish the catalogueThe plans this team may self-serve, pinned to versions11s14 plans
Team ready in 4m 59s. Six tasks, one record, repeatable for the next team.
Before and after
Before
- Runbooks that people follow by hand
- Glue scripts on a server someone owns
- Automations nobody can trace after the fact
- Approvals by chat message
- The same fix repeated across teams
With Wayfinder
- Triggers on webhooks, resource events, schedules or by hand
- Tasks as configuration, no controller to write
- Every run kept: what fired it, what each task returned
- Approval gates anywhere in the graph
- Published workflows every team installs
How it works
Trigger
A webhook delivery, a resource created or changed, a schedule, or a person.
Tasks
Call a web API, run an agent, wait for approval, raise a pull request. Outputs thread into the next task.
Record
The run is a resource: open it, read each task, replay it.
What a workflow looks like
The onboard-team workflow that ships in the catalogue, trimmed. The comments are from the file.
# Onboard a team: invite their lead, then create their workspace.
#
# Shipped as a catalogue entry, so this is the shape a published workflow takes.
# It uses only `wf/...` tasks, which means it depends on no integration, agent or
# MCP and installs cleanly into any tenant.
#
# Every value it needs is answered when somebody runs it.
apiVersion: orchestration/v3
kind: Workflow
metadata:
name: onboard-team
spec:
description: Invites a team lead and creates their workspace, tolerating a failed invite.
suggestedRoles:
- tenant.manager
triggers:
- name: run
manual:
inputs:
- name: workspace
description: Name of the workspace to create for the team.
- name: email
description: Email address of the team lead to invite.
- name: role
description: Tenant role a team lead is invited with.
defaultValue: tenant.member
tasks:
# Best-effort. An address can be wrong, or the person may already be a member,
# and neither is a reason to leave the team without a workspace.
invite_lead:
action: wf/invite/user
continueOnFailure: true
with:
name: '${{ .Inputs.email }}'
role: '${{ .Inputs.role }}'
# The point of the whole thing, and it runs either way.
provision:
dependsOn: [invite_lead]
action: wf/create/workspace
with:
name: '${{ .Inputs.workspace }}'
description: 'Onboarded by the onboard-team workflow'
In the product
Right-size api from 6 to 3 replicas. Saves 34% on the flagged service. Needs 2 of 2 approvals from security-team.
- agent/cost-triageread_metrics, list_resources, as sa:cost-triage, in its own sandboxallowed
- agent/cost-triageopen_pull_request, gated on approvalheld
- jon@acmeapproved plan, 03:41recorded
What this shows
- The plan step ran the agent and held the result.
- The approval step waits for two people from security-team.
- The apply step opens the pull request only after that; the audit shows every step.
Components
Triggers plus a graph of tasks, defined as configuration.
One run and its record.
Web API call, agent run, approval, pull request, condition.
Webhook delivery, resource events, schedules, manual.
alert-triage, cost-control, file-follow-up, change-approval and more, installable per tenant.
Tenant-wide, or owned by one workspace.
Security and governance
A task acts as the service account you name; a run cannot exceed its author.
Approval gates hold the run until the named people approve.
Outbound calls use the credential of the web API, not a shared secret.
Every run is attributable and replayable.
Automate one runbook.
Start free, install alert-triage, and point a webhook at it.