Skip to main content
The Details panel is where you manage the identity and metadata of a journey: its name, description, owner, tags, and version information. This is identification and organization, not execution configuration — the Details panel doesn’t affect how the journey runs.

​
When to use it

Open the Details panel when you need to:
  • Rename a journey or update its description.
  • Assign or change the journey owner.
  • Add or update tags for discoverability and organization.
  • Check version information for the journey.

​
Key concepts

  • Name — the primary identifier for the journey in the UI, CLI, and reports. Names should be clear and consistent — teams often use them in CLI commands and CI configurations.
  • Description — a short explanation of what the journey tests or validates. Helps teammates (and future you) understand the journey’s purpose at a glance.
  • Owner — the person or team responsible for the journey. Ownership is separate from access control — the owner is a metadata label, not an access role, though owners typically have editor or manager access.
  • Tags — arbitrary labels for grouping and filtering. Useful for organizing journeys by service, team, feature, or lifecycle state (e.g., payments, auth, regression, wip).
  • Version info — details about the journey’s current version. See Versioning and artifacts for how versions work and how they relate to build artifacts.

​
How it works

Open the Details panel from the Build-mode panel rail. All fields are editable inline. Name and description are free-form text. Keep names consistent with how you refer to the journey in other tools — CLI commands use the journey identifier, but readable names appear everywhere else. Tags are added or removed via the tag input. They have no enforced taxonomy, so it’s worth agreeing on a tagging convention with your team. Owner is selected from your organization’s user/team list. A journey can have one owner at a time. Version info is read-only in this panel. It reflects the current state of the journey definition. When a journey is compiled for a run, a build artifact is created — see Versioning and artifacts for details.
Tags and descriptions are the first things teammates see when browsing journeys. A clear description and a consistent set of tags make the library much easier to navigate as it grows.

​
Examples

A well-filled Details panel for a payment journey:
FieldValue
NameCheckout — standard card payment
DescriptionValidates the end-to-end checkout flow for a standard credit card payment, including fraud check and confirmation email trigger.
Owner@payments-team
Tagspayments, checkout, regression, p0

Access

Control who can edit and view the journey.

Versioning and artifacts

How journey versions and build artifacts work.

Build mode

Overview of Build-mode panels.

Admin: users and access

Manage users and organization-wide access settings.