There are three types of changes :

1. Standard Change: A standard change is a pre-authorized change that is low risk, relatively common and follows a specified procedure or work instruction.

2. Normal Change: This type of change follows the complete change lifecycle. It needs two-level approvals and must be planned well ahead of time. It usually has a major impact on the business process and overall IT workflows.

3. Emergenency Change: A change that must be implemented as soon as possible, for example to resolve a major incident or implement a security patch. This change is of such a high priority that it bypasses group and peer review and approval and goes straight to the Authorization state for approval by the CAB approval group.

ServiceNow largely complies with the core aspects of ITIL for its change management process. ServiceNow follows below lifecycle in change management.

1. New: A need for a change is identified and a change request is initiated.

2. Assess: The created change is then extensively assessed by a person of authority who governs the change process and a decision is taken whether to accept or reject the requested change.

3. Authorize: Once the change is deemed as necessary, its impacts, benefits and risks are reviewed to avoid any unnecessary disruption of IT setup. It is evaluated by the leadership and all stakeholders, who will be impacted by the change and then it is given an approval. For high-priority changes, which might impact the overall business operations, the Change Advisory Board (CAB) is also consulted.

4. Schedule: The initiated change is scheduled for implementation in such a way that no work disruption occurs.

5. Implement: With the approvals and schedule in place, the necessary changes are implemented in the IT system.

6. Review: The implemented change is tested and verified to ensure it is working in the intended manner and if any component of the whole change ecosystem is broken.

7. Close: When a change is closed, all related and associated incidents/ problems are closed automatically.

8. Cancel: There is an additional option to cancel any change requests that are initiated. The reason for cancelling the change is added to the Work Notes field.

Requests typically have the following characteristics:

- Approval is automatically granted by the delegated authority.
- The tasks are well known, documented, and proven.
- Authority is effectively given info in advance for the change.
- The request is included as part of the service offering.
- The risk is usually low and well understood.
e.g. Password reset, Account Creation etc.

Change Request have the following characteristics :
- A change request requires authorization by the Change Advisory Board (CAB).
- A change request might involve a significant change to the service or infrastructure.
- It might carry a high degree of risk.
e.g. Request to promote code from one environment to another.

Change advisary board in short known as CAB is group of people who assess, authorize, priorize the changes and control the process. The owner, manager, architects, project managers of the service or infrastructure should approve the changes with an agreement with business owners.

A problem is a cause, or potential cause, of one or more incidents. Problems can be raised in response to a single significant incident or multiple similar incidents. They can even be raised without the existence of a corresponding incident.

The Problem Management process has many states, and each is vitally important to the success of the process and the quality of service delivered. The Problem life cycle can be represented in a diagram as follows:

Let's say your VDI is working very slowly around 4 to 5PM, this will be considered as unplanned disruption of service therefore you will raise an incident. The corresponding team will look into the issue, and try to find out the root cause. Let's assume issue exist due to heavy traffic in Asia region server. So, as a work around they might ask you to connect to the EMEA server which might resolve your issue for the day.

Suppose many Asia region users are facing this issue daily and they start raising incidents, this multiple incident for the same issue will be considered as problem and problem record will be created to find paramanant solution. Once problem record is created, technical team will start investigating the issue as part of problem process.

Assume that they find out the root cause as Asia people also join in EMEA shift around 4-5 PM therefore load is suddnly getting increased on Server. So, they plan to increase the server capacity to handle more users. As increasing Server capcity is big unplanned significant change therefore it requires change request to be created to deploy these changes on required Server.