Use > Service Level Management > Service Level Management overview > Service Level Management administration > Service Level Agreement application integration records

Service agreement application integration records

Service Manager provides an out-of-box record for each application in the slamodulecontrol table that you can modify to enable SLM integration with other applications and associated settings. To edit the records, click Service Level Management > Administration > Configure Application in the system navigator.

The name of the primary application table is the name of the application integration record.

Choose this record To enable this application
cm3r Change Management requests
cm3t Change Management tasks
probsummary Incident Management
imTask Incident Management tasks
incidents Service Desk
request Request Fulfillment
requestTask Request Fulfillment tasks
rootcause Problem Management problems
rootcausetask Problem Management tasks
svcCartItem Service Catalog

Ensure that you select Enable SLM in this application to integrate service agreements with the individual application.

The following table describes Service Level Management application integration control record options.

Option Description
Table Name The name of the application table that Agreements are configured for.
Enable SLM in this application Select this check box to enable Service Level Management (SLM) processing for the indicated table.
Run in Foreground

Select this check box to process Agreement calculations in the foreground for the indicated table.

Clear this check box and the Agreement calculations will be scheduled to run as background processes. The Agreement information will not be immediately visible to the technicians.

Process Targets Select this check box to enable Process Target processing for the indicated table.
Service Targets Select this check box to enable Service Target processing for the indicated table.
Record ID Field

The field name in the indicated table that is used to store the unique ID of the ticket.

For example, values in the Record ID Field contains "Number" if the unique ID is stored in the Number field in the probsummary table.

Agreement ID Field The field name in the indicated table that is used to store the Agreement ID of the ticket.
Start Time Field The field name in the indicated table that is used to store the date and time value corresponding to the time when the ticket becomes active (open).
End Time Field The field name in the indicated table that is used to store the date and time value corresponding to the time when the ticket becomes inactive (closed).
Customer Field

The field name in the indicated table that is used to store the customer name of the ticket. Service Manager uses this field when the following behaviors occur:

  • The customer's time zone is necessary for Agreement calculations.
  • The Agreement selection process is trying to determine which Agreement needs to be used for the ticket being opened.

 

Technician Field The field name in the indicated table that is used to store the name of the technician who is responsible for working on the ticket. Service Manager uses this field when the technician's time zone is necessary for Agreement calculations.
Active Condition

Determines whether the record is active or not. This condition only refers to the valid field names in the current record and must use the $L.file variable.

For example, the "flag in $L.file=true" condition is valid when it refers to the fields in Incident Management.

Record Group Field Name The field name in the indicated table that is used to store the name of the ticket group.
Process Target State Field The field name in the indicated table that is used to store the ticket's current state or status. Service Manager uses this field when processing Process Targets.
Use Phases

Select this check box to use phases to measure service levels for the ticket's Process Targets. Clear this check box and Service Manager uses the Response State Progression list.

When Service Manager uses phases for the application that is configured for Agreements, a ticket is processed through the series of phases defined in the Category phase table. The name of the Category phase table is specified in the Object record for the indicated table.

Process Target State Progression

The set of ticket states that are used to measure the process service levels for the ticket's Process Targets. The states must be valid states for the indicated table ans must exist in valid succession.

For example, the state of "closed" must exist in the list after the state of "open".

For Incident Management, the valid states are defined in the pmstatus table.

Standard Alerts

The Agreement alert(s) to be generated when processing Process Targets for tickets in the indicated table. The definitions for the alert(s) must exist in the AlertDef table.

Service Manager generates these alerts in addition to those as already defined for the Process targets of the ticket's Agreement.

Use Legacy Unordered Suspend Process

Select this check box to use the legacy unordered suspend state for the record's Response Service Level Targets (SLTs). Clear this check box to use the ordered suspend state.

When Service Manager uses the legacy unordered suspend state, if a record moves to a suspend state, the running SLT will be suspended directly without checking the suspend state order in the response states list or phase lists. Otherwise, when Service Manager uses the ordered suspend state, the SLT state will be calculated by comparing the suspend state order with the initial and the final state order in the SLT definition.

Example:

Assume that an Incident has the following SLT definitions:

The initial state is Open, the final state is Working Progress, and the suspend processing for these states are Pending Vendor/Supplier and Pending Change. The corresponding response state progression list in the slamodulecontrol definition for the Incident is as follows:

  • Open
  • Pending Vendor/Supplier
  • Working Progress
  • Pending Change
  • Resolved
  • Closed

You create an incident and set the SLT state to Running. In this situation, the following behaviors occur:

  • When this check box is selected, the incident is moved to Pending Vendor/Supplier or to Pending Change (which is in the suspend list), and the SLT state will be set to suspended directly without comparing their orders.
  • When this check box is cleared:

    • If this incident is moved to Pending Vendor/Supplier, which is prior to Working Progress (the final state of SLT), this running SLT will be set to Suspended.

    • If this incident is moved to Pending Change, which is after Working Progress, the Working Progress state is automatically finished and passed and this SLT will be set to Achieved.

CI Fields for Outage Processing The CI field names that are referenced when processing outages.
CI Fields for Subscription Processing The CI field names that are referenced when selecting the record's Subscription Agreement(s).
Outage Condition

Determines whether to process outages for the tickets that associate to the specified table. This condition only refers to the valid field names in the current record and must use the $L.file variable.

For example, the "nullsub(ci.down in $L.file, false)=true" condition is valid when refers to the fields in Change Management.

Outage Start Field The field name in the indicated table that is used to store the start date or time of the outage for the CI(s) in the ticket.
Outage End Field The field name in the indicated table that is used to store the end date or time of the outage for the CI(s) in the ticket.
Auto Post Outage Information

Select this check box to automatically post outage information to the outage table for the CIs in the ticket being closed.

Clear this check box and Service Manager will prompt the operator who closes the ticket to verify the start and end time of the outage before posting the outage information.

Spread Outages Select this check box to generate outages for the child CIs of the ticket's primary CIs. Service Manager uses the information in the deviceparent table to determine which CIs are affected.
Extend outage spreading to more than one level

Select this check box to generate outages for any child CIs of the ticket's primary CIs that exist after the first level in the parent-child hierarchy. Service Manager uses the information in the deviceparent table to determine which CIs are affected.

Note This option is available only when the Spread Outages option is selected.

Related topics

Service Level Management administration tasks
Service Level Management control record
Service Level Agreement links
Defining Service Level Targets
Service Targets
Process Targets
Service Level Agreement alerts
Prioritizing incidents, problems, requests, and changes