NAME

CustomerSLA - extend SLAs by associations with customer companies

SYNOPSIS

This OTRS package adds the capability to associate SLAs with customer companies and automatically maintain service<-->customer user associations through them.

In addition, it allows to ensure compatibility between a ticket's customer id and the selected SLA by automatically adjusting the other when one is changed.

DESCRIPTION

To our understanding of ITIL, the SLA sits in between the customer and the service--no ticket for a service without a corresponding SLA that governs it.

The OTRS model already includes the association between the SLA and the service, but otherwise associates services directly to individual customer users. A commercial extension from OTRS.com (http://www.otrs.com/solutions/subscriptions/feature-add-ons/) is available to associate services with customers (i.e. the company/department/project/whatever the customer user belongs to), but still leaves the SLA disconnected from any customer.

With the popular CustomerIDs hack described in the OTRS admin manual, customer users already have the possibility to be in more than one "company". Applying the same approach to SLAs with a CustomerIDs SLA preference, the missing association can be established with almost no coding (just a bit on the presentation layer for rendering the associations to companies as a table, similar to associated services). Using this information, the customer user <--> service associations can be rebuilt as follows: A service will be associated to a customer user when one of the customer IDs of the SLA matches one of the customer ID/IDs of the customer user. Note that this is a simple token match; there is no need that the referenced customer ID actually exist as a company. Associations created manually by a user with an ID other than 1 (i.e. root) are not touched and thus allow manual additions if necessary.

When creating a ticket, SLAs are filtered according to the associated (and already selected) service. SLAs can additionally be filtered to those that apply to the (already selected) customer user or which are not restricted by customer ID at all.

When a service has been made available through more than one SLA, it is up to the user through which SLA he/she wants to raise a ticket against it. An optional event handler can update the customer ID (company) on the ticket itself to reflect the company/department/project for which the ticket applies, which can be useful for charging appropriately. Likewise, when a customer ID for the ticket is manually changed by an agent, the SLA may be updated or reset to correctly reflect the SLAs available for the selected customer ID.

POST-INSTALLATION TASKS AND CONFIGURATION

Starting with version 1.1 of this package, all SysConfig settings specific to this package are in group CustomerSLA.

Extension of Customer User for Multiple IDs

See the section Customer with multiple IDs (Company tickets) in the OTRS Admin manual.

Configure "Replacement" SLA modules through SysConfig

In SysConfig, disable the "standard" SLA modules supplied by the OTRS Framework and OTRS::ITSM:

In group Ticket, subgroup Frontend::Admin::ModuleRegistration, disable Frontend::Module###AdminSLA
In group ITSM Core, subgroup Frontend::Agent::ModuleRegistration, disable Frontend::Module###AgentITSMSLA

Adjust Template

The template for AgentITSMServiceZoom contains a hyperlink that refers to the "original" AgentITSMSLAZoom instead of the extended one. This can be adjusted by modifying this template (in $OTRS_HOME/Kernel/Output/HTML/Standard/), replacing AgentITSMSLAZoom by AgentCustomerSLAZoom (1 occurrence).

Enable/Disable Ticket SLA Filtering by Customer

Enabled by default; can be controlled by the entry Ticket::CustomModule###007-CustomerSLA

Enable/Disable Ticket Update (SLA/CustomerID)

Enabled by default; the event handler which ensures compatility between the ticket's SLA and customer ID can be controlled by the entry Ticket::EventModulePost###400-CustomerSLA

Launch Periodic Update of Service<-->Customer User Associations

Update of these associations based on SLAs currently needs to be performed in batch by running $OTRSHOME/bin/otrs.RebuildServiceAssocs.pl periodically (e.g. once a day). See usage information embedded in the script for available commandline options.

KNOWN LIMITATION: See below.

Optionally Extend Customer Company for "Contact" Field

As delivered, the package makes use of an optional CustomerCompanyContact field when displaying the associations between an SLA and customer companies in AgentCustomerSLAZoom. Creating this field is very much like the customization for the CustomerIDs for the customer users.

Create a new row in the database:

  mysql> ALTER TABLE customer_company ADD contact VARCHAR (200);

Define the mapping in Config.pm (copied from Defaults.pm, 1 line added):

  # Override only the field mapping for CustomerCompany, leave rest at default
  $Self->{CustomerCompany}->{Map} = [
     # var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly
     [ 'CustomerID',                 'CustomerID',   'customer_id',  0, 1, 'var', '', 0 ],
     [ 'CustomerCompanyName',        'Company/Project', 'name',              1, 1, 'var', '', 0 ],
     [ 'CustomerCompanyStreet',      'Street',       'street',       1, 0, 'var', '', 0 ],
     [ 'CustomerCompanyZIP',         'Zip',          'zip',          1, 0, 'var', '', 0 ],
     [ 'CustomerCompanyCity',        'City',         'city',         1, 0, 'var', '', 0 ],
     [ 'CustomerCompanyCountry',     'Country',      'country',      1, 0, 'var', '', 0 ],
     [ 'CustomerCompanyURL',         'URL', 'url', 1, 0, 'var', '$Data{"CustomerCompanyURL"}', 0 ],
     [ 'CustomerCompanyContact',     'Contact Email', 'contact',     1, 0, 'var', '', 0 ],   # (added)
     [ 'CustomerCompanyComment',     'Comment',      'comments',     1, 0, 'var', '', 0 ],
     [ 'ValidID',                    'Valid',        'valid_id',     0, 1, 'int', '', 0 ],
  ];

USAGE EXAMPLE

In our organization, we have services grouped into SLAs by target groups: Services that apply to everyone in the organization (e.g. internet, email, office), to specific departments (e.g. HR, sales/marketing, technical), or to specific projects (special tools, etc.).

When updating the customer users from data of the HR system by a nightly batch job, each customer user entry also gets a list of generated customer IDs based on departments.

The "OTRS admin role" then assigns SLAs to organization/s, departments, or projects. Subsequently, all customer user <--> service associations are maintained automatically by periodic execution of the rebuild script provided as part of this package.

KNOWN PROBLEMS AND LIMITATIONS

Batch synchronization between customer users and services only works with customer user backends that are able to return all customer users in a single call. For e.g. Kernel::System::CustomerUser::LDAP this depends on the number of entries versus the configuration setting UserSearchListLimit.

There is currently no support for printing associations between SLAs and customers.

There is no assistance for entering customer IDs, so data entry is to some extent prone to typing mistakes.

VERSION HISTORY / CHANGES

Version 1.1

Updated to run with OTRS and ITSM in versions 3.0 - 3.3, with some cleanup, minor bug fixes, and enhancements.

It has been tested with 3.0.11 and 3.3.3, but should run equally well on any intermediate version.

Simplified installation and removed dependency on exact OTRS version by removing the need to patch Ticket.pm. We are now using the "Custom Module" mechanism to replace just the TicketSLAList function, which is compatible to several recent OTRS versions.
Updated otrs.RebuildServiceAssocs.pl to not modify any customer user <--> service associations that have been made by a "real" user who is not the user root. Increased robustness and documented limitations (thanks to Dan Boala at iross.ro).
Extended ticket update to be more symmetric with respect to SLAs and CustomerIDs, i.e. update one whenever the other is changed. Automated updates are now being made as user ID 1 to distinguish them from manual agent actions.

Version 0.7.x

Initial version, running with OTRS 3.0.x and ITSM 3.0.5 (only)

TERMS AND CONDITIONS

AUTHOR

dietmar.berg@thalesgroup.com

OPAR - OPM Package ARchive

CustomerSLA