Service Level Agreement – its Configuration, Usage & Execution

From OSP dictionary, we would define Service Level Agreement as a systematic supervisor who ensures the tasks are completed on-time.

Consider a leave management application where an employee submits a leave request & manager approves it within 2 business days from the date of submission. Senior manager should ensure that all leave requests submitted by employees are approved by managers on-time.

It becomes hard for senior manager to keep track of all the leave requests and remind managers about the pending requests 😣

Wouldn’t it be nice if system takes care of reminding managers about the leave requests pending for their approval & escalating it to senior manager if not approved in 2 business days?🤔

Yes, PEGA does support that feature using Service Level Agreement 😊

What is Service Level Agreement?

SLA rule in PEGA defines different intervals to ensure that the task is completed on-time. If the time specified to complete the task is elapsed, then the escalation action can be taken.

• Goal — The suggested time to complete the task.
• Deadline — The actual time to complete the task.
• Passed deadline — The time that has passed since the deadline. After the deadline is overdue, it repeats ‘n’ number of times, or repeats indefinitely until the task is completed.

What is Urgency?

SLA updates urgency in different intervals which helps in prioritizing task to retrieve the most urgent work.

• Urgency is a numeric value between 0 & 100.
• It can be incremented at each interval [Goal, Deadline. Passed deadline] in a SLA rule.
• Calculated urgency will be used to prioritize items in user’s worklist, workbasket and during Get next work.

How to configure a SLA Rule?

• SLA rule is an instance of class RULE-OBJ-SERVICELEVEL.
• SLA events are written to queue class System-Queue-ServiceLevel and are processed by an OOTB agent ServiceLevelEvents of ruleset Pega-ProCom.

• SLA rule can be found under Process category in Records Explorer.

Start of service level

Initial urgency & condition to trigger the SLA rule will be set using this section.

A SLA can be marked as ready based on three different conditions. SLA entry will be written to the queue class only when the specified condition is met.

• Immediately: SLA entry will be written to the queue class as soon as the assignment that has the SLA defined gets created.
• Dynamically defined on a property: This accepts a date-time property as input and writes an entry into queue class only when the specified date time is reached.
• Timed delay: SLA entry will be written into queue class with a timed delay specified in days, hours and minutes fields.

Service Level Definitions

This section is used to define different intervals in SLA [Goal, Deadline and Passed deadline]. Intervals can be defined in two ways as shown below,

Goal

• Goal is the suggested time within which the task should be completed.
• In the above scenario, manager should approve each leave request in 2 business days. Hence 1 business day can be specified as goal time which is actually the suggested time before which the leave request should be approved.

• Since our calculation involves business days, Goal time calculation is enabled to use business days. Business days are the working days of an organization defined in the calendar instance.
• Calendar name for business day calculation will be referred from pyWorkPage.pyCalendar if set. If the value is empty, then calendar name under pxRequestor page pxRequestor.pyCalendar will be used for business day calculation. Activity SetCalendar invoked from InitialProfileSetUp sets the value for pxRequestor.pyCalendar.
• When the goal time is reached,
  • Urgency gets increased by 20.
  • Notify Assignee action gets invoked which sends a reminder email to the manager with whom the request is pending with.

Deadline

• Deadline is the actual time within which the task must be completed.
• In the above scenario, manager should approve each leave request in 2 business days. Hence 2 business days will be the deadline time, which is the actual time before which the leave request must be approved.

• When the deadline time is reached,
  • Urgency gets increased by 30.
  • Notify Assignee action gets invoked which sends a reminder email to the manager with whom the request is pending with.

Passed deadline

• Passed deadline can be used for the item which exceeds the specified deadline. Passed deadline can be configured to repeat the action ‘n’ number of times.
• In the above scenario, request should be escalated to senior manager if it’s not approved within 2 business days.

• With the above configuration, escalation action Notify Manager sends escalation emails for three consecutive days.
• Urgency will be increased by 10 on each attempt in passed deadline.

Hope now the configuration of SLA is clear. Let us now explore the possible ways of referring SLA in PEGA.

Types of SLA

SLA rule once configured can be referred in Case level, Stage level, Step level, Flow level or Assignment level.

Let’s consider a HR Application with on-boarding case type to examine each type of SLA, its configuration and back-end execution in detail.

Case level/Overall SLA

• A SLA rule when referred at case level is called as a case/Overall SLA. This is applicable throughout the life cycle of a case.
• It starts when a case is instantiated (or reopened), and stops when the case is resolved.
• The service-level agreement rule is identified in the standard property pySLAName under work page. This can be set using pyDefault data transform during the instantiation of the case.
• The Overall SLA urgency is set in a property pxUrgencyWorkSLA under pyWorkPage.

Scenario Overview

Each on-boarding case created in system should be resolved in 6 days. If not, it should be escalated to the assignee’s manager.

Implementation

• A SLA is configured with initial urgency as 10, Goal as 5 days with urgency as 20 and deadline as 6 days with urgency as 30 . Passed deadline event is configured to send escalation email to assignee’s manager.
• pyDefault data transform is specialized in the on-boarding work class and configured SLA rule is set to pySLAName.

• During on-boarding case creation, DefineSLATimes activity invokes Assign-AddAssign to queue the goal event to the SLA agent.

• System creates an internal flow OverallSLA with an assignment of class Assign-Internal, which invokes the defined Overall SLA rule.

• OverallSLA flow will be created as a parallel flow during case instantiation. It will be completed by system using a ticket Status-Resolved set in Resolve activity.

• Queue entry created for the overall SLA has all the details of execution. This queue entry will be picked and processed by the ServiceLevelEvents standard agent which increases the urgency and executes the escalation actions mentioned in the SLA rule.

Urgency calculation in Overall SLA

Urgency gets calculated using the below declare expression.

.pxUrgencyWork = @min(100,@max(0,.pxUrgencyWorkClass + .pyUrgencyWorkAdjust + .pxUrgencyWorkSLA + .pxUrgencyPartyTotal + .pxUrgencyWorkStageSLA +.pxUrgencyWorkStepSLA))

• pxUrgencyWorkClass -> Urgency value set using pyDefault data transform. It is 10 by default.
• pyUrgencyWorkAdjust -> An extension point that can be used to adjust urgency value anytime in between flow.
• pxUrgencyWorkSLA -> Urgency value set by the overall SLA execution. In our case, overall SLA initial urgency is 10, goal time urgency is 20 and deadline time urgency is 30.
• pxUrgencyPartyTotal -> Work parties in PEGA can have urgency set and this property holds the sum of parties urgency in a given case.

• pxUrgencyWorkStageSLA -> Urgency value set by the stage level SLA. This is explained in later part of the post.
• pxUrgencyWorkStepSLA -> Urgency value set by the Step/Flow level SLA. This is explained in later part of the post.

All the urgency related properties for overall SLA can be viewed under pyWorkPage in clipboard.

When goal time is reached for overall SLA, then pxUrgencyWorkSLA will be incremented to 30 which in-turn updates pxUrgencyWork to 40.

Stage level SLA

• A SLA rule when referred at stage will be called as Stage level SLA.
• It starts when a case enters a stage and ends when the case leaves the stage.
• The stage level urgency is set in a property pxUrgencyWorkStageSLA under pyWorkPage.

Scenario Overview

Document Submission stage in on-boarding case type should be completed within 2 days.

Implementation

• A SLA is configured with initial urgency as 5, Goal as 1 day with urgency as 5 and deadline as 2 days with urgency as 10 . Passed deadline event is configured to send escalation email to assignee’s manager.
• SLA rule is referred in Document Submission stage under stages tab in the on-boarding case type rule.

• During on-boarding case stage instantiation, pxChangeStage activity invokes Assign- DefineSLATimes of class which queues goal event to the SLA agent.
• System creates an internal flow pzInternalStageFlow with an assignment of class Assign-Internal, which invokes the Stage SLA rule.

• pzInternalStageFlow will be created as a parallel flow during stage instantiation. It will be completed by system using a ticket Status-Resolved set during stage completion.

• Queue entry created for the Stage SLA has all the details of execution. This queue entry will be picked and processed by the ServiceLevelEvents standard agent which increases the urgency and executes the escalation actions mentioned in the SLA rule.

Urgency calculation in Stage SLA

Urgency gets calculated using the same expression discussed above.

.pxUrgencyWork = @min(100,@max(0,.pxUrgencyWorkClass + .pyUrgencyWorkAdjust + .pxUrgencyWorkSLA + .pxUrgencyPartyTotal + .pxUrgencyWorkStageSLA +.pxUrgencyWorkStepSLA))

Where,
pxUrgencyWorkStageSLA is the urgency value set by the stage level SLA. In our case, Stage SLA initial urgency is 5, goal time urgency is 5 and deadline time urgency is 10.

All the urgency related properties for Stage SLA can be viewed under pyWorkPage in clipboard.

When goal time is reached for Stage SLA, pxUrgencyWorkStageSLA will be incremented to 10 which in-turn updates pxUrgencyWork to 30.

Step/Flow level SLA

• A SLA rule referred in Step/flow level is called as Step/Flow SLA respectively.
  • Step level – Starts when a step/process starts and ends when the step/process ends.
  • Flow level – Starts when a flow starts and ends when the flow ends.
• A step service-level agreement overrides a flow service-level agreement, if present.
  • Step SLA can be referred in each step under stage in case type rule.
  • Flow SLA can be referred under process tab of the flow rule.
• The step/flow level urgency is set in a property pxUrgencyWorkStepSLA under pyWorkPage.

Step and flow level SLA implementation functions similar to Overall and stage level SLA. So let’s directly jump into back-end execution of Flow SLA.

• During flow execution, DefineSLATimes activity invokes Assign-AddAssign to queue the goal event to the SLA agent.
• System creates an internal flow pzInternalProcessFlow with an assignment of class Assign-Internal, which invokes the Flow SLA rule.

• pzInternalProcessFlow will be created as a parallel flow during flow execution. It will be completed by system using a ticket Status-Resolved set during the flow completion.

• Queue entry created for the Flow SLA has all the details of execution. This queue entry will be picked and processed by the ServiceLevelEvents standard agent which increases the urgency and executes the escalation actions mentioned in the SLA rule.

Urgency calculation in Step/Flow SLA

Urgency gets calculated using the same expression discussed above.

.pxUrgencyWork = @min(100,@max(0,.pxUrgencyWorkClass + .pyUrgencyWorkAdjust + .pxUrgencyWorkSLA + .pxUrgencyPartyTotal + .pxUrgencyWorkStageSLA +.pxUrgencyWorkStepSLA))

Where,
pxUrgencyWorkStepSLA is the urgency value set by the Step/Flow level SLA. In our case, Flow SLA initial urgency is 5, goal time urgency is 5 and deadline time urgency is 10.

All the urgency related properties for Flow SLA can be viewed under pyWorkPage in clipboard.

When goal time is reached for Flow SLA, pxUrgencyWorkStepSLA will be incremented to 10 which in-turn updates pxUrgencyWork to 35.

Assignment level SLA

• A SLA rule when referred at assignment is called as assignment SLA.
• It starts when the assignment is created and ends when the assignment is completed.
• The assignment urgency is set in a property pxUrgencyAssignSLA under newAssignPage.

Scenario Overview

Document submission process has two assignments,
Assignment 1-> where organization sends a link to upload documents
Assignment 2-> where resource uploads documents using the received link.

Document upload must be completed in 4 hrs from the time of receiving link.

Implementation

• A SLA is configured with initial urgency as 10, Goal time as 2 hrs with urgency as 10 and deadline time as 4 hrs with urgency as 20. Passed deadline event is configured to send escalation email to assignee’s manager.
• Created SLA rule is referred in upload documents assignment in the document submission process.

• During assignment creation, activity Assign-AddAssign queues the goal event to the SLA Agent.

• Queue entry created for the Assignment SLA has all the details of execution. This queue entry will be picked and processed by the ServiceLevelEvents standard agent which increases the urgency and executes the escalation actions mentioned in the SLA rule.

Urgency calculation is assignment SLA

Urgency gets calculated using below declare expression during assignment creation.

.pxUrgencyAssign= @min(100,@max(0, .pxUrgencyWork + .pxUrgencyAssignSLA + .pyUrgencyAssignAdjust))

• pxUrgencyWork -> Work level SLA calculated by aggregating initial urgency, overall SLA and Stage SLA.
• pxUrgencyAssignSLA -> Assignment urgency calculated from the SLA rule. In our case initial urgency is 10, goal time urgency is 10 and deadline time urgency is 20
• pyUrgencyAssignAdjust -> Extension point which can be used to adjust urgency value based on the business need.

newAssignPage in clipboard holds assignment level urgency properties.

When goal time is reached for assignment SLA, then pxUrgencyAssignSLA will be incremented to 20 which in-turn updates pxUrgencyAssign to 45.

Prioritization of Work using Urgency

Most common usage of Urgency are listed below,

• pyUserWorkList report definition used to display work items from worklist uses pxUrgencyAssign to sort the records.
• pyGetWorkBasket report definition used to display work items from workbasket uses pxUrgencyAssign to sort the records.
• List views Assign-Workbasket GetNextWork and Assign-Worklist GetNextWork uses pxUrgencyAssign to sort the records before identifying assignments to pull from Get Next Work.

How are events written to Queue class?

• During SLA invocation, system takes care of writing an entry for GOAL event into queue class which is mapped to table pr_sys_queue_sla.
• Standard agent activity ProcessEvent takes care of creating a new entry for DEADLINE during GOAL event processing.
• Standard agent activity ProcessEvent takes care of creating a new entry for LATE/Passed Deadline during DEADLINE event processing.

How to Debug SLA?

Since SLA events are processed using OOTB standard agent ServiceLevelEvents, it can be debugged in the same way how standard agents are debugged.

We will write an article soon on Agents where we will cover how to debug agents. Till then, you can refer this article to troubleshoot SLA agent.

Can End User Access/Update SLA?

End User can access/update SLA rule in two ways.

• If user wants to update SLA of a single assignment in a case, it can be done using pyAdjustAssignmentSLA local action.
• If user wants to update SLA for all new cases that gets created, it can done by delegating the SLA rule.

Pointers to remember

• SLA events are written to queue class System-Queue-ServiceLevel and are processed by the OOTB standard agent ServiceLevelEvents of ruleset Pega-ProCom
• Locking is always an issue when parallel update happens to a case. SLA agent by default takes care of handling exception and retrying in case of failure.
• SLA rule can be delegated to business users, but delegated SLA rule will only have minimal level of information to update.
• SLA agents by default will be configured to run on background processing node type.

We are glad to publish the article requested by @ Radhika on “Service Level Agreement“. If you want us to publish any articles of your choice, please fill out this form & we will make sure it gets published.

Stay tuned for more posts on Background Processing !!!