Attention: DocWiki has reached EOL and will be decommissioned late January 2019. |
ServiceGrid Article - Cisco ServiceGrid Release Notes V4.10
From DocWiki
Overview
Release 4.10
The following new functions of the Summer Release 08 (Version 4.10) are available from Sunday afternoon 31st August 2008.
Summary
OLAs Operational Level Agreements
Use OLAs to measure your internal service processes.
New Call by XXX
The new function New Call by XXX allows customized menu entries, which can be linked to a defined workflow point of a CallSystem.
Setup Editor for SD.cockpit
Edit and copy list setups directly inside the SD.cockpit. Additionally, the test setup function is given to all setup editors for previewing the current setup.
Detailed Product and Menu Permission
Combination of read, write, and hide access inside each module.
SLA time extensions (over night)
A strong update of the SLA times allows to define breaks during the day, and recovery and response times according to location and call open time.
Priority Matrix
Use the priority matrix to calculate the right priority that should be given the urgency and impact.
Mail groups
Define own e-mail lists and assign them to contracts and services (contract elements and service items), which can be used inside of MessageRules.
Parent and child assignment for closed calls
Closed calls can now be assigned as parent or child to another call.
SD.ServiceManager
New Call by XXX
With the new release, it is possible to define our own CallOpen buttons inside the SD.call module. This allows to define individual workflow that starts through a CallOpen tab button.
Use Cases:
The following are the uses cases of New Call by XXX:
- Start workflows with a single click at different positions (CallActions).
- Define different CallOpen ways.
- Use different call open forms for the same workflow (Quick tickets).
For example: First level help desk has different CallOpen buttons than a third level agent.
And many more new combinations.
How to use:
To use the New Call, follow these steps:
Step 1: Select a CallAction and edit its master data.
Step 2: Set the UseInMenue flag to add the selected CallAction to the SD.call menu tab.
Step 3: Enter the label which should be shown for the new CallOpen in MenuText. Unless no individual text is entered, the system will use the short name of the CallAction.
Step 4: Enter a value for MenuSeqNr to define the position of the new menu entry. The lowest number will be listed after the last standard menu entry of SD.call.
The new call open type will be available to all permission groups unless the CallAction is assigned to permission groups through Display permission groups > Assign * permissiongroups to callaction.
With the new release, it is possible to define your own CallTracking setups to appear as menu buttons inside the tab menu of the SD.call module. This allows selecting defined setups with a single click.
Use Cases:
- Fast selection of commonly used CallTracking setups through menu entry.
- Enhance the the usability for special setups.
Usage:
To use the CallTracking setups, follow these steps:
Step 1: Select a CallTracking setup inside a CallSystem and edit its master data.
Step 2: Set the UseInMenueEntry flag to add the selected CallTracking setup to the menu tab of SD.call.
Step 3: Enter the label which should be shown for the new CallTracking button at MenuText. Unless no individual text is entered, the system will use the short name of the CallTracking setup.
Step 4:Enter a value at MenuSeqNr to define the position of the new tab menu entry. The lowest number will be listed after the last standard tab menu entry of the SD.call module.
The new CallTracking menu entry will be available to all assigned permission groups.
New CallTracking list options:
The following table describes the New CallTracking list options:
Option | Description |
UseAsMenuEntry | Indicates if the CallTracking list should be made available to the SD.call menu tab. |
MenuText | When it is empty, the short name of the CallTracking setup will be used. |
MenuSeqNr | The menu sequence number will order the position of the tab menu entry (after the standard SD.call menu entries). |
CallTracking
Ascent / descent sorting of list setups
With the new release, the sorting of list setups can be defined as ascending or descending. The first field of the list setup will be used for sorting.
Use case:
Create a list setup showing the following:
- The oldest Call first.
- The caller starting with the letter Z.
- The devices starting with the letter Z.
Usage:
- Select a list setup and edit its master data.
- Select the required sorting from the SortOrder drop-down list box.
ASC for ascent
DESC for descent
Inverse tree for device lists
The tree view of the inventory list could only show the sub devices. The new function Inverse tree switches the tree view from showing the sub devices to the root devices.
Use case:
Display tree lists where all root devices are displayed as tree.
For example, check on which computers some software is installed.
Usage:
Press the Inverse tree function to show all root devices.
Press the Tree function to switch back to show all sub devices.
For example, Acrobat 8.0 is installed on two desktops and one of them is a sub device of the Server10, which is a sub device of a 3com switch.
List based update of calls
The new release provides a new function that allows updating selected calls directly from the CallTracking list.
Two conditions of a call can be updated with the new options:
1.Calls can be set to test call.
2.CallState updates can be performed.
Use case:
With a few clicks, mass updates of calls can be performed directly from a CallTracking list to update CallStates or set the test call flag for selected Calls.
This saves lots of time when many calls have to be updated at once.
Setup:
Step 1: Edit the master data of the CallTracking list, which should gain the mass update function.
Step 2: Select the Listfunctions flag to activate the function.
Step 3: Select the setToTestCall and changeCallState flags to activate one or both update options.
Additionally, all CallStates to which an update can be performed should be activated for this new function by editing its master data and setting the UseForCallListFunctionUpdate flag.
How to use:
To use CallState updates, follow these steps:
Step 1: Select a CallTracking setup with the update function.
Step 2: Select the calls which should be updated.
Step 3: Select the changeCallState option.
The next mask asks to which CallState the selected calls should be updated to.
- Use the UseSuccessor flag to allow only CallState updates which fulfills the successor rules.
- Use the FireMessageTrigger flag to fire the connected MessageRules.
Click Go to proceed with the update.
After the update had started the system will show a list with the results of the update.
In the column Result, the red crossed symbol indicates an unsuccessful update, whereas the green checked symbol indicates a successful update.
How to use:
To use test call updates, follow these steps:
Step 1: Select a CallTracking setup with the update function.
Step 2: Select the calls which should be set to test call.
Step 3: Choose the setToTestCall option.
Step 4: Click GO to proceed with the update.
After the update was started the system will show a list with the results of the update.
In the column Result, the red crossed symbol indicates an unsuccessful update, whereas the green checked symbol indicates a successful update.
NOTE:
- All users with writing rights for SD.call are able to perform the mass CallState update through CallTracking setups (additional functionality inside the CallTracking list switched on).
- Only administrators can set calls through CallTracking lists to test call status.
- Calls can only be updated if the new CallState is allowed by the successor rules and is part of the right CallSystem.
- All CallStates which should be updated, should be able to set the UseForCallList FunctionUpdate at their master data.
- The CallState of calls which have been already closed cannot be updated with this function.
Activities
Negative activity booking
A new option has been added to the Activity Status types. The new added CallActivitySign option controls, if an activity status is positive or negative. This helps to subtract times from a call.
Use case:
The call activity sign gives the possibility for cancellation of bookings.
Book negative activities to reduce the total amount of working times.
Usage:
Define inside the basic data an activity status which has the CallActivitySign option set to "-".
By default all new created and existing activity states will be set to "+".
When an activity should be booked negatively, use the activity status (with the negative CallActivitySign).
More fields for activity lists extended report possibilities
With the new release, 72 additional fields can be added to the activity setup lists.
Use case:
With the new fields provided detailed activity reports (SD.cockpit) should be made available.
New fields for activity list setups:
The followinf table shows the new fields for acrivity list setups:
FieldName | Field Description |
CallActivitySign | Activity's sign |
CallClose | The close-time of the call. |
CallDescription | The description of the call. |
CallerFirstName | The first name of the caller. |
CallerLastName | The last name of the caller. |
CallerShortName | The short name of the caller. |
CallOpen | The open-time of the call. |
CallRecovery | The recovery-time of the call. |
CallSolution | The solution of the call. |
CallSysSpecField1 | The first sysspecfield of the call. |
CallSysSpecField10 | The tenth sysspecfield of the call. |
CallSysSpecField2 | The second sysspecfield of the call. |
CallSysSpecField3 | The third sysspecfield of the call. |
CallSysSpecField4 | The fourth sysspecfield of the call. |
CallSysSpecField5 | The fifth sysspecfield of the call. |
CallSysSpecField6 | The sixth sysspecfield of the call. |
CallSysSpecField7 | The seventh sysspecfield of the call. |
CallSysSpecField8 | The eighth sysspecfield of the call. |
CallSysSpecField9 | The ninth sysspecfield of the call. |
CCPFirstName | The first name of the contact. |
CCPLastName | The last name of the contact. |
CCPShortName | The short name of the contact. |
CHDFirstName | The first name of the helpdesk. |
CHDLastName | The last name of the helpdesk. |
CHDShortName | The short name of the helpdesk. |
ContractElementName | The name of the contractelement of the call. |
ContractElementName1 | The name1 of the contractelement of the call. |
ContractElementName2 | The name2 of the contractelement of the call. |
ContractElementName3 | The name 3 of the contractelement of the call. |
ContractElementName4 | The name 4 of the contractelement of the call. |
ContractElementName5 | The name5 of the contractelement of the call. |
CustCallID | The callid of the customer. |
CustFailureTypeNames | The short name and name of the failuretype of the customer. |
CustomerHelpdeskFirstName | The first name of the customer-helpdesk. |
CustomerHelpdeskLastName | The last name of the customer-helpdesk. |
CustomerHelpdeskShortName | The short name of the customer-helpdesk. |
CustomerOrgName | The name of the customer-organisation. |
CustomerOrgShortName | The short name of the customer-organisation. |
ProviderHelpdeskFirstName | The first name of the provider-helpdesk. |
ProviderHelpdeskLastName | The last name of the provider-helpdesk. |
ProviderHelpdeskShortName | The short name of the provider-helpdesk. |
ProviderOrgName | The name of the provider-organisation. |
ProviderOrgShortName | The short name of the provider-organisation. |
Queue2SCNames | The short name and name of the customer-queue2 of the call. |
Queue2SPNames | The short name and name of the provider-queue2 of the call. |
Queue3SCNames | The short name and name of the customer-queue3 of the call. |
Queue3SPNames | The short name and name of the provider-queue3 of the call. |
QueueSCNames | The short name and name of the customer-queue1 of the call. |
QueueSPNames | The short name and name of the provider-queue1 of the call. |
RC | The recovery-hours of the call. |
RS | The response-hours of the call. |
SPCallID | The callid of the provider. |
SPFailureTypeNames | The short name and name of the failuretype of the provider. |
Technician2FirstNameSC | The first name of the customer-technician2 of the call. |
Technician2FirstNameSP | The first name of the provider-technician2 of the call. |
Technician2LastNameSC | The last name of the customer-technician2 of the call. |
Technician2LastNameSP | The last name of the provider-technician2 of the call. |
Technician2ShortNameSC | The short name of the customer-technician2 of the call. |
Technician2ShortNameSP | The short name of the provider-technician2 of the call. |
Technician3FirstNameSC | The first name of the customer-technician3 of the call. |
Technician3FirstNameSP | The first name of the provider-technician3 of the call. |
Technician3LastNameSC | The last name of the customer-technician3 of the call. |
Technician3LastNameSP | The last name of the provider-technician3 of the call. |
Technician3ShortNameSC | The short name of the customer-technician3 of the call. |
Technician3ShortNameSP | The short name of the provider-technician3 of the call. |
TechnicianFirstNameSC | The first name of the customer-technician1 of the call. |
TechnicianFirstNameSP | The first name of the provider-technician1 of the call. |
TechnicianLastNameSC | The last name of the customer-technician1 of the call. |
TechnicianLastNameSP | The last name of the provider-technician1 of the call. |
TechnicianShortNameSC | The short name of the customer-technician1 of the call. |
TechnicianShortNameSP | The short name of the provider-technician1 of the call. |
CallDetail
Selection of Categories
Two new options for the CallDetail setups have been added to the Category and ReasonCategory code fields.
Use case:
Use IsCollapse for displaying the category trees collapsed.
Allow users only to select the last entry (leave) of a category tree.
Usage:
Edit the field options of a category field inside a CallDetail setup and select the two new flags IsCollapsed or SelectOnlyLeaves.
FieldName | Field Description |
IsCollapsed | When the flag is set the category tree will appear collapsed. (default: no) |
SelectOnlyLeaves | Allows only selecting the last entries of the category tree. (default: no) |
Parent and child call assignment works with closed call
With the new release, the assignment of parent and child calls works also on and for closed calls.
View URLs
URLs of contracts, services (contract elements and service items), and devices can now be shown inside the CallDetail. The URL can be shown in two ways, as link-name (ServiceGrid) or as linked URL (http://www.cisco.com).
Use case:
Refer to external information directly from the CallDetail form, after a contract or service (contract element or service item) was selected.
Use the URL names to keep long URLs short and descriptive.
Usage:
Define URLs and URL names inside the master data of contracts and services (contract element and service items).
Add the required fields to the CallDetail setups.
The following fields are available to the CallDetail setups.
FieldName | Field Description |
ContractURL | Contains the contract URL. (starting with the protocol: http:// or ftp:// ) |
ContractURLName | Name of the contract URL, can be shown alternatively and helps to display a short entry, if URL is too long for the CallDetail. |
ContractElementURL | Contains the contract element / service item URL. (starting with the protocol: E.g. http:// or ftp:// ) |
ContractElementURLName | Name of the contract element / service item URL can be shown alternatively and helps to display a short and descriptive entry, if URL is too long for the CallDetail. |
MainCompUrl | Contains the main device URL. (starting with the protocol: http:// or ftp:// ) |
MainCompUrlName | Name of the device URL can be shown alternatively and helps to display a short entry, if URL is too long for the CallDetail. |
Basic Data
Flexible SLA time definition
The new release brings a strong update to the existing SLA time definition of services (contract elements and service items). Not only definition of overnight SLA is available to the new version, it is also possible to define different SLAs for locations, priorities and CallOpen times.
Use cases:
Define breaks (for example, lunch time).
Define different response and recovery times depending on location, priority or call open time.
Use cases:
Edit a service (contract element or service item) and select its SLA.
Use the Add ServiceTimes function to add a new service record to the SLA.
The first row indicates the start time of the record and the second row indicates the stop time of the record.
A time record should not overlap with another one, or use the Copy ServiceTime to import times from a service time template.
Define filter criteria:
The filter possibilities for SLA should be switched on to be able to define them. Three flags are provided: Locations, Service Times, and Priorities.
Therefore, a set of flags is provided to the master data of each SLA (contract element and service item):
Option | Description |
UsesPrioritySLAExtensions | Default = "No" |
"No" | Shows no priorities, combo boxes are deactivated. |
"Of Customer" | Shows the customer priorities inside the combo boxes |
"Of Provide" | Shows the provider priorities inside the combo boxes. |
UsesServiceTimeSLAExtensions | Default = "No" |
"No" | Shows no service times, service time combo boxes are deactivated. |
"Of Customer" | Shows the customer service times inside the service time combo boxes. |
"Of Provide" | Shows the provider service times inside the service time combo boxes. |
UsesLocationSLAExtensions | Default = "No" |
"No" | Denies selecting a location through the search button or text field. |
"Yes" | Allows selecting a location through the search button or text field. |
Response and recovery time based on locations
With the new release, locations can have their own response and recovery times.
Use case:
Define different response and recovery time for selected locations.
Define additional combination of service time and priorties.
Usage:
To enable the location/SLA definition the flag SLA.UsesLocationSLAExtensions should be set first.
Therefore, select the Change SLA control parameters function inside the SLA master data of a service.
Set the SLA.UsesLocationSLAExtensions.
After the flag was set inside the Change SLA definitions the location column becomes available.
Use the Search button to select the locations and define the response and recovery time for a location.
NOTE:
The ServiceTime selectable at the SLA.filter is used to define the time when a call is opened. This gives the possibility to define different response and recovery times for calls which are opened in the morning or in the afternoon.
The start / end of response and recovery times are defined according to the SLA/Service hours and will not start by the time settings of the SLA.filter service time.
Response and recovery time based on priorities
The functionality of different response and recovery time for priorities remain. Other than before the flag SLA.UsesPrioritySLAExtensions has to be set before. Additionally, the priorities can be combined with ServiceTime (when a call arrives) and locations.
Use case:
Define different response and recovery times for selected priorities.
Define additional combination of service time and locations.
Usage:
To enable the priority/SLA definition, the flag SLA.UsesPrioritySLAExtensions should be set first.
Therefore, select the Change SLA control parameters function inside the SLA master data of a service.
Define if you would like to use the priority code of the customer ("OfCustomer") or provider ("OfProvider").
After the flag was set inside the Change SLA definitions, the priority column becomes available.
Set the Priority as used to.
NOTE:
The ServiceTime selectable at the SLA.filter definition is used to define the time when a call was opened.
This gives the possibility to define different response and recovery times for calls which are opened in the morning or in the afternoon.
The start and end of response and recovery times are defined according to the SLA/Service hours and will not start by the SLA.filter service time.
Response and recovery time based on call open time
Additionally, to the service hours of a service (CE, SI), the service times (SLA.Filters) can be defined. Those service times allow defining which response or recovery hours should be used at open of a call.
Use case:
Define different response and recovery times based on the call open time.
Define additional combination with locations and priorities.
Usage:
To enable the location/SLA definition the flag SLA.UsesServiceTimeSLAExtensions has to be set first.
Therefore select the Change SLA control parameters function inside the SLA master data of a service.
Set the SLA.UsesServiceTimeSLA Extensions flag.
After the flag was set inside the Change SLA definitions the service time column becomes available (showing all customer or provider service times).
NOTE:
The ServiceTime selectable at the SLA.filter is used for the call opened time only.
It provides the possibility to define different response and recover times based on the call open time.
The service level calculations are done based on the responses received during the service hours.
Example I:
Service hours: 9:00 17:00
ServiceTime (SLA.filter) 17:00 -24:00 -> Response 2 hours, Recovery 4 hours
Call Open: 18:00 leading to > response till next day 11:00, recovery 13:00
Example II:
Service hours: 9:00 17:00
ServiceTime (SLA.filter) 13:00 -17:00 -> Response 2 hours, Recovery 4 hours
Call Open: 14:00 leading to > response till 16:00, recovery 10:00 next day.
Extended field lengths for URL fields Contracts and Services (CE, SI)
The maximum length of the URL fields used inside of contracts, contract elements and service items became extended from 50 to 2000 characters. This allows entering even complex and long URLs to contracts and services (contract elements and service items).
Use case:
Enter complex URLs to the contracts and services (contract elements and service items).
Detailed Product and Menu Permissions
Until the new release, it was only possible to grant users' access to modules and to show all or selected tab functions only. A mix of read, hide and write access for a module such as SD.call, BasicData, SD.inventory and so on could not be defined. With 4.10, the read, write and hide permissions can be directly defined for each tab functions of each module of the Cisco ServiceGrid platform.
With this strong update the Product and Permission function inside the BasicData > Permissions folder was renamed to Menu and Permissions.
Use cases:
- Mix the read, write and hide access inside of each product module for all permission groups (users).
- More flexible permission group definitions can be made. For example, a user is allowed to change the user data inside of BasicData but can only see (read) the contract information and has no access to the MyCompany tab.
- Create specific permission groups for maintaining parts of the master data.
Usage:
Select the renamed Menus and Permissions to see the current configuration of the permission groups.
SD ReleaseNotes V4.10-022.jpg = No access to the module
SD ReleaseNotes V4.10-023.jpg = Access to the module
H = Hidden
R = Read access
W = Write access
Select a Change xxx option to edit the permission settings.
Use the check box of a tab function to define if it should be:
Hide
Read
Write
NOTE:
For all systems which are using more than one company, an important change affects their users.
If a user is a member of more than one company (not organizations), the permission definition of its root company will be the only valid one for the user.
InfoTicker permissions
The permission definition of the InfoTicker had been changed. The new permission concept makes it possible to define writing permissions for the InfoTicker whereas the rest of the Top functions stay read only or hide.
Use case:
The writing permission for InfoTicker does not affect the whole Top module.
For example: A user has write permission to change his own password and to submit information to the InfoTicker; but, is denied to use or edit own user data, or view the Sysinfo button.
Usage:
- Select the required permission group inside Permissions > Menus and Permissions.
- Select Read, Write or Hide from the InfoTicker drop-down list box to define how the access to the InfoTicker should be.
Deactivate the password policy for selected permission groups
With the new release, the password policy can be deactivated for certain permission groups.
The password policy can be switched on and off through the sub functions Password Policy and Permission Groups inside the Permissions folder.
Usage:
- Select the Assign Permission Groups function located inside the Permissions sub function Password Policy or Permission Groups.
- Deselect all permission groups which should be excluded from the password policy.
- Per default the password policy is set for all permission groups and has to be deselected by the administrator to allow a permission group to work without the policy.
- Two ways are provided to see which permission group is enabled for the password policy.
- The new field PasswordPolicyEnabled of the permission group list (PermissionGroups) indicates if a permission group is assigned to the password policy or not.
- Click on the function Assign Password Policy inside the Password Policy definition to see which permission group is currently assigned.
Priority Matrix Auto selection of call priority
Besides selecting directly the priority inside a call, it is possible to select the priority by giving the impact and urgencies. The new introduced priority matrix tells the system which priority code should be used inside the call. The priority matrices with its impact and urgency codes are defined per CallSystem. The impact and urgency information can also be set to inbound or outbound.
Use case:
Helpdesk agent can set the impact and urgency of a call. The priority will be automatically selected throguh the priority matrix.
Usage:
Three new points are provided for defining the impacts, urgencies and priory matrix. They are managed inside of a CallSystem.
As other codes of a CallSystem, once an impact or urgency were used, they can only be deactivated.
Impacts:
- Select Create New impact code to create a new impact.
- The fields ShortName and Name are mandatory.
- Use SeqNr to sort the code.
- Use CodeGroup to group the code.
- Select Urgency or Priorities to change to those code definitions.
- Select PriorityMatrix to map urgencies and impacts with priorities.
- Uncheck the IsActiveInLists or IsActiveInEditForms to deactivate single codes.
Urgency:
- Select Create New urgency code to create a new urgency.
- The fields ShortName and Name are mandatory.
- Use SeqNr for sorting the code.
- Use CodeGroup for grouping the code.
- Select Impact or Priorities to change to those code definitions.
- Select PriorityMatrix for mapping urgencies and impacts with priorities.
- Uncheck the IsActiveInLists or IsActiveInEditForms for deactivating single codes.
PriotityMatrix:
- Select Urgency, Impacts or Priorities to change between those code definitions.
- Select Change PriorityMatrix for mapping urgencies and impacts with priorities.
- Use the provided drop-down lists inside the matrix to assign the priority code between one impact and one urgency code.
- Click Save.
Select PriorityMatrix for mapping urgencies and impacts with priorities.
The following fields are available for the CallDetail setups:
Label | Description |
Impact | Shows short name and name of the impact code. |
Urgency | Shows short name and name of the urgency code |
The following fields are available for the CallTracking setups:
Label | Description |
CUSImpactName | The impact name on customer side. |
SPImpactName | The impact name on provider side. |
SPImpactShortName | The impact short name on provider side. |
CUSImpactShortName | The impact short name on customer side. |
CUSImpactNames | The impact short name and name on customer side. |
SPImpactNames | The impact short name and name on customer side. |
CUSImpactGroup | The impact CodeGroup short name on customer side. |
CUSImpactGroupName | The impact CodeGroup and name on customer side. |
CUSImpactGroupNames | The impact CodeGroup names on customer side. |
SPImpactGroup | The impact CodeGroup short name on provider side. |
SPImpactGroupName | The impact CodeGroup and name on provider side. |
SPImpactGroupNames | The impact CodeGroup names on provider side. |
Import the Service (CE and SI) assignment to CallActions through upload
With this upgrade of the existing CallAction/ContractElement(services)-functionality, it becomes easier to assign many services through upload functionality at once.
Usage:
Select the required CallAction and select Display ServiceItems or Display ContractElements.
Use the Upload ContractElement Assignments or Upload ServiceItem Assignments and upload the file with the ContractElements/ServiceItems and CallActions.
The following fields are required for uploading the assignment between services and CallActions.
Field Name | Field Description |
CustShortName | The customer short name. |
ProvShortName | The provider short name. |
CustOrgShortName | The customer organization short name. |
ProvOrgShortName | The provider organization short name. |
SLA.ShortName | Short name of the contract element. |
Company | Short name of the company. |
CallSystem | Short name of the CallSystem. |
CallAction | Short name of the CallAction. |
NOTE:
- Only mass upload of contract elements and service items is provided with this function.
- The deletion of already assigned services has to be done manually.
Negation of Services and CallActions
CallActions can be defined to be available to assigned CallActions only. With the new release these CallAction / ContractElement function got extended. It is now possible to define inside the master data of the CallAction, if the assigned ContractElements are allowed to use the CallAction or not. Additionally it can be defined that the CallAction is available to all, which is the standard option for all existing and new created CallActions.
Use case:
More functionality and variation when working with the combination of CallActions and Services (Contract elements and service items).
The limitation of Servies can be easily switched between except and allowed (or switched on for all).
Usage:
Edit the CallAction master data.
Choose the preferred option from ValidForContractElement drop-down lists:
- For all ContractElements (default)
- For assigned ContractElements (set for all CallActions which are using the ContractElement / CallAction relationship.
- Except assigned ContractElements
Setup preview functions for the setup editor
Another new feature of the setup editor is the Test Setup function. The Test setup function provides a fast way for previewing the current setup without the need to change to were the setup is used.
Use case:
The Test Setup functions enriches the setup administration and saves the switching time between the setup editor and where the setup is used.
Usage:
- Use the green linked Test Setup function inside of the setup editor.
- A pop-up window displays the current configuration of the selected setup.
Centralized upload and download for user queue assignments
The complete user assignment to queues can now be downloaded through the queue main folder. Previously the membership could only be seperately downloaded inside of each queue.
Use case:
The upload and download functions allow a faster administration of the user and queue assignments.
It is not required to perform downloads inside of all queues seperately.
Usage:
A new function appears at the queue list inside the BasicData. Use the Technicians and queues functions for the upload and download functions of the whole user assignments.
- Choose Download list to download the current user and queue assignment.
- Choose Upload to upload new queue assignments.
Required fields for the upload:
Field Name | Field Description |
Company | Short name of the company. (Mandatory) |
User | Short name of the user. (Mandatory) |
Queue | Short name of the queue. (Mandatory) |
Level | Additional information is not mandatory |
SD.report
Average Daily Calls for CallVolume Reports
The call volume reports with using the time periods year and months get an additional row showing the average daily calls. This provides another useful KPI for benchmarking your call volume.
Usage:
- Select a call volume report with year or months as time frame to receive the average daily call row.
- The new row reports the daily average amount of calls per time period.
More GroupBy parameters for ServiceTime and ServiceLevel
With the new release, two new GroupBy parameters can be used inside of the Service Time and Service Level reports. The organization category for customer or provider can be used for grouping the Service Time and Service Level reports.
New GroupBy parameters:
ProviderOrganizationCategory
CustomerOrganizationCategory
SD.inventory
Download sub-device relationship
Until now only the sub-device relationships could be uploaded but not downloaded. The summer release brings now the download functionality to the sub-device relationship.
Changes:
The Upload subdevices function has been moved inside the new the Root-/Sub- Devices function.
Usage:
- Select the Root-/Sub- Devices function.
- Select the Upload subdevices function to upload the sub-device relationship as used.
- Select the Download subdevices function to download the sub-device relationships.
New field for device setups: Device owner department
The department of the device owner can now be used inside device lists, device details, and SD.call device lists.
Usage:
Edit the required setup and add the field department (label: ownerdepartment) to the setup.
Sub and root-device assignment through multi-selection
Before the Release 4.10, each sub or root device could only be added one after the other by using the AddRootdevice and AddSubdevice functions. The new release allows now to add sub device and root device inside the device detail through multiselect.
The previous functions AddRootdevice and AddSubdevice have been replaced with the Assign Rootdevices and Assign Subdevice functions.
Use case:
Use the multiselection for faster assignment of sub device and root device to a device.
Usage:
To use the sub and root-device assignment, follow these steps:
Step 1: Select a device form a device list to see its details.
Step 2: Click RootDevices or SubDevices.
Step 3: Click Assign Rootdevices or Assign Subdevice function.
Step 4: Use the check boxes to select and deselect root or sub devices.
Step 5: Click Submit.
MessageRules
Mail Groups (e-mail lists) for Communications
With the new release, it is possible to define individual mail groups (e-mail group lists). Those individual e-mail lists can be used by the MessageRules to send information to all members of a mail group. A mail group consists of users (of the Cisco ServiceGridi platform) and additional email addresses can be added through the online interface without the need to create a user on the platform.
Use case:
- Define mail groups by assigning users and adding e-mail addresses and inform them through MessageRules.
- Use mail groups to inform free definitions of departments, project teams or other sets of people.
Usage:
Use the two new functions available inside the MessageRules tab, to create and administrate the new e-mail list functions.
AllMailGroups is used create and administrate e-mail lists.
AllMailAddresses is used to enter new e-mail addresses.
Assign a MailGroup to a Contract or Service:
- Edit the master data of a contract or service (contract elements and service items) and assign a mail group through the Search button.
- Delete an assigned mail group with the Trash button.
Create a new MailGroup:
- Select the AllMailGroups function inside the MessageRules tab.
(Click on an existing MailGroup to see and edit its data.)
- Select the Create a new MailGroup function to create a new MailGroup.
- A MailGroup is defined by three fields: Company, ShortName and Name
- Use the upload and download function for mass data handling of MailGroups.
- Use the upload function to upload users or e-mail addresses to the mail groups.
Assign users to a mail group:
- Select a mail group to see its master data.
- Click Display Members to see all assigned users and email addresses of the group.
- Use the Assign Users function to assign users from the Cisco ServiceGrid platform.
- Use the check box in front of the user to select or deselect the user from the MailGroup.
Assign email addresses to a mail group:
- Select a mail group to see its master data.
- Click Display Members to see all assigned users and e-mail addresses of the group.
- Use the Assign MailAddresses function to assign email addresses.
- Use the check box in front of an e-mail address to select or deselect the user from the mail group.
AllMailAddresses:
- Choose AllAddresses function inside the MessageRules tab.
- Click on an existing e-mail address to see and edit its data.
- Click Create a new MailAddress function for creating a new mail address.
- A mail address is defined by three fields: Company, E-mail and Description
- Use the upload and download function for mass data handling of e-mail addresses. (During import, the email address is used as primary key.)
- Use the upload function inside All MailGroups to assign e-mail addresses and users to the mail groups.
Assign mail group to a contract or service (contract element or service item):
Edit the master data of a contract or ServiceItem and assign through the search button a mail group for the provider side (ProvMailGroup) or customer side (CustMailGroup).
Mail Groups and Communications:
- Select an outbound communication (part of MessageRules) and assign one or more mail groups as receivers.
- Mail groups can only be used inside of a MessageRules communication.
- Use one of the following mail group types:
New mail groups:
The receivers inside the communications are named ContractElements, but they will also be used if a service item was assigned to a call.
Receiver types - Communications | Description |
SCContractElementMailGroup | Service customer contract element e-mail group |
SPContractElementMailGroup | Service provider contract element e-mail group |
SCContractMailGroup | Service customer contract e-mail group |
SPContractMailGroup | Service provider contract e-mail group |
New fields for contracts and services:
Inside the contract and service (contract element and service items) master data two new fields can be used to assign a MailGroup for the customer and provider side.
Field label | Description |
Contract | |
ProvMailGroup | Service provider contract element e-mail group |
CustMailGroup | Service customer contract element e-mail group |
ContractElement | |
CustMailGroup | Service customer contract element e-mail group |
ProvMailGroup | Service provider contract element e-mail group |
SD.cockpit
Subtitles and description for list setups reports and SD.report
For the list setups (used as cockpit elements) inside the SD.cockpit, two new settings allow defining subtitles and descriptions for graphic and table views of setup lists. Additionally, a description can be given to report (cockpit element).
Use case:
- The subtitle and description of a setup list will be shown when displayed as graphic or table.
- If present, the description of a report will be shown between the Function and User line.
Usage list setup:
To use the list setups, follow these steps:
Step 1: Edit the master data of a list setup (inside of SD.cockpit).
Step 2: Enter a subtitle in the SubTitle field.
Step 3: Enter the description into the Description field.
After the fields have been filled, they will appear on the screen, when the setup is displayed.
Usage reports:
To use the reports, follow these steps:
Step 1: Edit the master data of a report.
Step 2: Enter a description into the Description field.
After the field has been entered and saved, it will appear on the screen when the report is displayed.
Report distribution as graphic file (PNG)
Previously, grouped lists shown as graphics (SD.cockpit) were sent by the schedulers as CSV file only. With the new release, the cockpit scheduler will send those setups as graphic (using the PNG format) instead of the CSV file.
Changed behavior:
All defined schedules, which are currently sending grouped setups (which are defined as list) as CSV file will send them as graphic file (PNG).
Setup Editor for SD.cockpit
With the new release, it is now possible to administrate cockpit setups directly inside the SD.cockpit module. This saves the switching time between SD.cockpit and BasicData, and enhances the usability of SD.cockpit.
Use case:
- Users are not required anymore to change between the SD.cockpit and BasicData module to customize setup lists.
- Change setups inside existing cockpit elements without the need to delete the exiting element and to create a new one.
Usage:
Two new functions have been added to the master data view of a cockpit setup.
The Change List function was updated.
Copy Setup makes a copy of the current assigned setup and changes the assignment to the new setup.
Edit Setup starts the setup editor.
Change Setup assignment with Change List:
To change setup assignment with Change List, follow these steps:
Step 1: Choose a setup (cockpit element) inside Setup.
Step 2: Select the Change List function.
Step 3: Use the newly added Search icons to select a different setup by choosing from the list of setups.
After the changes have been saved, the new assigned setup becomes available to the cockpit element.
Copy Setup:
- Copy setup makes a copy of the currently assigned setup, and changes the assignment to the new setup.
- When the Copy setup function is called, the user is prompted to confirm the copy action.
- On confirmation, the current setup is copied, and the new created setup is assigned to the cockpit element.
- After the new, copied setup was created the system opens the new setup with the setup editor.
Edit Setup:
Edit Setup starts the setup editor and allows to change the setup.
The cockpit setup editor works in the same way as the setup editor used inside the BasicData.
NOTE:
- Changing a setup inside SD.cockpit will change the setup for everyone using the same setup and not only for the selected cockpit element.
- If a setup should be adapted for one cockpit elements but is used by several use the new Copy Setup function.
Report distribution parameters (SD.cockpit and SD.report)
Previously, SD.report and SD.cockpit schedulers sent reports with default subjects, content and sender email address.
With the new release, the subject, content and the sender address can be customized to specific needs.
Use case:
Customize the content of emails sent by the schedulers of SD.report and SD.cockpit.
Usage:
- Edit the master data of an SD.cockpit or SD.report scheduler or setup scheduler defined inside the user detail.
- Fill in the new options EMFrom, EMSubject, and Description to customize the appearance of the scheduled report email.
- The Description will be placed after the content of the report scheduler was listed in the mail body.
- The new option will become available with the new release.
New options:
The followimg are the new options and their description:
Option | Description |
EMFrom | Email address which should be shown as from address. |
EMSubject | Subject of the scheduler email. |
Description | Description (email body/text) of the scheduler email. |
Report setup view parameters
For all list setups new settings allow defining, which views should be available (for switching). It allows a user only to switch between the activated views of a selected list setup. (This function is available to all lists which can be grouped).
Use case:
With the new settings, the usage of list setups can be further customized to own needs and enables to use further restriction for the cockpit users.
Usage:
- Edit the master data of a setup inside the BasicData or SD.cockpit setup area.
- Use the flags for ListLink, TableLink, GraphicLink, and TreeLink to switch them on and off.
- Per default all four flags are enabled for all new assigned list setups.
- The TreeLink flag is only available to lists which can be viewed as tree (For example, device lists).
The SD.cockpit allows defining those flags additionally at the master data of a cockpit element. The definitions performed inside the cockpit element overrule the same definitions of the setup.
New list setup options:
Options | Description |
ListLink | Indicates if the "List" link for switching to the list view should be shown. |
TableLink | Indicates if the "Table" link for switching to the table view should be shown. |
GraphicLink | Indicates if the "Graphic" link for switching to the graphic view should be shown. |
TreeLink | Indicates if the "Tree" link for switching to the tree view should be shown. |
Hour and minute based reports of calls
Four new fields are added to the CallTracking lists which enable to create lists, and reports based on the hour or minute calls have been opened or closed.
Use case:
- Create a grouped CallTracking list which calculates the amount of calls that happened at a defined time of a day (hour or minute).
- Create graphics which show the amount of calls opened or closed per hour or minute.
Usage:
- Edit a CallTracking list, add one of the new fields, and add the number field as well.
- Group by one of the new fields CallCloseHour, CallCloseMinute, CallOpenHour, CallOpenMinute.
- Use the list view to see the results as list, or create a business graphic by using the graphic option.
New CallTracking setup field:
The following are the New CallTracking setup fields:
Field Name | Description |
CallCloseHour | Holds the hour of the call close. For example, 9, 10, 14. |
CallCloseMinute | Holds the minutes of the call close. For example, 34, 50, 24. |
CallOpenHour | Holds the hour of the call open. For example, 9, 10, 14. |
CallOpenMinute | Holds the minutes of the call open. For example, 34, 50, 24. |
Measure Operational Level Agreements (OLAs)
One of the newest functions of the Summer Release is introducing support for Operational Level Agreements. With 4.10, it is possible to define OLA to measure the internal service quality.
Use case:
Measure own defined OLAs inside your service processes.
How much time was a call in the second level?
How much time has past between two CallStates?
Usage:
OLA Administration:
Use the new OperationLevelAgreements subfolder inside CallSystem > Workflow to define an OLA and the CallState where the time measure should start and stop.
Use the Create new OperationLevelAgreement to create a new OLA.
Use the Show all CallStates with all OperationLevelAgreements to view a matrix of all created OLAs and their CallStates.
Create a new OLA:
- Use the Create new OperationLevelAgreement to create a new OLA.
- Define a ShortName, Name, and OLAMinutes (OLA times) for the new OLA.
- Save the new OLA by using the Save button.
- After an OLA was created the Assign Service Times allows setting the Service Times for the OLA.
- Use the Assign CallState function to define the measure points of the OLA. You can use multiple CallStats for start and end of the OLA times.
- The same CallState may not be the start and stop point at the same time.
- Select the start and stop points by setting a flag in the IsStartOLA or IsStopOLA.
- After the selection is done click Submit to submit the changes similar to setup editor.
Addition to the manual entry of the OLA start and end points, an upload and download function are provided. The upload file has to contain the fields CallSystem, OperationLevelAgreement, CallState, StartOLAFlag, and StopOLAFlag to perform successful upload.
NOTE: An OLA definition can have more than one start and stop points. A start point will not be overwritten by another start point and a stop point will not be overwritten by another stop point. If an OLA was started and stopped and a CallState is reached which would start the OLA again. The OLA will start to run again until another stop point is reached. The times will be added to a total time.
Use OLA values inside of CallTracking lists (for reporting):
The OLA times can be shown inside of CallTracking lists, which can be shown as list or cockpit graphic.
Add one of the following fields to a CallTracking list. The OLA which should be shown is selected via the field option "OLA". Even if only one OLA is available this selection has to be done.
Field Name | Field Description |
SCOLAMinutes | OLAMinutes of an OLA of the customer. |
SPOLAMinutes | OLAMinutes of an OLA of the provider. |
SCOLATotalMinutes | TotalMinutes of an OLA of the customer. |
SPOLATotalMinutes | TotalMinutes of an OLA of the provider. |
Changes / Bug fixes / Updates
Updates: Style sheets (color themes)
- Updates and correction of the style sheets settings have been made to improve the online interface.
- The standard style shows error messages as white messages on red background.
Update: Assign Parent / Child Setups
Previously, when a user changed between a CallTracking and a CallDetail, and was working with the assignment of children or parent calls and exited from the call to the CallTrackinglist, a wrong setup was sometimes shown.This behavior was corrected. The system will now show the correct CallTracking list.
Change: Service time templates for SLAs and OLAs
With the introduction of OLAs and the extended SLA time definition, the already implemented function Service Times becomes more important.
Previously, the service times were used for import inside of SLAs only and could also handle priorities.
Now Service Times provides functions to create and maintain service time templates for SLAs and OLAs. A service time template defines the time in between which services are active and are used inside the SLA master data of services (contract elements or service items) and by OLAs.
For example:SLA/OLA runs Monday till Friday from 09:00 till 17:00 with no service for weekends.
Usage:
Service time templates are administrated inside the BasicData > MyCompany > Setups > Contracts > Service Times.
Changes:
Through the generalization of the Service Times (used by OLAs and SLAs) the definition of the following are no longer defined inside the Service Times:
ResponseTime, RecoveryTime, RecoveryAlertMinutes1, RecoveryAlertMinutes2, UseCutOff, CutOffTime1, BusinessDays, and CutOffTime2.
Change: Translation for German: Serverity > Ernsthaftigkeit
With the introduction of the priority matrix and its urgency and impact codes, it was necessary to correct the German translation of serverity which was Dringlichkeit. The new translation has been changed to Ernsthaftigkeit.
For a complete list of Cisco ServiceGrid Articles, go to the List of Articles page.