Pipelines let authorized users design automated workflows for a workspace. A pipeline is made of ordered pipes. Each pipe performs one action, such as validating input, calling an HTTP endpoint, working with entries, or sending an email.
Creating a pipeline
- Open Pipelines from the workspace navigation.
- Click Create Pipeline.
- Enter a slug name, optional description, and status.
- Add pipes to the flow.
- Save the pipeline.
Pipeline statuses are:
| Status | Meaning |
|---|---|
draft |
Being designed and not ready for production use |
active |
Ready to execute |
inactive |
Disabled but retained for reference |
Pipeline designer
The designer shows pipes as a vertical flow. Use the inline add controls to add a pipe before, after, or between existing pipes. Drag pipe nodes to reorder them. Click the edit button on a pipe to open its configuration dialog.
Each pipe has:
| Field | Description |
|---|---|
| Label | Human-readable name shown in the designer |
| Type | The action the pipe performs |
| Enabled | Disabled pipes are skipped during execution |
| Configuration | Type-specific settings |
Pipe types
Validate Data
Validates the incoming payload before later pipes run. The field builder uses the same conventions as content type fields, so validation rules feel familiar.
Supported validation behavior includes required fields, strings, numbers, email addresses, URLs, booleans, arrays, and min/max constraints.
Validate Data can be configured with expected fields instead of raw Laravel validation rules. Expected fields use the shared validation-field schema that hosted forms and content-type-aware workflows rely on, including route-safe field names, supported field types, input types, option lists, date formats, and user-friendly limits.
HTTP Request
Calls an external HTTP endpoint.
HTTP request pipes only call public HTTPS URLs. Your platform may restrict allowed target hosts. Private, local, and reserved IP ranges are rejected.
Configuration includes:
| Field | Description |
|---|---|
| Method | GET, POST, DELETE, PATCH, or PUT |
| URL | Request URL |
| Headers JSON | JSON object of request headers |
| Body JSON or Text | Request body |
HTTP request values can use placeholders from the pipeline context, for example {input.email} or {entry.id}.
Entry Action
Runs an action against entries in a content type.
Supported actions include creating, updating, deleting, fetching one entry, and listing entries. Configure the content type, action, optional entry identifier, and field mapping JSON.
Send Email
Sends an email using the platform mail system.
Configuration includes recipients, subject, and body. Values can use placeholders from the pipeline context.
Transform Data
Maps values from the pipeline context into new output keys. Use this to reshape data between pipes — for example, renaming fields or building a derived value before passing it to a later pipe.
The mapping is defined as a JSON object where each key is the output name and each value is a string that can include context placeholders:
{
"user_email": "{input.email}",
"greeting": "Hello, {input.first_name}"
}
The output of a transform pipe is available to later pipes as {transform.user_email} (or whatever label the pipe is given).
Log Message
Enters a message in the execution output. Useful for marking progress, adding annotations to execution logs, or confirming that a step was reached.
The message field supports context placeholders, for example Processing request for {input.email}.
Log message pipes always succeed and have no side effects.
Testing a pipeline
Open a saved pipeline and use Test Pipeline to enter a sample JSON payload. Test mode runs through the pipeline with dry-run behavior where supported, then shows the per-step result and final context.
Warning: Dry-run support is intentionally conservative. Validation runs normally, while external side effects such as HTTP requests, entry writes, and email sending should remain guarded by the pipeline executor's dry-run handling.
Execution history
Each execution creates a log entry with status, input, result, error message, timing, and duration. Execution history is available in two places:
- History — open from the pipeline context menu on the pipelines index page. Shows the last 50 executions.
- Pipeline designer — the History tab inside the designer shows the last 20 executions for that pipeline.
Trigger from a form
In a form's Settings, set Submit action to Trigger pipeline and select an active pipeline. Map questions to the pipeline's expected fields. The separate Success action can show a message or redirect after the pipeline succeeds.
For a simple copy of each answer, choose workspace or custom email delivery on the form. See Forms.
API execution
Active pipelines can also be executed through the API. API execution resolves the pipeline through the route workspace and returns 422 when execution fails.
POST /api/v1/{workspace}/pipelines/{id_or_name}/execute
See Pipeline API for request and response details.
Related pages
- API Access — API key management.
- Pipeline API — Execute pipelines programmatically.
- Content Types — Content Type and field concepts used by validation and entry pipes.