1.	General Information
	1.1 Introduction
	1.2 Users’ groups in ITCM application
	1.3 List of ITCM application forms and their principal functions
2.	Workflow
	2.1   Call Statuses
	2.2   Flag 'Failed' (CS domain only)
	2.3   Creation of the call (ticket) and first (group) Assignment of the new ticket (call)
	2.4   Rejecting a call
	2.5   Individual Assignment
	2.6   Suspending a call (ticket)
	2.6.1 Setting up reminder for suspended ticket
	2.6.2 Automatic wake-up mechanism for suspend tickets
	2.7   Resuming a call (ticket)
	2.8   Completing a call (ticket)
	2.9   Re-opening a call (ticket)
	2.10 Closing a call (ticket)
	2.11 Escalation of a call (ticket) to an expert
	2.12 Information on current open calls
	2.12.1 Lists of Calls
	2.12.2 Call Meters
	2.13 Highlighting special requests
	2.13.1 Reference tickets (PDP-SERCo domain only)
	2.13.2 Happy / Neutral / Unhappy flag (PDP-SERCo domain only)
	2.13.3 Work review flag
3.	Escalations
	3.1 Time Escalations
	3.1.1 Adjusting time limits for escalation
	3.1.1.1 ITCM:Domains schema
	3.1.1.2 ITCM-ClusterAssignment schema
	3.1.1.3 ITCM:CategoryRules schema
	3.1.2 Time measurement
	3.1.3 Possible types of time escalations
	3.2 Expert Escalations
4.	Notifications
	4.1 Triggering and contents
	4.2 Assignee status and notification
	4.2.1 Marking an assignee as being absent
	4.2.2 No “first notification” for absent assignee
	4.2.3 Automatic mail transfer in case of absence of the assignee
	4.3 E-mail notification groups versus Remedy native notification mechanism
5.	Application tuning
	5.1 Defining a domain
	5.2 Creating users
	5.3 Creating call assignment groups
	5.4 Creating cluster assignments
	5.5 Defining category time constraints
6.	Interface enhancements to ITCM application - predefined macros
7.	CS Workflow
8.	PDP-SERCO Workflow
9.	Pictures of ITCM Forms
	9.1 ITCM:CallManagement form in CS domian
	9.2 ITCM:CallManagement form in PDP domian
	9.3 ITCM:CallManagement schema - "Lists of Calls" tab (for all Domains)
	9.4 ITCM:CallManagement schema - "Call Meters" tab (all Domains)
	9.5 ITCM:Domains form
	9.6 ITCM:GroupPopulation form
	9.7 ITCM:CategoryRules form
	9.8 ITCM:ClasterAssignments form in CS domian
	9.9 ITCM:ClasterAssignments form in PDP domian
	9.10 PW:ChangePassword form
	9.11 ITCM:Dialog:SuspendReminder pop up window

1. General Information

1.1 Introduction

ITCM is a Remedy application designed to handle the requests from CERN/IT groups to External Service Providers. The application was designed in 1999 for the PDP/SERCo contract and was extended in Summer 2000 to the CS/WMDATA contract. Based on a prototype by Frédéric Hemmer, the application has been designed by Vincent Doré and enhanced in 2000 by Darek Kuzara from ITCS group. Further changes has been implemented in April 2001 by Darek Kuzara.

The application is split in Domains (currently PDP/SERCo and CS/WMDATA) which are fully separated. A user can only access and work on the requests in his domain. Domain managers (i.e. managers in charge of the SLA) are responsible within their own domain for choosing and entering appropriate request categories, populating assignments and escalation groups, choosing and entering escalation time limits.

Requests from IT Submitters are automatically transferred by ITCM to the appropriate Assignee(s) working for the Service Providers. ITCM chooses the Assignee(s) according to the systems (cluster) selected by the Submitter and the time limits according to the category selected by the Submitter. In parallel with the requested intervention, the Assignee updates the Remedy request (entering progress report, requesting more information, changing status,...). Submitters and Assignees are notified by email of modifications done on the request. During the whole process, timers count the time spent on various states. Submitters and Assignees are notified by email of modifications done on the request (changes of status, new comments added,...). When a time limit is exceeded, notification is sent to the escalation group attached to the request category. ITCM works closely with the PDP and CS databases both to display machine information and to restrict PDP submission to the machines in their database.

 

1.2 Users’ groups in ITCM application

There are 7 functional groups of users in ITCM:CallManagement application. One user can belong to one or more groups:

 

ITCM-Readers	- by default all Remedy users using ITCM:CallManagement application should belong to this group. The group has read only permission to most of the field in most of the application’s schemas. .
ITCM-Submitters	- all Remedy users supposing to create a new calls in ITCM:CallManagement application should belong to this group.  In case of CS domain all users belonging to this group may not only submit a new call but also close it, suspend it, resume, and complete. .
ITCM-Assignees	- all Remedy users supposing to deal with already created calls in ITCM:CallManagement application should belong to this group. The users belonging to this group may modify ‘Details Diary’ field, may take call “In Hand”, reassign a call to another member of the same notification group, complete a call, suspend or resume it. .
ITCM-Escalators	- all Remedy users belonging to this group may modify call entries after it has been escalated to an expert (and therefore “Closed”)  .
ITCM-ContractManagers	- Remedy users belonging to this group may modify and create entries in ITCM:CategoryRules, ITCM:ClusterAssignments, ITCM:GroupPopulation schemas; .
ITCM-AssigneeManagers	- Remedy users belonging to this group may modify and create entries in ITCM:ClusterAssignments and ITCM:GroupPopulation schema; .
ITCM-Subadministrators	- Remedy users belonging to this group may modify and create and modify application objects (using Remedy AdminTool).  .

1.3 List of ITCM application forms and their principal functions

ITCM application consist of the following forms (schemas):
 

ITCM:CallManagement	- main application form. Access for all ITCM application users especially for those belonging to ITCM-Submitters and ITCM-Assignees groups; (see here for the form view examples). .
ITCM:Domains	- defines application domains, availability (or not) time and expert escalation within the domain. Access for users belonging to ITCM-Subadministrators group; (see here for the form view example). .
ITCM:GroupPopulation	- defines notification (assignment) groups and list of their members. Access for users belonging to ITCM-AssigneeManagers and ITCM-ContractManagers groups; (see here for the form view example). .
ITCM:CategoryRules	- defines time constraints and time measurement mode for calls’ categories. Access for users belonging to ITCM-ContractManagers group; (see here for the form view example). .
ITCM:ClusterAssignments	- defines assignment group and notification groups for time and expert escalations for a cluster. Access for users belonging to ITCM-AssigneeManagers and ITCM-ContractManagers groups; (see here for the form view example). .
ITCM:Dialog:SuspendReminder	- auxiliary form, acting as pop-up message box for setting suspend parameters (both automatic resume time or interval for a reminder message). (see here for the form view example). .
ITCM:Counters	- auxiliary form, used by application escalations for various time calculation. This form is hidden for all ITCM application users. .
PW:ChangePassword	- enables all users of ITCM application to change their password and work status (Absent / Active). Restricted access for all ITCM application users. Each user may only see and modify its own data; (see here for the form view example). .

2. Workflow

2.1 Call Statuses

 

New	- only during the process of creation and reopening of a ticket (call). If there are no constraints on number of the open tickets, the transition from this status to "Assigned" status is immediate and automatic. There are no constraints on number of the open tickets in CS group domain. .
Assigned	- In CS domain status changes to from “New” to “Assigned” when [Save] button is pressed, and the call (ticket) is committed to the database. Hence, “Assigned” is the first status of the registered call. In PDP workflow this only happens when there is available work slot. At the time when the ticket is in this status it is assigned to the appropriated assignment group. This depends on a cluster. In CS domain, there is only one cluster hence only one assignment group. .
In Hand	- status changes to from “Assigned” to “In Hand” when [In Hand] button is pressed, and changes are saved (by pressing [Save] button). This action means: assign the ticket to an individual (person performing the action). The status means, that somebody belonging to assignment group took a call for work and since then is responsible for completing it. Only in case of CS domain not only a member of the assignment group can take a call in hand, but also a member of submission group. .
Suspended	- status changes to from “In Hand” to “Suspended” when [Suspended] button is pressed, and changes are saved (by pressing [Save] button). This call status means, that call is suspended and all clocks (for time escalation) are stopped). All calls might be suspended at any time by a member of an assignment group and by a member of submission group (in CS domain only). .
Rejected	- status changes to from “Assigned” to “Rejected” when [Reject] button is pressed, and changes are saved (by pressing [Save] button). The status means that somebody belonging to assignment group refused to accept the call. This is the last phase in the workflow. No changes to the status of the ticket can be done afterwards. .
Completed	- status changes to from “In Hand” to “Completed” when [Done] button is pressed, and changes are saved (by pressing [Save] button). This call status means, that work requested in the call has been completed successfully by a member of assignment group (or by a member of submission group in case of CS domain only).  All time escalation clocks are stopped for the calls in “Completed” status. .
Closed	- status changes to from “Completed” to “Closed” when [Close] button is pressed, and changes are saved (by pressing [Save] button). This call status means, that work requested in the call has been completed successfully and approved by a member of submission group.  If request remains in “Completed” status for longer than 9 working hours, the call status will be automatically changed to “Closed”. In this case two notification messages will be send: one to the submitter of the call, and one to the last person assigned to the call. Closed calls cannot be reopen (as it is the case for “rejected” calls). .
Failed	this is not a status. This is only a “Yes/No” flag field. The field is present only in CS domain. By default all calls have this flag field set to “No”. It is set to “Yes” whenever any time defined in time escalations for the call category has been exceeded or the call has been escalated to an expert. This flag may be set with any of the above status.

 

2.2 Flag 'Failed' (CS domain only)

Failed this is “Yes/No” flag field. The field is present only in CS domain. By default all calls have this flag field set to “No”. It is set to “Yes” whenever any time defined in time escalations for the call category has been exceeded or the call has been escalated to an expert.

 

2.3 Creation of the call ticket and first (group) Assignment of the new ticket

Only the members of ITCM-Submitters group can create a new call ticket. In order to create a new call it is enough to fill in all required fields in ITCM-CallManagement schema. These fields are:

• in case of PDP-SERCo domain: ‘Cluster’, ‘Host’, ‘Work on’, ‘Category’, ‘Type’, ‘Priority’ and ‘Description’;
• in case of CS domain: ‘Category’ and ‘Description’ (initially ‘Category’ is always pre-set to: ‘Standard User Assistance’ but other possible categories may be chosen from the menu attached to the ‘Category’ field;

All allowed categories are available from the menu attached to the ‘Category’ field. The same considers ‘Cluster’, ‘Host’, ‘Type’, and ‘Priority’ fields.

During the whole process of creation of the call, ticket is in “New” status. After filling in all required fields (and /or ‘Details Diary’ field for additional information), the ticket is created after [Save] button is pressed. By default the status automatically changes to “Assigned”. In case of PDP workflow the status automatically changes to “Assigned” only if there are no constraints on numbers of currently open calls.

 

2.4 Rejecting a call

Each call assigned to appropriate assignment group and being in “Assigned” status may be rejected by any member of this group. The action can be achieved by pressing [Reject] button, and saving changes by pressing [Save] button. If this happens, the workflow of the call is finished. A short reason why the call is rejected should be given in ‘Details Diary’ field.

After the call is marked as rejected it cannot be re-open or re-assigned. For CS domain this call cannot be marked “Failed” anymore.

 

2.5 Individual Assignment

A call ticket is (re-)assigned to an individual whenever:

• call status is “Assigned” and call is taken in hand (by pressing [In Hand] button);
• call status is already “In Hand” i.e. it is already assigned to an individual within the same assignment group and any changes e.g. in ‘Details Diary’ field are saved to the database by different user than the one registered in ‘Assigned To’ field. This is so called re-assignment. This action do not change the assignment group (‘Assigned to Grp’ field).

Re-assignment may takes place also for calls escalated to an expert. Closing a call do not change individual assignment.

By default only members of ITCM-Assignees group may take a ticket in hand. In case of CS workflow members of ITCM-Submitters group may also take tickets in hand. (This of course means that the ticket will be assigned to the person performing the action.)

 

2.6 Suspending a call (ticket)

By default a call ticket (when it is in “In Hand” status) can be suspended by any member of ITCM-Assignees group. In case of CS domain the ticket can be also suspended by any member of ITCM-Submitters group (also when it is in "Assigned" status).

Suspend ticket action is achieved by pressing [Suspend] button. Pop up form will appear allowing user to define suspend parameters such as automatic wake up time or time period for the notification reminder (to be sent to the assignee) Accepting the settings by pressing [OK] button and saving the ticket will result in suspending it. Pressing [Cancel] button in the pop up form will cancel the operation of suspending the ticket.
Whenever a person performing the suspending ticket action is different than the one registered in ‘Assigned To’ field the call is assigned to the person performing the action.

2.6.1 Setting up reminder for suspended ticket

The reminder mechanism automatically send periodical reminder emails to the ticket assignee. The default value (in hours) between 2 reminders is setup in the ITCM:CategoryRules form by the Assignee Managers, separately for each category. This default value can be overwritten by the Assignee when he suspends the ticket (0 means no reminder) or changed later when the ticket is suspended, by pressing "Suspend parameters" button. The latter action results in popping up Suspend Ticket dialog window, where all suspend parameters can be set up. "Next reminder will be send at" read only field shows calculated time for the next reminder message. In order to compute the time of the next reminder message one need to press [Return] / [Enter] key from the keyboard while after defining the time interval in "Hours" field. The "Next reminder will be send at" field is placed below "Hours" field defining period of time for the reminder
See picture 9.11 for the example view of the dialog pop up window.

 

2.6.2 Automatic wake-up mechanism for suspend tickets

The wake-up mechanism for suspended ticket automatically resumes suspended tickets i.e. changes its status form "Suspended" to "Assigned". At this time e-mail notification is sent to the assignee. The Assignee can specify when the tickets should be automatically resumed in the Suspend Ticket dialog window, when he suspends a ticket. The assignee need to click on the rectangular button right to the "Automatic ticket Resume Time" field in order to set up the date. Leaving this field blank (default) will result in no automatic wake-up. This setting can be modified later by pressing "Suspend parameters" button. The latter action results in popping up Suspend Ticket dialog window, where all suspend parameters can be set up.
See picture 9.11 for the example view of the dialog pop up window.

 

2.7 Resuming a call (ticket)

By default a call ticket can be resumed from suspension by any member of ITCM-Assignees group. In case of CS domain a member of ITCM-Submitters group may also perform this action (the ticket will be re-assigned to the user performing the operation). The call may only be resumed when it is in “Suspended” status.

Resume call action is achieved by pressing [Resume] button and saving the changes by pressing [Save] button. Whenever a person performing the resume action is different than the one registered in ‘Assigned To’ field the call is assigned to the person performing the action.

 

2.8 Completing a call (ticket)

By default a call ticket can be completed by any member of ITCM-Assignees group. In case of CS domain a member of ITCM-Submitters group may also perform this action (the ticket will be re-assigned to the user performing the operation). The call may only be completed when it is in “In Hand” status. Complete report should be written in ‘Details Diary’ field before pressing [Save] button.

Complete call action is achieved by pressing [Resume] button and saving the changes by pressing [Save] button. Whenever a person performing the complete action is different than the one registered in ‘Assigned To’ field the call is assigned to the person performing the action.

 

2.9 Re-opening a call (ticket)

A call (ticket) can be re-open by any member of ITCM-Submitters group. This can be only done when call is in “Completed” status. Re-opening report can be written in ‘Details Diary’ field before pressing [Save] button.

Re-open call action is achieved by pressing [Close] button and saving the changes by pressing [Save] button. Any comments may be put into ‘Details Diary’ field before pressing [Save] button. Re-opened call’s status is automatically changed to “Assigned” and all members an assignment group are notified. All clock are resuming from they latest values for the time escalations (if defined).

Closed calls cannot be reopen (as it is the case for “rejected” calls).

 

2.10 Closing a call (ticket)

A call (ticket) can be closed by any member of ITCM-Submitters group. This can be only done when call is in “Completed” status.
Close call action is achieved by pressing [Close] button and saving the changes by pressing [Save] button. Any comments may be put into ‘Details Diary’ field before pressing [Save] button.

If request remains in “Completed” status for longer than 9 working hours, the call status will be automatically changed to “Closed”. In this case two notification messages will be send: one to the submitter of the call, and one to the last person assigned to the call.

Closed calls cannot be reopen (as it is the case for “rejected” calls).

 

2.11 Escalation of a call (ticket) to an expert (CS domain only)

A call (ticket) can be escalated to an Expert Escalation group by any member of ITCM-Submitters group. This can be only done when call is in “Completed” status. Escalation report can be written in ‘Details Diary’ field before pressing [Save] button.

A Call Expert Escalation action is achieved by pressing [Escalate] button and saving the changes by pressing [Save] button. All members of the Expert escalation group are notified about the escalated call.

Each call escalated to an expert escalation group is automatically marked as failed.

 

2.12 Workflow control features

2.12.1 Lists of Calls

Lists of all currently opened (Assigned, In-Hand, Suspended and Completed) calls in a user's domain are placed in the new tab called "Lists of Calls". Double clicking on any of the calls from one of the four lists opens this call in a new ITCM window for fully displaying this call (modify mode). The lists are accessible at any time (also while submitting a new ticket). In order to activate any of the lists it is necessary to click on it.
In order to refresh the list the user needs to right click on the chosen list and select 'Refresh Table' from the appearing menu. See picture 9.3 for detailed view of the "List of calls" tab.

 

2.12.2 Call Meters

Fields representing the number of currently Assigned, In-Hand, Suspended and Completed calls in the user's domain and of those only assigned to the user are placed in the new tab called "Call Meters". The "Call Meters" fields are accessible at any time (also while submitting a new ticket). Call meters may be updated at any time by clicking either of the two buttons presented on the tab "Refresh call meters for Domain" and "Refresh my call meters". See picture 9.4 for detailed view of the "Call Meters" tab.

2.13 Highlighting special requests

2.13.1 Reference tickets (PDP-SERCo domain only)

Users belonging to PDP domain can highlight the tickets by changing "Reference ticket" flag (in the Main Field tab of ITCM:CallManagement form). See picture 9.2 for an example.

 

2.13.2 Happy / Neutral / Unhappy flag (PDP-SERCo domain only)

This set of 3 buttons is an implementation of so called "smiles". They change their appearance depending on the user choice. By default all tickets are marked as "Neutral". It is yet another tool allowing the users to indicate if they are happy or not with a ticket. The usage is simple pressing the buttons, and saving the ticket afterwards.
See picture 9.2 for an example.
 

2.13.2 Work review flag

This fields allows to set up the call work review status to either of the tree possible values:
- Not needed (default)
- To be done
- Has been done
See picture 9.2 for an example.

3. Escalations

3.1 Time Escalations

Time escalations define time constraints for calls. There are two levels of time escalation. They vary from resulting action after the defined time in the level elapses. Time escalation level 1 results in warning send to all members of the ‘1st Time Escalation Group’. This group is defined in ITCM:ClusterAssignmentschema for each ‘Cluster’ separately (in case of CS there is only one cluster). Time escalation level 2 results in notification message send to all members of the ‘2nd Time Escalation Group’ also is defined in ITCM:ClusterAssignment schema for each ‘Cluster’ separately. All tickets, which passed through the time limit defined in the second level time escalation, are automatically marked as failed. (Note that ‘Failed’ field is not visible in PDP-SERCo domain).

3.1.1 Adjusting time limits for escalation

The following schemas are involved in time escalation settings: ITCM:Domains, ITCM:ClusterAssignment, ITCM:CategoryRules and indirectly ITCM:GroupPopulation.

Application manager for a domain may set the following time escalation parameters:

3.1.1.1 ITCM:Domains schema:

• enable or disable time escalation for all calls within its domain (ITCM:Domains schema). This setting is a global one for the whole domain;
• in case of enabled time escalation, define which call statuses will trigger time counters. Possible combinations are: “Assigned” only, “In Hand” only, “Suspended” only, “Assigned” plus “In Hand”, “Assigned” plus “Suspended”, “In Hand” plus “Suspended” or “Assigned” plus “In Hand” plus “Suspended”. All this setting are valid for all the calls within the domain. In case of choosing more than one call status being involved in time escalation, the escalation time counters calculate combined time for all statuses allowed;

3.1.1.2 ITCM-ClusterAssignment schema:

• ‘1st Time-Escalation Group’ - name of the group which members will be notified in case of time escalation level 1 (ITCM-ClusterAssignment schema, group must be defined in ITCM:GroupPopulation schema beforehand). Note: if escalation notification group is not defined it does not suppress the escalation itself. This mean, that nobody will be notified / warned about exceeding the time limit, but all other actions associated with this event will take place;
• ‘2nd Time-Escalation Group’ - name of the group which members will be notified in case of time escalation level 2 (ITCM-ClusterAssignment schema, group must be defined in ITCM:GroupPopulation schema beforehand). Note: if escalation notification group is not defined it does not suppress the escalation itself. This mean, that nobody will be notified / warned about exceeding the time limit, but all other actions associated with this event will take place;

3.1.1.3 ITCM:CategoryRules schema:

• Call ‘Completion Time’ (in minutes) – defines time limit for a call defined per ‘Category’. This means that all calls of a certain category will have the same time limits conditions. ‘Completion Time’ = 0 means not time escalation at all for the category. This can be defined in ITCM:CategoryRules schema.
• ‘First Escalation After […] % of the Completion Time’ – defines percentage of the time limit after which 1st time escalation takes place (defined per ‘Category’). This means that all calls of a certain category will have the same time limits for the 1st time escalation. In this case 0 means no 1st time escalation for the category. This can be defined in ITCM:CategoryRules schema.
• ‘Second Escalation After […] % of the Completion Time’ – defines percentage of the time limit after which 2nd time escalation takes place (defined per ‘Category’). This means that all calls of a certain category will have the same time limits for the 2nd time escalation. In this case 0 means no 2nd time escalation for the category. This can be defined in ITCM:CategoryRules schema.
• ‘Default Time Calculation’ flag enable choosing type of the time calculation. There two types of time calculation available: “business time” (counting time only during official CERN working day since 8:30 till 17:30) and “flat time” (counting time continuously apart from business time). This can be set up in ITCM:CategoryRules schema, globally for all calls of the defined ‘Category’;

3.1.2 Time measurement

There are two types of time calculation available in the application: “business time” and “flat time” (refer to 3.1.1). This can be set up in ITCM:CategoryRules schema, globally for all calls of the defined ‘Category’.

There are 6 escalation objects running in five minutes intervals each updating time clocks. They recalculate time spend in each of the defined statuses e.g. “Assigned”, “In Hand”, “Suspended”, depending on category settings in ITCM:CategoryRules (refer to 3.1.1). Time clocks are also updated when a call changes its status.

3.1.3 Possible types of time escalations (summary)

 

Time calculation for statuses Type of time calculation Remarks Assigned Business hours1 Assigned Continuous time2 Assigned + In Hand Business hours1 A sum of clocks for each status Assigned + In Hand Continuous time2 A sum of clocks for each status Assigned + Suspended Business hours1 A sum of clocks for each status Assigned + Suspended Continuous time2 A sum of clocks for each status Assigned + In Hand + Suspended Business hours1 A sum of clocks for each status Assigned + In Hand + Suspended Continuous time2 A sum of clocks for each status In Hand Business hours1 In Hand Continuous time2 In Hand + Suspended Business hours1 A sum of clocks for each status In Hand + Suspended Continuous time2 A sum of clocks for each status Suspended Business hours1 Suspended Continuous time2

1 - Official CERN working hours including official lunch break time (between 12:30 and 13:30). 2 - Time measured regardless of official CERN working hours (round the clock).

3.2 Expert Escalations

For more information about an Expert Escalation of an call please refer to chapter 2.11.

4. Notifications

4.1 Contents and triggering

Notifications are sent when a call changes its status, when it was updated, when time defined in one of the two time escalationsexceeds. All notifications within the application are sent via e-mail to the relevant recipient(s). Exception to this rule is a group notification send when a ticket is created or re-open (assigned to appropriate group of people) in PDP domain. In this case Remedy Notifier is used to sent the notification.
The messages as well as mail subjects for the same sort of notification may vary between different domains. Notifications are sent when the 'Details Diary' field is modified. Note, that all important changes (like Assignment, Status changes etc.) are logged in 'Details Diary' field, therefore this triggers notification. In particular notifications are sent after:

• - first assignment (re-opening of the ticket) - This action implies assignment to a group action which results in group notification. Only active members of the group receive this kind of notification. All users marked as "Absent" in "User" form are excluded even though they are members of the appropriate group.
• - individual call re-assignment - individual notification is sent to a new assignee if different of currently logged user;
• - automatic closure of the call ticket - individual notification is sent to the submitter of the call ticket;
• - expert escalation - This action implies assignment to a group action which results in group notification. All members of the expert escalation groups for the Domain receive this kind of notification, no matter they are marked as "Absent" in "User" form or not. This option is currently active only for CS domain.
• - time escalations - This action implies assignment to a group action which results in group notification. All members of the time escalation groups for the Domain receive this kind of notification, no matter they are marked as "Absent" in "User" form or not. This option is currently active only for CS domain.

Each of the notification messages consist of call request id. All other information included in the notification message vary depending on the type of the notification.

 

4.2 Suppressing notifications

 

4.2.1 Marking an assignee as being absent

An assignment group notification is suppressed for the users who are marked as absent in "User" from. The "User" form is not accessible for most of the users, there is PW-ChangePassword form available, which allows the user to change its Remedy login password and 'status'. There are 2 user statuses available: "Active" and "Absent".
Note: E-mail notification is never send to the user who triggered the notification. Exception to this rule is assignment of the ticket to the assignment group action, when all of the members of the assignment group receive the notification.

 

4.2.2 No “first notification” for absent assignee

The assignee is not sent any notification about any new tickets assigned to his / her group in case when absence is registered in the User form or via PW-ChangePassword form either by the Assignee Manager or by the Assignee himself.

 

4.2.3 Automatic mail transfer in case of absence of the Assignee

In case of absence of the Assignee (the absence of the Assignee has to be registered by the Assignee or the Assignee managers as already explained), update mails sent to the Assignee notification mails are also sent to the other members of the Assignment group and (in case of PDP-SERCo domain) to the Assignee managers.

4.3 E-mail notification groups versus Remedy native notification mechanism

It has been decided to not use the Remedy native notification mechanism but to replace it by a simple home-made group mechanism in order to:

• stop sending notification mails to absent people;
• avoid duplication information in the system group form and ITCM:GroupPopulation form;
• avoid security problems of domain administrators accessing the system forms (User and Groups forms);
• remove the limit on the number of groups user can belong to, imposed by Remedy group notification mechanism (255 characters long definition of the groups);

5. Application tuning

5.1 Defining a domain

A new domain may be added in ITCM:Domains schema by any member of ITCM-Subadministrators group. While creating a new Domain manager may define globally for the whole domain escalation parameters (see chapter 3 for details).

There is one special field called “New Ticket Notification” in ITCM:Domains form. Giving user (Remedy login name) in this field will result in sending notification to that user whenever new call is created or Detail Diary’ field is updated for an existing one (any change of any field in the ITCM:CallManagement schema). This feature was meanly designed for PDP-SERCo domain, however it may be use by anyone.

Domains were introduced in order to separate the tickets different groups / contracts e.g. CS, PDP. They allow for variations of the workflow for different domains.

A Remedy user currently can only belong to one domain. It is not possible to see calls of the other domain than the user’s own domain. This is also true for domain administrators.

 

5.2 Creating users

A new user may be defined in standard Remedy User schema. The creation of the new user may be requested by sending an e-mail to Remedy.Support@cern.ch stating ITCM application and domain in which user will work. It is necessary to fill in CM-Domain field in User form for any users meant to use ITCM:CallManagement application. Newly defined user has to belong to at least one of the ITCM-groups (see chapter 1.2 for the list of the application groups). It is a Remedy administrator responsibility to create any new users in Remedy system.

 

5.3 Creating call assignment (notification) groups

A new assignment group may be defined in ITCM:GroupPopulation schema by any member of ITCM-AssigneeManagers group. There is a mechanism preventing duplication of the group names with the same status within one domain. This mechanism works during submission (creation) of the new assignment group as well as during modification / search operation.

Members of the group may be picked up from the menu attached to the ‘Members’ field. This menu consists of the list of all users belonging to the current domain (domain of the currently logged in user).

It is possible to define group without the members, however this group will not work as notification group, i.e. nobody will receive any notification

 

5.4 Creating a cluster assignments

Clusters are chiefly meant for PDP-SERCo domain. There is only one cluster for CS domain (already predefined in the application). ‘Cluster’ field in the main application schema (ITCM:CallManagement) is hidden in pre-set for this domain.

Cluster represents groups of the machines from the PDP-SERCo point of view. The list of clusters and machines for PDP-SERCo are dynamically refreshed from the PDP machine database (at ticket creation time). Defining a cluster assignment in ITCM:CallManagement schema allows to determine assignment group for a call - the group responsible for completing the call (‘Assignee Group’ field), time level 1 escalation notification group (‘1st Time-Escalation Group’ field), time level 2 escalation notification group (‘2nd Time-Escalation Group’ field) and expert escalation notification group (‘Expert-Escalation Group’ field). All aforementioned fields have assigned menu allowing to choose one of the assignment groups defined for the current domain in ITCM:GroupPopulation schema.

Each cluster may be set as active (“In-production”) or inactive (“Retired”). This can be set by changing ‘Cluster Assignment Status’ radio button field. It is within users belonging to ITCM-ContractManagers or ITCM-AssigneeManagers groups responsibility to manage proper cluster assignments.

There is a mechanism preventing duplication of the cluster assignments with the same status within one domain. This mechanism works during submission (creation) of the new assignment group as well as during modification / search operation.

 

5.5 Defining category time constraints

Each domain has it own set of Categories. This is defined in special character menus (ITCM:CS:CallCategories in case of CS domain, and ITCM:PDP:CallCategories in case of PDP-SERCo domain). Currently, any changes to the set of categories can only be done by the intervention of a Remedy administrator.

User (belonging to the ITCM-ContractManagers group) may define time constraints for the possible time escalations which will be valid for all calls of the certain category (for more detail of time settings please refer to the sections 3.1.1 and 3.1.2).

Each category may be set as active (“In-production”) or inactive (“Retired”). This can be set by changing ‘Rule Status’ radio button field.
There is a mechanism preventing duplication of the category definitions with the same status within one domain. This mechanism works during submission (creation) of the new assignment group as well as during modification / search operation.

6. Interface enhancements to ITCM application - predefined macros

In order to improve call handling a few new buttons and menu items has been introduced into the main application schema (ITCM:CallManagement). All 6 new buttons are available from the right side of the last default Remedy User Tool button (“What’s this?” button) in the Remedy task bar. All new menu items are available from the new menu called “Calls”. The menu is situated between “Action” and “Window” default Remedy User Tool menus. It is necessary to open at least one instance of ITCM:CallManagement form in order to get new macros buttons and menu available in a user tool.
 
 

Picture 6 ITCM:CallManagement schema

 

Print Current Call		prints the currently open call on the printer. The user will have to select one of the all available printers from the operating system. The format of the printout is different for different domains.
List My Open Calls		opens a new ITCM:CallManagement search window listing all calls with status “In Hand” or “Suspended”, assigned to the currently logged in user;
List My Suspended Calls		opens a new ITCM:CallManagement search window listing all calls with status “Suspended”, assigned to the currently logged in user;
List All New Calls		opens a new ITCM:CallManagement search window listing all calls with status “Assigned”, “In Hand” or “Suspended” within the current domain;
List All Open Calls		opens a new ITCM:CallManagement search window listing all calls with status “Assigned” or "In Hand" or "Suspended" within the current domain;
List All Suspended Calls		opens a new ITCM:CallManagement search window listing all calls with status “Suspended” within the current domain;

7. CS Workflow

Picture 7 CS workflow

8. PDP-SERCO Workflow

Picture 8 PDP-SERCO workflow

9 Pictures of ITCM Forms

ITCM:CallManagement - main application form. Users belonging to ITCM-Submitters and ITCM-Assignees;
 

Picture 9.1 ITCM:CallManagement schema in CS domain

Picture 9.2 ITCM:CallManagement schema in PDP domain

Picture 9.3 ITCM:CallManagement schema - "Lists of Calls" tab (all Domains)

Picture 9.4 ITCM:CallManagement schema - "Call Meters" tab (all Domains)

ITCM:Domains - defines application domains, availability (or not) time and expert escalation within the domain;
 

Picture 9.5 ITCM:Domains schema

ITCM:GroupPopulation - defines notification (assignment) groups and list of their members;
 

Picture 9.6 ITCM:GroupPopulation schema

ITCM:CategoryRules - defines time constraints and time measurement mode for calls’ categories;
 

Picture 9.7 ITCM:CategoryRules schema

ITCM:ClusterAssignments - defines assignment group and notification groups for time and expert escalations for a cluster.
 

Picture 9.8  ITCM:ClusterAssignments schema in CS workflow

Picture 9.9  ITCM:ClusterAssignments schema in PDP workflow

PW:ChangePassword - enables all users of ITCM application to change their password and work status (Absent / Active). Restricted access for all ITCM application users. Each user may only see and modify its own data.
 

.                  .

Picture 9.10  PW:ChangePassword form

ITCM:Dialog:SuspendReminder - pop up windows where the user can set any suspend parameters (i.e. Suspend Reminder and Automatic wake-up time).
 

Picture 9.11 ITCM:Dialog:SuspendReminder pop up window