Setting up Change Management and Problem Management is a milestone for any IT organization. It's the point where your change and problem processes stop being ad hoc and become standardized, auditable, and aligned with ITIL best practices, with built-in approvals, clear accountability, and AI working alongside your team. This article walks you through the full setup, from planning your processes to running your first change.
If you're new to Change and Problem Management, start with the Change and Problem Management Overview to learn the core concepts, terms, and user roles.
Available for:
Customers using SysAid Spaces. If you're using SysAid Classic, see Change Management and Problem Management Location Guide and FAQ.
Please note:
While this article does not explicitly cover SysAid Request Management, the same principles that apply to Change Management and Problem Management also apply to Request Management.
Step 1: Plan your processes
SysAid gives you the tools to implement your change and problem processes, but the processes themselves are yours to design. Before you start configuring, map out what your organization needs: which types of changes and problems you handle, how many templates that requires, who participates in each process, and where approvals are required. Process standardization is the primary goal of Change and Problem Management, and it's much easier to achieve when your templates are planned up front rather than created ad hoc.
Your service record history is a great planning resource, and SysAid Copilot can mine it for you. The Analyze Low-Risk Change Candidates for Automation AI agent reviews your closed changes and clusters the routine, low-risk ones that deserve a streamlined template, while the Detect Recurring Issues AI agent surfaces incident patterns that point to problems worth a dedicated process.
Tip!
To learn more about prebuilt AI agents and how to activate them, see Prebuilt AI Agents Overview.
Step 2: Grant permissions
Grant the Change and Problem Management permissions to the Admins who will build and run your processes:
Go to Settings > Administration > User Management > Service Pros (Admins).
Select the user whose permissions you want to manage.
Open the Permissions tab.
Grant Change Manager to the Admins who will design templates and oversee the full process, and Create Changes/Problems to the Admins who will create and close changes and problems.
Click OK or Apply.
Tip!
For the full breakdown of what each permission controls, see Managing Agent and Admin Permissions.
How access works inside a workflow
Once a change or problem is running, access to its work is controlled through assignment. Each action item has an Assignee (a user and/or group), and only the Assignee can edit and complete that action item. Admins with the Change Manager permission can edit all action items regardless of assignment, and Admins with the View other Admins' action items permission can view, but not edit, action items assigned to others. Everyone else sees only their own assigned work.
This means you can enforce hard boundaries within a single workflow through assignment. For example, if a User Acceptance action item must be completed only by the change requester, assign that action item to the requester or their group. Other participants in the same workflow, such as implementers and planners, can't edit or complete it, even if they own every other action item in the process. Keep in mind that Admins with the Change Manager permission can always edit any action item, so grant that permission only to the people who oversee the process.
Step 3: Build your templates and workflows
SysAid includes a set of out-of-the-box change and problem templates. Review them first to see how much of your process is already covered, then adapt them or build your own. See Service Desk Templates for the full list.
Templates are designed in the Template Designer, and each template's process is built in the Workflow Designer: create phases to divide the process into logical stages, then add action items to each phase. For each action item, set its Assignee, define its fields, and configure dependencies so that action items activate in the right order. See Workflow Designer, Change Templates, and Problem Templates.
A few configuration choices deserve special attention:
Approval action items. Build your approval gates, including CAB sign-off, as action items assigned to the approvers. Approvers can approve or deny directly from an email notification.
End User approvers. When an approver is an End User, such as a CFO on the CAB, you can allow them to download a PDF with the full change details so they can make an informed decision. They complete their action items from the Self-Service Portal.
AI in your workflow. You can add an action item that automatically triggers an AI Agent or a Workato recipe when it activates, letting your workflow run analysis or automation steps without human intervention.
Please note:
Editing an existing action item affects every template that uses it, and template changes are not retroactive: they apply only to changes and problems created after the update, not to records already in progress.
Any Admin can choose or change a service record's template while creating it, but only to another template of the same type. For example, you can swap one incident template for another, but you can't turn an incident into a change by switching templates. After the record is created, its template can no longer be changed.
Step 4: Set up workflow notifications
Notifications keep your workflow moving: when an action item is activated or completed, its notification can send an email, send a text message, open a new service record, or any combination of the three. Setting one up has two parts:
Create the notification under Settings > Customization > Notifications > Workflows.
Connect it to an action item in the Workflow Designer by selecting it in the Notification ID field in the action item's attributes, and choosing whether it's sent on activation or completion.
For your approval action items, two options are especially useful: attaching a PDF with the full change details to the email, and using the $Approve and $Deny tags so approvers can act directly from the email without logging in.
Tip!
For the full setup, including all delivery channels and the complete list of dynamic tags, see Setting Workflow Notifications.
Step 5: Configure linked-incident behavior
Changes and problems usually start life as incidents, and SysAid can keep those incidents in sync automatically at two points:
At creation. When a change or problem is created from an incident, for example by an escalation rule or an AI agent, the incident's status updates automatically to the status you define under Settings > Customization > Service Desk > General Service Desk Customizations. See General Service Desk Customizations for SysAid Spaces.
As the process progresses. When a change or problem moves to a specific status, Status Settings rules can update all of its linked incidents to a matching status, for example closing all linked incidents when a change reaches Change Completed. See Automatically Updating Linked Incident Statuses (Status Settings).
Step 6: Activate your AI agents
SysAid Copilot's prebuilt AI agents take on the analytical heavy lifting of Change and Problem Management: scoring change risk against ITIL factors, predicting change failure, classifying changes for approval routing, detecting problems hiding in your open incidents, creating problems with their related incidents already linked, and running structured root cause analysis. Review the AI agents relevant to your processes and activate the ones your team needs. See Prebuilt AI Agents Overview.
Step 7: Run your first change or problem
With permissions, templates, notifications, and automations in place, it's time to test your setup end to end. There are two flows to know, and the following sections walk through each one:
Creating a change or problem
Closing a change or problem when the process completes
Creating a change or problem
To create a change or problem:
Click Create at the top of the page. The Create button is available from any page in SysAid.
Select Change or Problem as the record type.
Select the relevant template within that type.
Fill out the record's details and save.
Please note:
Out of the box, an incident can't be converted into a change or problem. Incidents can only be converted to requests, and vice versa. To create changes or problems from incidents automatically, use an escalation rule or an AI agent such as Create Problem with Related Incidents.
Tip!
If multiple incidents share the same root cause, the Detect Problem from Incidents AI agent can identify the cluster for you, and the Create Problem with Related Incidents AI agent can create the problem with all relevant incidents already linked.
The template you chose already includes the workflow you configured for it in Step 3, and that workflow activates as soon as the service record is created: its independent action items open immediately, and their Assignees are notified. From here, participants work on their action items from the record's Action Items tab, from email, or from the Self-Service Portal, and can track their assigned work in the My Action Items view. See Fulfilling Action Items.
Closing a change or problem
Every change reaches closure: approved changes are closed after implementation, and rejected changes are closed before it. Problems are closed whether they were resolved successfully or marked as unresolvable. Closing doesn't happen automatically when the workflow's last action item is completed. Resolving the record is a deliberate step:
Open the change or problem that's ready to be closed.
Go to the Journey tab.
In the toolbar at the bottom of the record, click Resolution. The Resolve the Service Record form opens.
Select the Resolution Status.
Fill in the Closure Information and describe the Solution. To make the solution visible to the Request User, turn on the Share with Request User toggle. If future reference requires more technical detail, describe it in the Resolution field.
Click Resolve.
Please note:
The fields that are mandatory when closing depend on your configuration. Under Settings > Customization > Service Desk > General Service Desk Customizations, you can select which of the closing fields (Closure Information, Solution, and Resolution) are mandatory for each service record type, so your changes and problems can have stricter closing requirements than your incidents.
If you configured Status Settings rules in Step 5, the record's linked incidents update automatically when it reaches the closing status.
Tip!
You can also resolve a record by changing its status to a closed-class status. For all resolution options, see Resolving a Service Record.
Next steps
Your Change and Problem Management setup is now live. To see the full process in action, read Example of a Change from Start to Finish, which walks through a complete change from the originating incidents to closure. For the day-to-day mechanics of working on action items, see Fulfilling Action Items.