Nodes
Nodes are the building blocks of a workflow. You connect them to define how a run starts, what it does, and how it branches.
This section covers every node type: triggers, actions, conditions, and inputs. For how nodes fit into the wider workflow model (connections, outputs, and JSON structure), see concepts and structure.
How to choose a node type
Use these guidelines as a starting point:
- Choose a trigger when you need an entry point that starts the workflow:
- Self-service trigger for manual runs.
- Event trigger for catalog changes.
- Schedule trigger for cron-based runs.
- Choose an action when the workflow should perform work, such as calling an API, updating the catalog, publishing to Kafka, invoking AI, or running an integration action.
- Choose a condition when you need automatic branching based on data already in the run, without waiting for a person.
- Choose an input when you need a human-in-the-loop step such as an approval, manual gate, or decision that requires a response before the run continues.
Node types
There are four node types. A workflow can mix them freely, and can define more than one trigger.
| Node type | Description |
|---|---|
| Trigger | An entry point that initiates the workflow. Can be a self-service trigger (manual execution), an event trigger (automated based on entity changes), or a schedule trigger (automated on a cron schedule). A workflow can have multiple triggers. |
| Action | Performs an operation such as sending a webhook, upserting an entity, publishing to Kafka, triggering an integration action, or invoking AI. See action nodes. |
| Condition | Evaluates expressions and routes the workflow to different branches based on the results. See condition nodes. |
| Input | Pauses the workflow and waits for a human response before continuing. Use for approvals, manual gates, and decision points. See input nodes. |
Triggers
Trigger nodes are the entry points of a workflow. Only the trigger that fired produces outputs for that run. You can reference those outputs with the trigger's node identifier, or with .outputs.trigger as an alias for the active trigger.
| Trigger | When to use it |
|---|---|
| Self-service | A user starts the workflow from the self-service hub, an entity menu, the API, or as an MCP tool. |
| Event | An entity is created, updated, or deleted in the catalog, or a timer property expires. |
| Schedule | A recurring cron expression should start the workflow. |
You can mix trigger types in the same workflow so one automation serves a form, a catalog event, and a schedule. For how multiple triggers share outputs, permissions, and testing, see multiple triggers.
Actions
Action nodes run after a trigger (and after any conditions or inputs that lead to them). They share common fields such as identifier, title, variables, links, and onFailure. See configuration and outputs for the shared reference.
| Action | What it does |
|---|---|
| Webhook | Sends an HTTP request to an external endpoint, synchronously or asynchronously. |
| Upsert entity | Creates or updates an entity in your software catalog. |
| Kafka | Publishes a message to Port's dedicated Kafka topic for your organization. |
| AI | Invokes Port AI or an AI agent and resumes when the invocation completes. |
| Integration actions | Runs operations in connected tools (for example GitHub, Jira, or PagerDuty) using your installed integrations. |
| Port execution agent | Routes a webhook action into your private network without exposing a public endpoint. |
Conditions
Condition nodes add automatic branching. Each condition defines one or more outlets with JQ expressions. Port evaluates the expressions against the workflow run context and continues down the first matching path, or a fallback connection if none match.
Unlike input nodes, conditions do not pause the run or wait for a person. For configuration, outlets, and examples, see condition nodes.
Inputs
Input nodes pause a branch of the workflow and wait for responders. Use them for approvals, manual gates, and decisions that need a form response.
When the run reaches an input node, Port notifies the configured responders. The node completes when an outlet reaches its required number of responses, then continues down that outlet's path. For configuration, outlets, notifications, and examples, see input nodes.
Next steps
- Self-service trigger - Create workflows triggered by users.
- Event trigger - Create workflows triggered by entity changes.
- Schedule trigger - Create workflows triggered on a cron schedule.
- Action nodes - Perform operations such as webhooks, catalog updates, and AI.
- Integration actions - Run operations in connected tools such as GitHub, Jira, and PagerDuty.
- Condition nodes - Branch a workflow based on JQ expressions.
- Input nodes - Pause a workflow for approvals and human decisions.