End-users can generate requests when:

1. Ordering items using the Service Portal,
2. Contacting a Virtual Agent through chat conversation; a request can be created on behalf of the end-user, and
3. Visiting an on-site IT support location through a Walk-Up interface.

Process users such as a Service Desk Agent can create new requests from:

1. The Service Catalogue application,
2. The Service Portal, and
3. An incident record.

Learn more here!

The incident/problem version of the ‘Assign to me’ UI action overrides the Task-level action and only assigns the incident/problem to you if you are in the Assignment group.

You can select the ‘Assign to me’ UI action for an incident or a problem record to assign the record to yourself after passing the following checks:

• If the ‘Assignment group’ field is filled in and you’re part of the group, the record is assigned to you.
• If the ‘Assignment group’ field is empty and you’re a member of a single group, the ‘Assignment group’ field is filled in, and the record is assigned to you.
• If the ‘Assignment group’ field is empty and you’re a member of multiple groups, you’re prompted to select the Assignment group. When you manually select the Assignment group, the record is assigned to you.
• 
  

If you have customised the Task UI action or any of its extended tables or created new UI actions that have the ‘Overrides’ value pointing to the Task UI action, you must perform the following actions to avoid seeing two ‘Assign to me’ UI actions on your extended table forms.

• Set the 'Action name' field to 'task_assign_to_me'.
• Remove the 'Overrides' value for extended tables.

Screenshot: ‘Assign to me’ UI Action on Incident record

Learn more here!

Problem management is the process of managing the problem lifecycle from initial detection through the analysis, investigation, resolution, and closure of the problem.

Here are the goals of problem management:

• Determine the root cause of incidents and identify viable workarounds (Detection and Logging)
• Drive to permanent solutions that prevent a recurrence (Investigation and Diagnosis)
• Identify and solve problems proactively to improve IT services and prevent potential incidents from occurring (Resolution and Closure)

Here are the three stages that problems move through in their lifecycle:

1. Detection and Logging,
2. Investigation and Diagnosis, and
3. Resolution and Closure.

Diagram: Problem Management Lifecycle

Learn more here!

Creating articles from received emails is not a common option to populate your knowledge base with knowledge articles.

Here are some of the possible methods of populating a knowledge base with knowledge articles:

• Integrating with a Web Distributed Authoring and Versioning (WebDAV) compliant source,
• Creating articles directly in the ServiceNow platform (using templates, knowledge blocks or from cases or incidents), and
• Importing Microsoft Word files into a knowledge base.

Screenshot: Importing a Microsoft Word File to the 'IT' Knowledge Base

Learn more about:

• Integration with external knowledge sources
• Importing a Word document to a knowledge base

Change Management allows the Emergency and Normal change types to be reverted to the new state which is the first approval state using the Revert to New action from the Context Menu. This action is performed if the approval was requested and the submitter recognises that not all configuration item in the scope of the change is included before submitting for approval.

• To modify the Normal change request to the New state, you can modify the state of a change request from Assess state to New state by clicking Revert to New from the context menu.
• To modify the Emergency change request to the New state, you can modify the state of a change request from Authorize state to New state by clicking Revert to New from the Context menu.

Note: When you revert to New from the Assess state or the Authorize state, the workflow is restarted and all pending approvals are cancelled.

If a Normal or Emergency change request is rejected, the state of the change request is set to New. As the state of the change request is New, you can modify the type of the change request again. For example, if your Emergency change request is rejected on the grounds that the change request is Normal, you can modify the Type of the change request to Normal and resubmit the change request.

Learn more here!

A request item record contains links to the parent request and the child catalog task(s).

By default, tasks can be related to each other using a parent/child relationship, such as a Problem with a group of child Incidents or a Catalog Request with a group of child Catalog Tasks.

If you cannot fix a problem without doing more analysis, you can reanalyse it by moving it from the Fix in Progress state back to the Root Cause Analysis state.

The Problem Management process has many states, and each is vitally important to the success of the process, and the quality of service delivered.

Previously, you could only go to the Root Cause Analysis state from the Resolved state.

Diagram: Problem Management state transitions

Learn more here!

A user with the admin or incident_manager role can edit the major incident properties to define whether a new major incident must be created or a major incident candidate must be promoted to a major incident. The properties are available only when you activate the Incident Management - Major Incident Management plugin (com.snc.incident.mim).

These properties are available at Incident > Administration > Major Incident Properties.

Here are the properties for major incident management:

• Create a new major incident or promote a major incident candidate to a major incident.
• Provide a comma-separated list of incident communication task types that can have the Compose Email option on Major Incident Workbench.
• Associate a custom UI page to an exported post-incident report.
• Auto-assign a major incident to different assignment groups based on the actions taken on incidents and also on conditions related to the assignment group.
• Select the default recipient location of emails for communication tasks. The default value is BCC.

Screenshot: Customisation Properties for Major Incident Management

Learn more here!

You can use the conflict calendar to view the change schedule, view the details of the change, customise views, and resolve conflicts.

The Conflict Calendar button appears in the change form title bar once the Planned start date, Planned end date, and Configuration item fields are populated, and the request is saved.

You cannot update the Blackout Schedule or Maintenance Window in Conflict Calendar.

Screenshot: Change conflict calendar

Learn more here!

A Standard change is a predefined, pre-authorised change considered to be relatively low risk.

It is frequently implemented, has repeatable implementation steps and has a proven history of success.

A Standard change was initially implemented as a normal change or standardised through the use of templates.

As Standard changes are pre-approved, they follow a stream lined process in which group level or peer approval and CAB authorisation steps are not required.

Approved standard change requests can be predefined in a catalogue of templates to make accessing and requesting a standard change more efficient. This ability also enables the Change Management team to control the changes that are authorised as standard.

Screenshot: Example of a Standard Change request

Learn more here!