Objects
Pipelines & stages
Configure object pipelines, stages, movement rules, and record stage history.
Pipelines & stages
Pipelines & stages covers stage-based lifecycle configuration for object records and tickets, including transitions, stage history, and stage-driven reporting. Use this page when you are setting up the product surface, reviewing a rollout, or troubleshooting why users see a different result from an administrator.
What this surface is
- Primary purpose: stage-based lifecycle configuration for object records and tickets, including transitions, stage history, and stage-driven reporting.
- Where users start: Object pipeline settings are configured from
/settings/objects/:objectId/object-settings; ticket pipelines live under/tickets/settings/pipelines. - Where administrators configure it: Ticket pipeline stages use
/tickets/settings/pipelines/:pipelineId/stages; record history appears on record detail pages. - Runtime/detail surface: Pipelines show where work sits, who owns the next action, and how long records spend in each stage.
- Platform connections: Pipelines connect records, tickets, workflows, notifications, quick actions, reports, and dashboards.
Where it lives
| Area | Path or surface | Use it for |
|---|---|---|
| User surface | Object pipeline settings are configured from /settings/objects/:objectId/object-settings; ticket pipelines live under /tickets/settings/pipelines. | Day-to-day work and review. |
| Configuration | Ticket pipeline stages use /tickets/settings/pipelines/:pipelineId/stages; record history appears on record detail pages. | Setup, permissions, routing, labels, and behaviour. |
| Runtime/detail | Pipelines show where work sits, who owns the next action, and how long records spend in each stage. | Testing the live experience users actually see. |
Configure it
- Confirm the audience for this surface and whether they are staff users, portal users, customers, public visitors, or administrators.
- Open the owning product route: Object pipeline settings are configured from
/settings/objects/:objectId/object-settings; ticket pipelines live under/tickets/settings/pipelines. - Review the configuration route and permissions before changing live behaviour: Ticket pipeline stages use
/tickets/settings/pipelines/:pipelineId/stages; record history appears on record detail pages. - Define the primary records, fields, statuses, owners, and notifications involved in this workflow.
- Configure Object pipeline, Ticket pipeline, and Stage history first because they shape the rest of the rollout.
- Add Stage automation and SLA/reporting only after the core path works with sample data.
- Test the runtime surface as a restricted user, not only as a superadmin: Pipelines show where work sits, who owns the next action, and how long records spend in each stage.
- Check downstream connections after saving: Pipelines connect records, tickets, workflows, notifications, quick actions, reports, and dashboards.
- Record the owner, rollout date, and support path for the configuration.
- Review the first week of activity and remove any option that users do not understand or need.
Configuration options
| Option | Use when | Notes |
|---|---|---|
| Object pipeline | Dynamic records need lifecycle tracking | Configure in object settings. |
| Ticket pipeline | Support queues need stages | Configure under ticket settings. |
| Stage history | Teams need audit of movement | Review on record or ticket detail. |
| Stage automation | A transition should trigger work | Use workflow triggers or quick actions. |
| SLA/reporting | Time in stage matters | Build reports and charts. |
| Multiple pipelines | Different processes share one object | Use only when stages truly differ. |
Operating notes
- Keep labels aligned with the words users see in the product, especially Object pipeline and Ticket pipeline.
- Permissions still matter even when a menu, page, or link is visible.
- If users see empty data, check role filters, enabled apps, ownership rules, and saved filters before editing records.
- If a change affects customers or public visitors, test from a logged-out or customer account as appropriate.
- Use reports or logs to confirm the change produced the expected operational result.
- Capture configuration decisions in rollout notes so support teams know what changed.
- Do not reuse one option for unrelated processes just because it is already configured.
- Review linked notifications, workflows, dashboards, and reports after changing this surface.
- Prefer narrow changes that can be tested with sample data before a tenant-wide rollout.
- When troubleshooting, start at the route users open, then inspect configuration, permissions, and logs in that order.
- Keep retired settings hidden or archived so users do not choose outdated paths.
- Assign an owner for ongoing review; unattended configuration becomes stale quickly.
For developers
Use these pages when the surface is read or changed by code, scripts, embeds, widgets, API clients, webhooks, or realtime listeners.