Onboard

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.
With Wayfinder
5 minOne workflow run creates the cloud account, access, tools and dashboards for a team. Timed on our reference deployment.
acme / Workflow run team-onboard RunTasksAudit
AccountAccessToolsObservabilityReady

Triggered by platform-eng for team payments. Every task runs as sa:team-onboard.

  • Vend the AWS accountacme-payments, Workloads OU, guardrails applied
    1m 12saccount 4417
  • Create the workspace and environmentsdev, staging and prod, with networking and DNS attached
    2m 04s3 environments
  • Scope the team accesspayments-eng from your identity provider, roles per environment
    18sno standing admin
  • Connect the team’s toolsGitHub team, Artifactory repo, Jira project, Slack channel
    41s4 integrations
  • Stand up monitoringDatadog dashboard and monitors from the platform template
    33s9 monitors
  • Publish the catalogueThe plans this team may self-serve, pinned to versions
    11s14 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

acme / payments / Approval cost-control run 88 GateAudit
PlanApproveApply

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 sandbox
    allowed
  • agent/cost-triageopen_pull_request, gated on approval
    held
  • jon@acmeapproved plan, 03:41
    recorded

What this shows

  1. The plan step ran the agent and held the result.
  2. The approval step waits for two people from security-team.
  3. The apply step opens the pull request only after that; the audit shows every step.

Components

Workflow

Triggers plus a graph of tasks, defined as configuration.

WorkflowInvocation

One run and its record.

Tasks

Web API call, agent run, approval, pull request, condition.

Triggers

Webhook delivery, resource events, schedules, manual.

Published workflows

alert-triage, cost-control, file-follow-up, change-approval and more, installable per tenant.

Scopes

Tenant-wide, or owned by one workspace.

Security and governance

Scoped identity

A task acts as the service account you name; a run cannot exceed its author.

Approval gates

Approval gates hold the run until the named people approve.

Per-integration credentials

Outbound calls use the credential of the web API, not a shared secret.

Audit trail

Every run is attributable and replayable.

Automate one runbook.

Start free, install alert-triage, and point a webhook at it.