Service Management

At its simplest, auto assignment involves identifying a set of selection criteria and automatically assigning the task to the agent who most closely meets the criteria. You can, however, select multiple sets of criteria, including both rating-based and time-based criteria.

Agents can be auto assigned based on the agent or the task schedule.

Time-based methods, such as schedules and priority assignment, help you auto assign agents based on configuration settings and optional properties. The calculated ratings are used to determine the best agent to perform the task.

Agents can be auto assigned based on the time zone defined in their user records and the time zone of the tasks.

Depending on your settings in the SM application's configuration screen, you can assign agents manually or using auto-assignment.

When auto assignment is enabled and a task is qualified or marked as Ready for Work, an appropriate agent is automatically assigned to the task and it is moved to the Assigned state. If the task cannot be auto-assigned, a user with the dispatcher role must adjust the values in the request or task form and then save the record.

Agents can be auto assigned based on the location defined in their user record and the location of the tasks.

Agents can be auto assigned based on the skills of an agent, and the skills required to perform the task. Assign skills to an agent user records using Skills Users .

The priority assignment feature enables you to configure auto assignment so that agents can be assigned to perform tasks or provide services on a continual, 24x7x365 basis. Priority assignment is triggered when the priority of a task matches the priority set in the application configuration page.

Rating-based methods, such as location, skills, and time zones, help to auto assign agents based on configuration settings and optional properties. The calculated ratings are used to determine the best agent to perform the task.

When the Request lifecycle option is set to request-driven, the assigned agent can complete and close the request once all the tasks in the request are complete.

You can define controls for individual fields that are enforced when a record transitions between states.

State flows are used by SM applications to control how a work order or request automatically transitions from one state to the next. When state flows are disabled, various aspects of the ServiceNow system are also changed, as described here.

You can rebuild state flows when a mismatch between existing and new sys_ids occurs.

Approving a request in an SM application means that the request is ready for task creation and assignment.

A request contains one or more tasks. These tasks allow qualifiers to define activities that must be done to complete a request.

Service Management (SM) refers to the ServiceNow service management applications you install, such as Facilities Service Management. Each of these applications allow you to manage business functions that require a request-type workflow where requests are approved, qualified, assigned, and completed.

From creation until closure, SM application requests for work (for example, work orders and facilities requests), and their respective tasks follow a life cycle tracked by the State field in Field Service Management and Facilities Service Management.

State flows control the sequence in which records transition between states in Service Management applications.

Work notes are an important part of the state flow process and are used to communicate information about state transitions.

Use this dashboard when you wish to dive into open requests for items divided by Age.

To view the current state of open item requests, see the Open Requested Item Reports.

Use this dashboard when you wish to dive into open requests for items divided by State: Pending, Work in Progress, or all Open requests.

To view the current state of open requests, see the Open Request Reports.

Use this dashboard when you wish to dive into open requests divided by Age.

Use this dashboard when you wish to dive into open requests divided by State: Pending Approval or Approved.

After the Service Management Core plugin has been activated, you can activate other SM applications, such as Field Service management and facilities service management. You can also activate CMS portals for each of these SM applications to add them to the Service Management Portal.

Several types of components are installed with the Service Management Core plugin.

Requests can be automatically created or updated from the information in inbound emails as long as the functionality has been enabled on the configuration screen of SM application. The emails are also to be sent to a mailbox defined by criteria in the appropriate inbound email action.

Requests are created differently based on the role that has been granted to the user. Department administrators can create requests differently than an employee can.

Service Management Core includes several feature plugins. Each of these plugins installs several types of components in support of the service management process.

Service Management requests follow a specific life cycle and move through a series of states, which are displayed in the State field on the request record.

Like requests, the associated request tasks follow a specific life cycle and move through a series of states, which are displayed in the State field on the task record.

The business rules, client scripts, and UI actions that the system creates automatically to perform custom transitions exist only while the state flow records that use them are present.

A task window is the time period, bordered by start and end times, in which a task is performed.

Platform Analytics Solutions contain preconfigured dashboards. These dashboards contain actionable data visualizations that help you improve your business processes and practices.

Track the progress of new requests through the time they are worked on until they are closed.

Track the progress of purchase orders, transfer orders, and software assignments.

Agents regularly access request records as they resolve requests and correspond with the submitters. They can also access built-in reports to see information like the number of active or unassigned requests for an SM application.

The Service Management Core plugin is activated automatically when you activate any service management application.

Existing tasks can be cloned to create tasks with the same populated fields.

When you close a request, you can add details that you want the submitter to be aware of.

Within a request, you can enter comments that are visible to the submitter, allowing for collaboration between the two of you. For collaboration with other agents, you can enter comments that are not visible to the submitter.

Requests can be automatically created from the information in inbound emails as long the functionality has been enabled on the configuration screen of SM application. The emails are also to be sent to a mailbox defined by criteria in the appropriate inbound email action.

The catalog provides several different categories so users can choose the one that closely relates to their request.

Requests can be automatically created from the information in forwarded inbound emails as long the functionality has been enabled on the configuration screen of SM application. The emails are also to be sent to a mailbox defined by criteria in the appropriate inbound email action.

Tasks are created in support of requests.

Use this procedure to assign agents to active requests in service management (SM) applications.

When service management state flows have been disabled, they cannot be re-enabled from the user interface.

A dictionary override in a state flow defines the starting state for all new records in a specific table. You set an override in tables that extend a base table only, so that your customizations are applied only to the extended table.

Your business processes might require work order tasks to be accepted automatically when dispatched to an agent.

You can configure a state flow to trigger a registered system event when a task transitions from a starting state to a specified end state. For example, you can use events to trigger email notifications and create script actions.

Requests can be automatically updated from the information in inbound email replies as long the functionality has been enabled on the SM application's configuration screen. The emails must also be sent to a mailbox defined by criteria in the appropriate inbound email action.

If you have tasks that are often repeated across multiple jobs, you can create and reuse a task template in multiple request templates. You can also use it on a Work order request to pull common and repeatable information into a request.