Editing

The Pipeline Editor is a full-page workspace for editing a pipeline and its child pipelines. It opens each pipeline as a tab, tracks unsaved changes per tab, and hosts an inline debugger so you can test edits without leaving the editor.

A pipeline can be edited as YAML or as a list of processor blocks. The editor is also where a pipeline tree's source control and unit tests live.

Accessing the Editor

note

A pipeline that has a staging version opens read-only here — the editor says so and offers Open staging editor. Make the changes in the staging pipeline's editor and sync them back when you are done.

Navigate to Content Management > Pipelines, select a pipeline, then click Pipeline Editor in the pipeline detail header. The editor occupies the full page, separate from the detail tabs. Editing requires pipeline-edit permission; with read-only permission the editor opens but nothing is editable and no save control appears.

Layout

The editor has a rail, a tab bar, an editor panel, and a dock along the bottom:

• Rail (left, collapsible) — shows one section at a time: the pipeline explorer, Source Control, Merge Requests, or Unit Tests. The editor reopens on whichever section you were last in.
• Tab bar (top) — one tab per open pipeline. A change's diff opens as a tab of its own.
• Editor panel — the active tab's pipeline, in either of two views.
• Dock (bottom, collapsible) — a tab strip carrying the inline debugger, Problems, Recommendations, and Checkpoints.

Editor Views

The Editor view control on the tab strip switches the editor panel between two views of the same pipeline:

View	What you get
Low-code view	A YAML editor
No-code view	The pipeline's processors as a list of blocks, with a properties panel

The choice is a personal preference rather than a property of the pipeline: it is remembered for you across reloads and applies to every pipeline you open afterwards.

Neither view keeps its own copy of the pipeline. The no-code view is handed the same text the YAML editor has and returns whole documents back to it, so switching views mid-edit changes nothing and loses nothing — unsaved edits included.

note

On a narrow screen the switcher is not shown and the editor stays in the YAML view, because the block canvas needs room for a properties panel beside it. Your stored preference is left untouched, so it is still there on a wider screen.

The No-code View

The pipeline's processors appear as an ordered list of blocks, each showing its type, its condition if it has one, and a one-line summary of the option that best says what it does.

• Reorder by dragging a block's handle.
• Add with Add processor, either at the end or between two existing blocks.
• Duplicate or Delete a block from its action menu.
• Select a block to edit its options in the properties panel on the right.

The processor picker lists the catalog alphabetically with sticky letter headings, and its search matches a processor's description as well as its name — so searching for parse returns grok, dissect, kv, csv, syslog, and uri_parts, none of which have "parse" in the name.

The properties panel shows a row per option: the ones the catalog declares for that processor, the universal options every processor accepts, and any other key present in the YAML. That last group matters — an option the catalog does not recognize still gets a row, marked as unrecognized, rather than being dropped when you next edit the block.

Two things the no-code view deliberately will not do:

• A processor it does not recognize is left exactly as written. It is shown as unrecognized, and its configuration is carried through untouched.
• A value it cannot represent is read-only. A YAML alias, a merge key, or a map keyed by something other than a string is shown but not editable, and the block's advanced editing is disabled while one is present — editing would replace the construct with whatever a plain form produced.

If a document does not parse, or is not a top-level processors: list, the no-code view says so and changes nothing. Switch to the YAML view to see and fix it.

Pipeline Tree

The rail's explorer section lists the pipeline hierarchy. The root node is labeled name (root), where name is the main pipeline; each child pipeline appears as a node beneath it. Click a node to open that pipeline in a tab.

Each node provides a copy control and a delete control. Use Add new child pipeline at the bottom of the explorer to create a child pipeline. Toggle the rail with the Collapse sidebar / Expand sidebar control; when collapsed, it reduces to a narrow strip.

Editing Tabs

Opening the main pipeline or a child pipeline adds a tab. The main pipeline's tab is labeled name (Root) and cannot be closed; child tabs show the child pipeline's name and can be closed individually.

A tab with unsaved edits is marked with a dirty indicator in place of its close control. Closing a tab that has unsaved changes opens a Close confirmation prompting Discard and close or Cancel; closing a tab with no unsaved changes closes it immediately.

Editing and Saving

Each tab edits one pipeline's processor configuration, in whichever view is selected. Pipeline and processor syntax is documented in Overview.

Click Save changes to save the active tab. The control is enabled only when the tab has unsaved edits. On save, the editor validates that:

• the configuration includes a name field, and
• the name uses only lowercase letters, digits, and underscores, up to 150 characters.

Saves use optimistic concurrency: if the pipeline was changed elsewhere since you opened it, the save is rejected and you are prompted to retry, so concurrent edits are not silently overwritten.

note

Saving does not change what your directors are running. A save records an uncommitted change, which goes live only once it has been committed and merged — see Source Control.

Child Pipelines

Click Add new child pipeline in the explorer and provide a name to create a child pipeline. The new pipeline is seeded with a starter configuration containing a single comment processor, and opens in its own tab ready to edit.

To remove a child pipeline, use the delete control on its tree node and confirm with Delete (or Cancel). Deleting a child pipeline also closes its tab. Like an edit, a deletion is recorded as an uncommitted change and takes effect on merge.

The Dock

The dock along the bottom collapses to its tab strip and expands into the active tool. Only the active tab is rendered.

Debugger

Click Debug in the editor header to open the inline debugger in the dock. It runs the pipeline against selected test data and reports how each processor transforms it, using the same dataset providers, environment variables, and node status indicators as the standalone debugger. Each editor tab keeps its own debugger state. For full details, see Debugging.

Problems

Syntax diagnostics for every pipeline in the tree, not only the open tabs, grouped by pipeline, each row jumping to the line and column that produced it. Findings are errors or warnings.

Reporting across the whole tree is the point: the problem worth surfacing is usually the one in a child pipeline nobody has opened. A pipeline whose content could not be loaded is listed as not checked rather than counted as clean.

Recommendations

Advisory findings about what will cost you rather than what is broken — per-event work, patterns that behave badly on unusual input, and configuration that will not age well. The rules, their severities, and what makes each one fire are documented in Recommendations.

Checkpoints

Named snapshots of a tab's content that you can return to. Take snapshot captures the active tab; a snapshot can be renamed, restored, or deleted, and Clear all removes every snapshot for the pipeline.

Restoring replaces the tab's content and leaves it unsaved, so you can review the result before committing to it — but anything unsaved at that moment is lost.

warning

Checkpoints are stored in your browser and nowhere else. They are not shared with anyone, do not follow you to another browser or machine, are not backed up, and disappear with your site data. They are not a substitute for source control — use a commit for anything that has to survive or be seen by someone else.

Limits: 50 snapshots per pipeline, about 256 KB per snapshot, and roughly 1 MB in total. Past the total, the oldest snapshots are dropped. A pipeline too large to snapshot is refused rather than allowed to evict your history, and a browser that blocks local storage or has run out of quota reports that instead of failing quietly.

Closing the Editor

Click the close control in the editor header to return to the pipeline detail view. If any open tab has unsaved changes, a Quit Pipeline Editor? confirmation appears, prompting Discard and quit or Cancel before the editor closes.

---