Change & problem management

Change management

Changes in Zentra are first-class records distinct from regular tickets, with their own model, approval graph, and lifecycle. Open Changes in the agent UI to create, review, and track them.

Lifecycle

Every change moves through a defined sequence:

• draft — change author is preparing the request.
• pending-approval — submitted to the relevant CAB group; approvers are notified.
• scheduled — approved and queued for the implementation window.
• in-progress — implementation underway.
• completed — change finished and validated.
• rejected — turned down at approval; reason captured.
• cancelled — withdrawn before approval or before implementation.

Change Advisory Board

CAB groups are configured under Settings → CAB. Each group has named members (with roles such as technical, business, chair) and a set of approval rules:

• Vote thresholds — minimum approvers needed, or unanimous.
• Quorum — minimum number of members who must respond.
• Expiry — how long an approval request stays open before timing out.

Decisions are captured on ApprovalDecision records and form an immutable audit trail.

Risk scoring

Each change can be scored to drive routing into the appropriate CAB. The risk model considers factors such as:

• Affected configuration items (count and tier from the CMDB).
• Implementer team’s recent change-failure rate.
• Time of day vs. business hours.
• Concurrent changes touching overlapping CIs.

Scoring above your configured threshold routes a change to the senior CAB; below it, a lighter-weight approval path applies. Tune the model under Settings → Change risk model.

Freeze windows

Block changes during sensitive periods (month-end close, customer events, holiday peaks). Configure under Settings → Freeze windows:

1. Set the date/time range and timezone.
2. Choose scope: all changes, or by team / category / risk score.
3. Choose enforcement: warn (CAB can still approve) or block (only emergency changes are accepted).

Submitting a change inside a freeze window surfaces the conflict immediately, with a one-click action to reschedule.

Implementation, validation, backout

Every change record has dedicated fields for:

• Implementation plan — the steps the implementer will take.
• Validation plan — how success will be measured.
• Backout plan — what happens if validation fails.

Approvers see all three on a single screen — typically the first thing CAB reviewers read, and the first thing investigators want during a post-incident review.

Change tasks

Larger changes break down into ChangeTask records, each with its own owner, status, and ordering. The change as a whole completes when all tasks are done.

Problem management

When the same incident recurs, open a problem record. Problems track the underlying cause and link to all related incidents and tickets via ProblemIncidentLink and ProblemTicketLink.

Lifecycle

• open — newly opened, awaiting investigation.
• in_progress — root-cause analysis underway.
• resolved — root cause identified and fixed (typically through a related change).
• closed — final, no further activity expected.

Workflow

1. Open the problem from any incident — Zentra suggests this when it detects clusters automatically.
2. Capture findings on the problem record. Use ProblemNote entries to track the investigation as it unfolds.
3. Link every related incident with ProblemIncidentLink; agents on those incidents see the linked problem inline.
4. Open a change request when remediation requires a planned modification.
5. Close the problem when the underlying cause is fixed.

Every state transition is recorded on ProblemEvent for audit purposes.

Approvals (used by both)

Changes and service requests both use the ApprovalRequest system. Approval requests have:

• Steps — sequential or parallel groups of approvers.
• Decisions — approve / reject with optional comment, captured on ApprovalDecision.
• Expiry — auto-rejection or escalation when no decision in time.
• Notifications — approvers are notified by email and (where configured) Slack or Teams.

Metrics

The reports module surfaces these by default (see Automation for triggers; see the in-app Reports view for visualizations):

• Change failure rate — % of changes that caused an incident or rollback.
• CAB review time — submission to approval.
• Change throughput — completed changes per period, by team.
• Repeat-incident rate — incidents linked to existing problems.

Next

• Asset & CMDB — the configuration items that drive change impact analysis
• Automation — workflows that gate changes and orchestrate approvals
• Webhooks & API — fire outbound webhooks on change events