The goal of request management is to:

1. Empower requesters and ensure efficient delivery of items and services (Ensure all users in the organisation are made aware of and can easily request all services offered by IT)
2. Inform users about available goods and services (Ensure that all new services can quickly be offered in the catalogue as soon as they become available)
3. Enable a streamlined, standardised process (Provide a consistent and repeatable process for requesting and fulfilling services to ensure that users’ expectations are clearly set and continually met, thus maintaining high customer satisfaction levels).

Request management allows catalogue items to be requested and fulfilled.

Learn more here!

Using Multiple Choice variable type in Service Catalogue creates radio buttons for user-defined question choices.

The lookup multiple choice variable creates radio buttons using data from a table. Its functionality is similar to the lookup select box variable, which creates a choice list from queried data.

Note: Table with large data causes performance issues when loading the page. Use reference qualifiers to reduce data or use the reference type variable.

Learn more here!

Peer approvers are required to check whether the change plan is technically sound.

When a change request is in a New state, it is not yet submitted for review and authorisation. A change requester can save a change request as many times as necessary while building out the details of the change prior to submission.

Peer review and technical approval of the change details are performed during the Assess state.

Learn more here!

The major incident workbench is a single pane view designed for major incident managers, communication managers, and resolver groups. The workbench helps to manage major incidents by aggregating and providing actionable information.

To navigate to the major incident workbench, you can open a major incident or a major incident candidate and click 'View Workbench' on the form header.

The major incident workbench provides UI elements that display the summary of tasks, progress of communication plan, conferencing information, and a report on the cause and resolution of the major incident.

The major incident workbench has the following UI elements:

• Summary,
• Communicate,
• Collaborate, and
• Post Incident Report.

Note: You need to activate the Notify plugin (com.snc.notify) for the Collaborate tab to appear. The Post Incident Report tab is visible only when the incident state is either Resolved or Closed.

• The Summary tab provides a unified view of information in the form of a card layout. The information on impacted services, affected CIs, active outages, locations that are impacted, and child incidents helps to keep you informed about related records associated with an incident.
• The Communicate tab helps you understand the progress of the communication plan and its related tasks.
• The Collaborate tab helps you view information about communication tasks with conference as their communication channel. It also allows you to manage the participants in a conference call.
• The Post Incident Report tab helps you to understand the cause of the major incident and the actions taken by the teams to resolve the incident.

Screenshot: Major incident workbench with the four tabs

Learn more here!

You can take the following actions on the CAB Meeting form:

• Refresh Agenda Items,
• Send meeting request to attendees, and
• Go to this meeting in CAB Workbench.

You can Refresh CAB Meetings from the CAB Definition form but not the CAB Meeting form.

You can add an agenda item to your CAB meeting to customise the agenda and make the meeting more effective.

Screenshot: Different UI actions on the CAB Meeting form

Learn more here!

Catalog editors can perform the same functions as a catalog manager for their assigned catalogs, including assigning editors to the catalog, but they cannot reassign the catalog manager.

Catalog manager [catalog_manager] can edit and update a service catalog, as well as the categories and catalog items within the catalog. The manager can assign editors and also a different manager for the service catalog.

Note: You can perform these actions only on catalogs for which you are assigned as the manager or the editor.

Learn more here!

Approvals are a critical component of the request management process. Approvals ensure that overall orders and individual items are evaluated by appropriate groups or individuals 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.

Requests can be approved at Request and/or Requested item level(s), out of the box.

When a request is sent to a user with the [SM application]_approver_user role, the approver has several choices. If you select 'Approval is required for new requests' in the applications Configuration screen, the newly created request automatically moves to the Awaiting Approval state. Otherwise, the request moves to the next configured state.

Diagram: Approval that can happen at both the Request (REQ) and the Requested item (RITM) levels

Learn more here!

ref_ac_columns attribute is used to list all the columns you want visible on the Caller's drop-down list in the Incident record. ref_ac_columns specifies the list of reference table columns to display. You should separate column names with a semi-colon.

Here are some other dictionary attributes:

• ref_auto_completer specifies the name of the client-side JavaScript class that creates the drop-down auto-completion choices.
• ref_ac_columns_search enables auto-complete to match text in the columns listed in the ref_ac_columns attribute. Set this attribute to true to enable auto-complete to match the text in all reference field columns. By default (or when this attribute is false), auto-complete only matches the text in the display value column.
• ref_ac_order_by specifies the reference table column that sorts the auto-completion choices.

Screenshot 1: The ref_ac_columns attribute on a reference field on the [task] table

Screenshot 2: The Attributes related list for a dictionary entry that lists the 'Reference auto completer columns' attribute

Learn more here!

Change approvals move through a defined process that includes:

1. Request Approval,
2. Approval Notification,
3. Locate Approval, and
4. Approve or Reject. 

When you click Request Approval in the change form title bar, the change state moves to Assess to indicate that the change is waiting for approval.

Designated approvers are notified via email.

Approvers can approve or reject from the email or the Service Portal.

Approvers can locate their approvals in the Now Platform by clicking Service Desk > My Approvals.

You can click the Requested link to open the approval request.

Any of the approvers defined in the workflow can either approve or reject the change.

• If Approved, the next action in the workflow sequence commences. This could be a change task or another approval.
• If Rejected, the rejecter must provide comments. The change is then rolled back to the New state.

Once all approvals in the Assess and Authorize stages are complete, the approval workflow is complete.

Learn more here!

If the email has a watermark of an existing incident, an inbound email action updates the existing incident according to the action's script.

By default, if an email has no identifiable watermark, an inbound email action attempts to create an incident from the message.

You can define an inbound email action to script how the system responds to an inbound email.

Note: Inbound email flows take priority over inbound email actions. If you create flows with inbound email triggers, emails are first processed by the inbound email triggers before inbound email actions process them.

Inbound email actions are similar to business rules: both use conditions and scripts that take action on a target table. An inbound email action checks the email for a watermark that associates it with a task and checks for other conditions. If the conditions are met, the system takes the inbound email action that you configure. The system can take two types of actions:

• Record action: setting a value for a field in the target table.
• Email reply: sending an email back to the source that triggered the action.

Image: Inbound Actions

Learn more here!