Configure process statuses without conflating lifecycles
Tenant administrator or the delegated permissions for the particular Setup action. Some capabilities also require module activation and the applicable operating view.
Tenant status lists can define names, ordering and supported behavioural flags. They do not replace each process's server-side transition, approval or closure rules. Request wrapper state, Requested Item status and Task status are different concepts.
Before you start
Read the applicable process guide and current status list. Identify which lists are configurable and which task lifecycles are fixed. Opening a manager's settings page does not guarantee status-write rights; several domain status endpoints require admin.
Steps
- In Incident & Incident Tasks, review both lists independently. Set the supported open/terminal/pause-clock behaviour and display order for the intended lifecycle.
- In Problem Management, maintain Problem investigation states and review the separately implemented Problem Task rules. Known Error classification is distinct from the main Problem lifecycle.
- In Request Management, maintain the Requested Item status configuration exposed by the process. Do not attempt to use it as a universal editor for Request wrapper states or Request Tasks.
- In Change Management, review Change statuses and exposed approval policies. Check transition guards and task eligibility separately from the visible status name.
- Save the smallest necessary change, then test creation, transitions, cancellation/closure, pause behaviour and reporting using representative records.
- Verify that restricted transitions are still refused and that historical work remains understandable.
Fixed task states and process-specific rules
The LLD documents fixed state sets for Change Tasks and Request Tasks rather than tenant-configurable ticket-status lists. Problem Tasks also have their own implemented lifecycle and closure conditions. Do not infer a task-status editor merely from a generic administration description or an older task-state example.
Default seeding supplies starting Incident, Problem, Request, Change and Incident Task reference states for new tenants. It is not a universal clone of every Setting and does not establish that all tenants should use identical wording.
Catalog location
Service Catalog administration is under Service Portfolio → Service Catalog, rather than the old Request Settings location. Catalog Items define intake, target choices, approvals, fulfilment and Change-link expectations. A required Change link does not prove that Change is approved or completed.
Expected result
Workflow labels and supported flags match operational practice, with each process retaining its own authorization and lifecycle checks.
Important behaviour
Do not assume all workflows share one state machine. Some Asset transitions and reconciliation checks match editable status names; review those separately before renaming Active, Retired or Disposed. Existing SLA measurements are not retroactively rewritten merely because configuration changed.