This article shows SysAid Change Management in action, following one change from the incidents that triggered it to its closure. It assumes your Change Management process is already set up. If it isn't, start with Setting Up Change and Problem Management, and see the Change and Problem Management Overview for the concepts and roles that appear throughout this story.
Available for:
Customers using SysAid Spaces. If you're using SysAid Classic, see Example of a Change from Start to Finish (Classic).
The scenario
Your company's ancient production server hosts several business applications, and lately it has started to act its age. Over the past two weeks, the service desk has received a steady stream of incidents:
One team reports that their reporting tool freezes.
Another can't reach the CRM.
A third sees intermittent timeouts.
Different symptoms, same server. The time has come to upgrade it. A production server upgrade is a significant change with real risk, downtime that needs a maintenance window, data that needs backing up, and decisions that need sign-off, so it runs through your predefined change process in SysAid.
The people in this story:
Alexander, a SysAid Administrator, oversees the change process. The SysAid Administrator permission grants every permission in SysAid, including Change Manager, so he can build templates, edit any action item, and manage the process end to end.
John, a regular Admin, implements the upgrade. He has no special change permissions; he participates through the action items assigned to him.
Maya, the CFO, sits on the CAB. She's an End User in SysAid and participates from her email and the Self-Service Portal.
Ami, an End User whose reporting tool keeps freezing, usually right before a deadline. She opened one of the incidents.
The incidents that started it
It begins in the service record queue, where the server's symptoms have been piling up as separate incidents.
Individually, each incident looks routine. Together, they point at one root cause. The Detect Problem from Incidents AI agent clusters the incidents and recommends creating a problem, so Alexander does: the Create Problem with Related Incidents AI agent creates a new problem with an AI-generated title, description, and category, and automatically links the three incidents to it.
.gif?sv=2026-02-06&spr=https&st=2026-07-29T02%3A44%3A12Z&se=2026-07-29T03%3A01%3A12Z&sr=c&sp=r&sig=S5Is%2BSk60Y%2FpwpSYWTvebEoi4pYOv4y3gU64jPZZu9s%3D)
A quick investigation follows. The Problem Analysis Assistant AI agent runs a root cause analysis on the problem and posts its findings: the production server is failing under load as it nears end of life, and the fix is a hardware upgrade.
With the root cause identified, the next step is clear: the production server needs to be upgraded. That's a significant, risky change, so it runs through your predefined change process in SysAid.
Please note:
Neither an incident nor a problem can be converted into a change. Instead, you create the change separately and link the problem, and its incidents, as related items.
Creating the change
Alexander creates the change:
He clicks Create at the top of the page (available from any page in SysAid), selects Change as the record type, and picks the Production Server Upgrade template his team built in the Workflow Designer.
He fills in the change details: what's being upgraded, why, and the target timeline, and saves the record.
From the change's Related Items tab, he links the problem investigation and the three incidents that led here, including Ami's, so the whole history, from incidents to root cause to fix, stays connected.
The template already includes the workflow the team configured for it, and it activates the moment the change is created: the first phase's independent action items open, and their Assignees are notified. From this point on, the change largely runs itself; Alexander's job is to keep it moving, and everyone else's job arrives as an action item.
Assessing the risk
The first phase is assessment. An action item assigned to Alexander asks for a risk evaluation, and this is where SysAid Copilot earns its keep: the Assisted Change Risk Scoring AI agent assesses the change against key risk factors based on ITIL best practices and posts a clear risk score, and the Change Failure Risk Prediction AI agent estimates the probability that the change fails or needs a rollback, with the contributing factors spelled out. Alexander reviews the analysis, attaches the rollback plan, and records the planned maintenance window in the action item's fields, then completes it.
Every step of this is logged. The change's Journey tab records each action item as it's activated and completed, along with field updates, so anyone opening the record can see exactly where the change stands and how it got there.
Getting approvals
Completing the assessment phase activates the approval phase. The approval action items go out to the CAB, and this is where Maya, the CFO, enters the story. As an End User, she doesn't work in the Admin interface at all. Her approval action item reaches her by email, and because the workflow notification was set up with embedded actions, the email itself contains Approve and Deny links.
Maya wants the full picture before signing off on downtime. She opens her action item in the Self-Service Portal and downloads the PDF with the complete change details: the risk score, the rollback plan, the maintenance window, the linked incidents.
Satisfied, she approves. From here, the change can go one of two ways.
Track 1: The change is rejected
Not every change survives approval. Say the CAB decides the timing is wrong: quarter-end is two weeks away, and the finance applications on that server can't risk any downtime until it passes. An approver clicks Deny, and the workflow stops advancing.
A rejected change still gets closed properly, so the record and its history stay clean. Alexander resolves it:
He opens the change and goes to the Journey tab.
In the toolbar at the bottom of the record, he clicks Resolution.
In the Resolve the Service Record form, he selects the rejection status, notes the reason in the closing fields, and clicks Resolve.
The linked incidents stay open; the underlying issue is still real. Alexander schedules a new change for after quarter-end, and the related items carry straight over to it.
Track 2: The change is approved
Let's rewind and take the happier path: every approver signs off, and the implementation phase activates.
One by one, the implementation action items open and notify their Assignees. John gets the bulk of them, as regular Admins usually do when there's real work to be done: back up the server's data, notify affected users of the maintenance window, perform the upgrade during that window, and restore service. He works through them from his My Action Items view, completing each one as it's done; each completion activates the next dependent action item and lands in the Journey.
The final phase is verification, and its action item is deliberately not assigned to John. User Acceptance belongs to the change requester's side of the fence, so the template assigns it to Ami's team, and only they can complete it; that's assignment doing its job as the access boundary. Ami's team confirms the reporting tool runs clean on the upgraded server, and the last action item turns green.
Closing the change
The workflow is complete, but the change doesn't close itself; resolving it is a deliberate step. Alexander opens the change one last time:
He goes to the Journey tab and clicks Resolution in the toolbar at the bottom of the record.
In the Resolve the Service Record form, he selects the completion status, fills in the closing fields, and describes the solution, turning on Share with Request User so Ami and the other reporters see the outcome.
He clicks Resolve.
And here the setup pays off one more time: the Status Settings rule the team configured fires on the closing status and automatically closes all of the linked incidents, Ami's included. Nobody chases down five incident records; the automation does it.
With the fix implemented and verified, Alexander closes the loop on the problem investigation too. He opens the problem, goes to its Journey tab, clicks Resolution, and resolves it with a note pointing to the change that fixed it. Its own linked incidents are already closed, courtesy of the change, so there's nothing left open.
The production server is upgraded, every participant did their part from their own surface (the record, email, or the Self-Service Portal), the Journey holds the full audit trail, and the incidents that started it all are closed. That's the point of Change Management: a significant, risky change moved through assessment, approval, implementation, and verification without the process itself getting in the way.
Next steps
To build a process like this one for your organization, follow Setting Up Change and Problem Management. For the day-to-day mechanics the participants used in this story, see Fulfilling Action Items. And to activate the AI agents that scored this change's risk, see Prebuilt AI Agents Overview.