ServiceGrid Article - Workflow

From DocWiki

Jump to: navigation, search

Contents

Overview

The workflow folder combines all the settings required to build a workflow and contains function to map a workflow to another workflow. Here are the workflows:

  • CallAction
  • CallStates
  • Successors

Important: The CallSystem master data settings have an additional impact on how the process must be used.

CallAction

CallActions are used to move from one call state to the next call state. With its options, it defines how this transformation should be performed. A call action can be automated or requires a user interaction.

  1. To create a new CallAction select the Create new CallAction function.
  2. At least the “ShortName” and the “Name” of the CallAction must be given to create a new CallAction.
  3. Use the other options to enrich the functionality of the CallAction.

CallActions options

Options
Description
ShortName
Indicates the short name of the CallAction (12 characters)
Name
Indicates the name of the CallAction (12 characters)
SeqNr
Indicates the sequence number of the CallAction, used for sorting the CallActions
Start
Indicates that this is a start CallAction
AutoSave
Indicates that the transformation will be saved automatically when using the CallAction without asking the performing user. Example: Automated escalation to another level
LockCall
Indicates the option to lock calls
DetailSetup
Indicates which CallDetail setup should be used when performing the action
MobileSetup
Indicates which mobile setup should be used when performing the action
UserExit

DefaultStart
Indicates if the workflow should start with this state
CreateParent
Indicates if a parent call should be created
CreateChildren
Indicates if a child call should be created
UpdateParent
Optionss: No, Use Successors, Ignore Successors
UpdateChildren

Options: No, Use Successors, Ignore Successors

NOTE: The above options are defined, if the children calls are updated

Permissiongroups
Indicates if a CallAction is assigned to permission groups



















Assign CallAction to permission groups

A call action can be defined to be used by selected permission groups (user groups). Therefore, the required permission groups must be assigned to the desired CallAction.

  1. Click on “CallAction” and select the required CallAction.
  2. Select the “Display permissiongroups” to see the currently assigned permissiongroups.
  3. Click on “Assign permissiongroups to callaction” to add / change and manage the assigned permission groups.
  4. Change the settings by selecting or unselecting the permission groups and save the changes using the “Submit” button.

NOTE:
Once permission groups were assigned, the CallAction is unavailable to all other permission groups. This is a very powerful way to allow selected CallActions to be used by selected user groups only.

Assign CallAction to contract elements,

A CallAction can be defined to be used by selected contract elements only. Therefore, the required contract elements must be assigned to the desired CallAction.

  1. Click on “CallAction” and select the required CallAction.
  2. Select the “Display contractelement” to see the currently assigned contract elements.
  3. Click on “Assign contractelements to callaction [ShortName]” to add / change and manage the assigned contract elements.
  4. Change the settings by selecting or unselecting the contract elements and save thechanges using the “Submit” button.
  5. Click on “Display serviceitems” for change to the assigned contract elements.

NOTE: 
Once service items or contract elements (services) were assigned, the call action will be unavailable to all other services. This is a very powerful way to allow selected call actions only special services.

Assign CallAction to service items

A call action can be defined to be used by selected service items. Therefore, the required service items have to be assigned to the desired call action.

  1. Click on “CallAction” and select the required CallAction.
  2. Select the “Display serviceitems” to see the currently assigned service items.
  3. Click on “Assign serviceitems to callaction [ShortName]” to add / change and manage the assigned service items.
  4. Change the settings by selecting or unselecting the service itemes and save the changes using the “Submit” button.
  5. Click on “Display contractelements” for change to the assigned contract elements.

NOTE:

Once service items or contract elements (services) were assigned, the call action will be unavailable to all other services. This is a very powerful way to allow selected call actions only special services.

Call States

Call states describe where in a given workflow a service request, or Call, currently is. There is no limit to the number of CallStates in a workflow, but note that the number of CallStates indicate the level of complexity. Every CallState has to be set up separately with the options detailed below.

Despite the fact that it is possible, take care that all CallState.ShortName and CallState.Name within a CallSystem are unique.
Reason:
Callstates can be identified in templates through a given ShortName and / or a Name. The system tries to find the requested CallState by using the given data in an SQL-Statement.
There is no technical restriction that hinders an administrator to create several Callstates with identical ShortNames or Names – but different mapping and/or Flags. The system uses the first item it can find. If the system can find more than one item, the item which will be used is not predictable.
For example, you have created two CallStates with the ShortName “Open”. One with Call-open-flag and the other without the Call-open-flag. For several years your implemented system works in creating tickets with the CallState “Open”. Suddenly the system decides to take the other one (the one without the CallOpen-Flag) – and your implementation stops working and produces error messages. Such a problem is hard to find. Similar problems can occur with all other flags.

Create / edit a CallState

For creating a new CallState, use the “Create new call state code” or select an existing CallState to edit. At least the fields “ShortName”, “Name” and “Level” have to be defined to create a new call state.

Here are the Call State options:

Option
Description
ShortName
Indicates the short name of the call state (up to maximum 20 characters)
Name
Indicates the name of the call state
SeqNr

Indicates the sequence number of the call state. This is optional.

CallStates will be sorted in the CallStates list initially by sequence number, and then alphabetically. 

Icon
Optional icon for the CallState that may be displayed in CallTracking lists.
IsActiveInEditForm
Used to soft-delete a call state. This flag defines if the call state should be shown in CallState dropdown boxes in CallDetail forms.
IsActiveInLists
Used to soft-delete a call state. This flag defines if the call state should be shown in lists filter criteria (i.e., if it can be selected to filter on it). Calls that are currently in a "hidden" CallState will still show up on the list.
Level
Assigns the call state to a level (1, 2, or 3)
RetentionTime
Defines how long this call state is allowed to stay in this status (in hours). May be used as a trigger for escalation messages.
Start
Defines if the call state is a start status. Every workflow needs at least one start status.
Stop
Defines if the call state is an end status. Every workflow should have at least one end status. Calls that are in a CallState with the stop flag set to 'Y', cannot be updated anymore.
Open
Will set the call open timestamp (Yes, overwrite)
StartSLA
Will start the SLA time (Yes, No, Overwrite)
Acknowledge
Will set the acknowledge timestamp (Yes, No, Overwrite)
Response
Will set the CallResponse timestamp (Yes, No, Overwrite)
Recovery
Will set the CallRecover timestamp (Yes, No, Overwrite)
Close
Will set the CallClose timestamp (Yes, No, Overwrite)
Busy
Used for dispatching of technicians. Will show a technician as "busy" in the dispatching overview, when the technician is assigned to a Call with a CallState flag of Busy = 'Y' (checkbox)
HoldSLA
Will stop the SLA calculation until a call state with "ContinueSLA" is reached (checkbox).
ContinueSLA

Will continue a stopped SLA calculation (checkbox).

Yes/No/Overwrite
  • Yes - 'Yes' state will set the timestamp (using the system time), if it is not set before. If it is already set, there will no change. If the CallDetailSetup includes the respective field, and if a date and time is set in that field, that is the timestamp which will be stored in the database, and not the system time.

    Example: If SLA is set to "Yes" multiple times in a workflow, the SLA will be measure from the first time the timestampp was       set, no matter how many more time the flag is set to "Yes".

  • No - Will not set the timestamp.
  • Overwrite - Will set the timestamp and overwrites any other earlier set time, iF the field is included in the CallDetailSetup and a date and time is entered (even if by default). System time is only used in case the timestamp is currently empty and either the timestamp field is not part of the CallDetailSetup or if the field is part of the setup, but empty. System time will never be used to overwrite an existing timestamp.

    Example: If Recovery is set to "Overwrite", then the timestamp will be set for the first time when that status is reached.    
    However, if the customer doesn't agree with the solution and the ticket moves back to a "pending" or an "in progress" state, the
    Recovery time will be overwritten once that status is reached again. This will result in a more accurate measurement of the total     Recovery time if you customers have to agree to a solution.




































Successors

Successors are used to define the flow of the process. Only call states which fulfill the successor rules can be accessed next.

Defining successors

  1. Select the “Change successors” function to define the successor rules.
  2. Select the follow up call state on the right.
  3. Select the “CallAction” which should be used for the transformation.
  4. If more than one successor per CallState should be defined assign the first one, save the entry and click the “Change successors” again to have a second row added.
  5. Continue this unless you have defined all your successors.

The changes will be activated immediately.

Mapping Workflows

Before mapping two workflows, make sure that this is allowed in the settings of the PossibleCallSystemMappings


For a complete list of Cisco ServiceGrid Articles, go to the List of Articles page.


Related Articles

Workflow Pattern

Rating: 0.0/5 (0 votes cast)

Personal tools