ServiceNow automatically checks for CI and other scheduling conflicts.

Before you save the change record, the read-only Conflict status field displays Not Run.

The conflict check cannot run until you enter the Configuration item, the Planned start date, and the Planned end date.

A conflict check runs automatically each time you save, submit, or update the change. 

If no conflicts are detected, the Conflict Status and Conflict last run fields are automatically populated.

If conflicts are identified, the Conflict status field is updated to reflect a conflict and an error message directs you to the Conflict form section of the Change request record to review conflicts. When you create a change request and provide a CI, planned start date, and planned end date, or update any of these values, conflict detection is executed automatically.

Learn more here!

producer.variable_name is the proper syntax for accessing values of variables from a Record Producer script field.

You can also define a script that uses any variable or server-side objects and functions to assign values.

• Use current.*FIELD_NAME* to reference fields on the record being created.
• Use producer.*VARIABLE_NAME* to reference values entered by the end user.
• Use RP.getParameterValue to return specified parameter values passed on the URL. The RP stands for Render Properties, not Record Producer.

Screenshot: The script for the 'Password Reset' record producer using the producer.*VARIABLE_NAME*

Learn more here!

The workflow associated with each item record governs the specific approvals and fulfilment tasks for that specific item.

Each item record documents one particular service or piece of equipment that has been requested.

Workflows that are associated with the Requested Item [sc_req_item] table have a specific type of workflow input.

When a variable is associated with a catalogue item and the workflow generating the catalogue task is associated with the catalogue item, the variable scope determines which variables are available for mapping within the catalogue task activity in a workflow. If a workflow is associated with Requested Item [sc_request_item] and is not specifically associated with a catalogue item, any catalogue variable with a blank Cat Item field value is available to all catalogue task activities within the workflow.

Learn more here!

You can create a major incident candidate in multiple ways. After a major incident candidate is created, the major incident manager evaluates the candidate and decides whether the candidate should be promoted to a major incident.

There are three ways to create a major incident:

• Propose/promote from an existing incident: Create a new major incident candidate by clicking Incident > Major Incidents > Create Major Incident Candidate.
• Create major incident candidate module: Manually propose an existing incident to be a major incident candidate by clicking Propose Major Incident from the context menu. You are prompted to enter the reason for proposing the incident as a candidate and specifying the business impact of the incident.
• Trigger rules: An incident can be marked as a major incident candidate based on the major incident trigger rules. A major incident manager or an incident manager can create trigger rules for major incidents to automatically identify major incident candidates.
• 
  

Screenshot 1: Proposing an Incident to become a Major Incident

Screenshot 2: Associating multiple incidents with a major incident

Learn more here!

ServiceNow change application automatically calculates the risk and impact of the change from predefined risk conditions.

You can define risk calculation rules on which the risk and impact of a change are calculated. Best Practice - Change Risk Calculator is activated by default in the base system.

The risk and impact values can change when the automatic risk calculation runs.

After running a risk assessment, you can rerun the assessment multiple times before requesting approval.

Learn more here!

Authorising the order is normally associated with the approval stage in the Request Management Lifecycle.

Approvals are a critical component of the request management process. Approvals ensure that appropriate groups or individuals evaluate overall orders and individual items before fulfilment takes place. Approvals can take place at both the request level and the item level, depending on your platform configuration. Approvals can also vary by catalogue item.

You can configure the Knowledge Article Helpful widget instance options for the Knowledge Management article view page in the Knowledge Management Service Portal.

The article view page uses the Knowledge Article Helpful widget to allow users to provide feedback on the article's helpfulness, display a confirmation message after feedback is provided, and display the percentage of users who found the article useful.

The Most Useful item in the Knowledge Management Service Portal displays articles with the highest percentage of users, marking them helpful.

The homepage displays links to the featured, most viewed, and most useful articles using several widgets.

The featured articles are displayed based on the keywords associated with the articles.

The most viewed and most useful articles are displayed based on the articles' highest view and use count.

Screenshot 1: The Most Useful module on the knowledge article page on Service Portal

Screenshot 2: The Most Useful module on the homepage of the Knowledge Management Service Portal

Learn more here!

Task [task] is one of the core tables provided with the base system.

It provides a series of standard fields used on each of the tables that extend it, such as the Incident [incident] and Problem [problem] tables. In addition, any table which extends task can take advantage of task-specific functionality for driving tasks.

The Planned Task plugin provides the Planned Task [planned_task] table, which extends the Task [task] Table to provide more fields for tasks to measure duration and effort.

Screenshot: Some of the task extended tables; including the change_request

Learn more here!

You can create an outage from a task record, such as an incident or a problem, to track the downtime of a configuration item. However, you cannot create outages for the inactive incident and problem records. That means any states that make these records inactive, including Closed and Canceled.

The 'Create Outage' UI action is added for the Task [task] table. When the Task-Outage Relationship plugin (com.snc.task_outage) is activated, the 'Outages' related list is added to the related list of the task forms such as Incident, Problem, or Change. If you have the admin role, you can assign multiple tasks to an outage by configuring the 'Tasks' related list to appear on the Outages form.

Screenshot 1: Creating an outage from a resolved incident

Screenshot 2: Creating an outage from a new problem

Screenshot 3: No option to create an outage from a canceled incident

Screenshot 4: No option to create an outage from a closed problem

Learn more here!

Here are the different content types in a Content Item:

• KB Article: a ServiceNow knowledge article available to users with the specified roles.
• Catalogue Content: a static block of text, formatted with HTML.
• External Content: documents or web pages stored outside the base system instance.

Screenshot: Example of a Content Item

Learn more here!