Workflows & tools
Shipping and operating software rarely breaks at the pipeline. It breaks in the space around it: finding the owner, pulling context from five tools, chasing an approval in Slack, and remembering the step that lives only in someone's head.
Workflows are Port's system of action for that space. One governed execution layer, shared by humans, automation, and AI agents. The workflow a developer triggers from the self-service hub is the same workflow an agent invokes as an MCP tool: same logic, same permissions, same audit trail.
💡 Don't have a Port account yet? Sign up for freeWhat you can build
Workflows cover three broad patterns:
- Self-service - Give developers a governed form to request infrastructure, deployments, or any other operation, with built-in approvals and guardrails. For example, scaffold a new service or promote a version to production.
- Automate a process - React to catalog events to enforce policies, send notifications, or keep data consistent without human intervention. For example, open a Slack channel for every new incident or nudge reviewers on stale pull requests.
- Agent tool - Expose a workflow as an MCP tool so AI agents can invoke governed operations autonomously. See expose workflow as a tool.
Most real workflows mix all three. A self-healing incident flow starts from an event, hands diagnosis to an agent, pauses for a human to approve the remediation plan, then runs the fix and posts the result back to the incident channel.
Browse more examples, or start from our guides.
The business orchestrator above your tools
Workflows do not replace the systems you already run - CI/CD pipelines, cloud provider APIs, ticketing and incident management tools, monitoring, AI agents, or the scripts your team wrote years ago. They orchestrate the business process around all of them, then hand each technical step to whichever system already does that job.
| Layer | Who owns it | What it does |
|---|---|---|
| Business workflow (Port) | Platform, SRE, and app teams | Fetches context, scores risk, collects approvals, invokes agents, notifies people, updates the catalog. |
| Execution systems (your existing tools) | The teams that already run them | Build and deploy, provision infrastructure, page on-call, open tickets, run the job. |
A release workflow can start from a merged pull request, pull the service's owners and dependencies from your Context Lake, branch on how risky the change is, pause for the team lead's approval, then trigger the deploy job in the pipeline that already exists. An access request follows the same shape, with your cloud provider and ticketing system doing the technical work instead.
Developers see one governed step-by-step run instead of five browser tabs.
Why teams build on workflows
| Capability | What it means in practice |
|---|---|
| Agentic-native | AI is a node type, not an integration project. Drop Port AI, Claude, or Cursor agents into any step, and expose the workflow back to agents as a governed MCP tool. |
| Human-in-the-loop anywhere | Pair any step, automated or agentic, with an input node: review the agent's plan, the diff, and the rollback target as separate gates. Each review carries its own context and is recorded on the run. |
| Catalog-aware by default | Every step can read your services, owners, dependencies, and environments through data flow, so an incident workflow knows who to page before it pages anyone. |
| Forms that know your org | User inputs compute from the catalog, the user, and other fields - entity dropdowns, conditional visibility, and validation with custom error messages. |
| Dynamic permissions | Who can trigger and who can approve is composed from catalog context, user, and form values, not a static role list. "Only the owning team can deploy this service" is a rule, not a convention. |
| Built for many builders | Platform engineering is not the bottleneck for every automation. Workflows are catalog entities with team ownership, so each team ships what it knows best against shared context and governance. |
| Composes with your stack | A growing set of native nodes, including GitHub, GitLab, Azure DevOps, Jira, and more, with webhooks, Kafka, and the Port execution agent covering everything else. See all action nodes. |
| Safe to change | Test a workflow before you publish it, and track every run step by step, with logs, once it is live. |
The engine
Every workflow is a directed graph of nodes connected by edges. Nodes are either triggers (entry points), actions (operations), or conditions and inputs (branching logic). Edges define execution order and pass data between steps.
For a full breakdown of node types, data flow, and JSON structure, see concepts and structure.
Trigger types
A workflow can be entered from any of four trigger types, and a single workflow can define multiple triggers. You build a workflow once and it is invokable from everywhere - one definition serves a developer, a catalog event, and an agent at the same time.
| Trigger | When it fires |
|---|---|
| Human form | A user submits the self-service hub form or calls the API directly. See self-service trigger. |
| Catalog event | An entity in your software catalog is created, updated, or deleted. See event trigger. |
| Agent tool | An AI agent invokes the workflow via the Port MCP server. See expose workflow as a tool. |
| Schedule | A time-based rule fires on a recurring interval or cron expression. See schedule trigger. |
Whichever entry point fires, the same nodes execute, the same permissions are checked, and the same run record appears in the audit trail. Every action an agent can take is explicitly defined, governed, and observable, rather than a separate automation path that bypasses your controls.
Actions & automations is Port's legacy execution system. It remains fully supported. For new work, workflows offer multi-step logic, agent tool invocation, human-in-the-loop steps, and a richer trigger model. Once your organization runs on workflows only, an admin can hide actions & automations across the UI.
Next steps
- Quickstart and build with AI - Build your first workflow in a few minutes.
- Concepts and structure - Learn about workflow components and structure.
- Expose workflow as a tool - Make workflows invokable by AI agents through the Port MCP server.
- Interact with runs - Monitor and manage workflow executions.
- Workflow catalog and ownership - Assign team ownership to workflows and control access via the
_workflowblueprint. - Examples - See real-world workflow examples.