- Service Level Agreement main objective is to process any time bound requirements in the application.
Imagine, Timesheet application. If an employee fails to submit timesheet by end of month (April 30th), then he/she has to be sent with a reminder email. If he/she didn’t submit after 5th of next month, then we should send an email copy reporting Manager.
In Pega, we can have a separate case generated for those who didn’t submit Timesheet and we have have an SLA running for the case.
SLA can be configured to send an email to the employee.
We will discuss about it in detail later in this post.
What is a SLA?
SLA – Service Level Agreement.
- SLA is supported by a Pega OOTB agent – ServiceLevelEvents under Pega-ProCom agent.
- We can configure the SLA on an entire flow or for a particular assignment.
- SLAs can update the urgencies as well as executing the Escalation activities (like sending Email).
How do we configure a SLA?
- SLA rule comes under Process category.
Create a new SLA rule.
- There is single main tab – General
In this, we configure the urgency calculation as well as configure the escalation activities.
Start of Service Level
Initial Urgency – We can set a numeric value between 0-99.
What do you mean by urgency?
- Urgency can be associated with assignment as well as work item.
- Numeric value can be set from 0-99 range.
- In most of the application, we use urgency to prioritize the unresolved cases.
- So based on urgency, we can sort the worklist or workbasket and also we can use GetNextWork to pull the work item with highest urgency.
- Normally for every assignment the urgency is default to 10.
Imagine, if you configure this SLA in an assignment shape with Initial urgency as 10. Then the total urgency will be Default urgency (10) + Initial Urgency (10) = 20
Assignment Ready – There are 3 values which you can configure for assignment ready.
Let’s first discuss, “Why do we need this field?”
Imagine in an Organization, a particular division – say call center division works from 9 p.m to 6 a.m
That means user can start working on their case only from 9 p.m. In such cases, we can start the SLA from the start time not the assignment creation time.
Assignments can be created and assigned to the user by mid-day, say 11 am. But no one is there to work and some business don’t want to start the SLA from the assignment creation time.
Hope you get it 🙂
Now, let’s get to the options available:
- Immediately – As soon as the assignment is created.
- Dynamically defined on a property – We can refer a property and set the time prior.
- Time delay – You can introduce a time delay (some constant values).
Service Level Definitions
Before checking the configuration, let’s know about the basics of the definitions.
There are 3 definitions available in a Service level:
- Passed deadline
Imagine I got a postpaid connection and need to pay the bill by 25th of every month.
The service providers have some business policies like, on 25th they will send me an e-mail along with post mail.
If I didn’t pay my bill by 27th, then they will send a reminder again.
If I still didn’t pay the bill by 30th, then they will start sending a reminder mail in 3 days’ time interval by adding Rs.100 each day as a fine amount.
Let us solve this in Pega. Imagine, here we create a work item by 24th of every month for all the connections. The work item will get resolved after bill payment.
Calculate Service levels –
We know Assignment ready field is the starting point for SLA calculation.
a) Interval from when assignment is ready
For the postpaid bill scenario, I set the goal date as 1 day next to work item creation.
Work item creation date – 24th,so goal date will be 25th. You can also restrict it to business days.
b) Set to the value of a property – You can set the date value to the property dynamically prior.
We can use some property like BillGoalDate with values as 25th of that month.
Goal Date – 25th
As per our requirement, on 25th they need to send a reminder mail to the user (me).
So goal date, we can configure the SLA as Notify Party. You can also use custom Run activity to solve your business requirement.
You also have an option to increase the urgency of the case on goal date.
Now we have configured GOAL.
Deadline – 27th
Note: Deadline date time interval is calculated from assignment ready date. Not from goal date.
So work item creation date is 24th and deadline(second reminder) on 27th, so you can configure deadline as 3 days. Increase urgency value and execute notify party escalation activity.
Passed Deadline – 30th – It means 3 days after our deadline 27th.
Note: Passed deadline date time interval is calculated from deadline date. So it’s 3 days.
You have an option to repeat the same escalation process for n number of times.
Here, in our example it is for 20 times. So by 3rd , 6th,… of next month the same passed deadline escalation events occur.
What are the types of SLA?
The was by which we use SLA, it is of two types:
- Assignment SLA
- Work item SLA
What is an Assignment level SLA?
- We can specify time bound process for particular assignments.
Throughout the application, I will explain with a simple leave application.
Step 1: Create a SLA rule.
We set Initial urgency to 10 & Assignment ready – Immediately.
For testing purpose, I set the goal as 10 seconds and Urgency will be increased by 20.
Now, SLA is ready.
Step 2: Create a sample flow rule with an assignment shape.
Step 3: Configure the SLA in the assignment shape.
You will see a clock symbol in the assignment shape. Remember, whenever you see a clock symbol in the assignment shape, it means SLA is configured.
Remember to route the assignment to your Operator ID and configure my work to see your worklist.
Step 4: Run the flow rule. Flow rests on assignment shape, where it expects user input.
Assignment urgency is calculated using the Declare Expression,
pxUrgencyAssign = @min(100,@max(0, .pxUrgencyWork + .pxUrgencySLA + .pxUrgencyAdjust)))
Min max is for restricting the value within 100. Cool 🙂
pxUrgencyWork – Work SLA (Default 10)
pxUrgencySLA – What we set from SLA
pxUrgencyAdjust – Manually, we can adjust SLA
We set SLA Initial urgency is 10.
So Urgency should be 20 at the time of work item creation.
Refresh the worklist in sometime, the SLA agent should run and set the Urgency to 40.
Yes, it is 🙂
Let us now trace and check what is happening behind the scene.
Step 5: Trace the flow run.
- You can see ‘DefineSLATimes’ activity which sets the SLA value to Assign-Worklist class.
You can verify the assignment SLA values in PC_ASSIGN_WorkList table as well as in the clipboard newassignpage. You can find other values too. Like when is the goal date, deadline date, etc.,.
- You can see Assign-.AddAssign activity getting called and declare expression getting fired.
AddAssign activity is responsible for queuing the Goal event to SLA Agent.
The standard SLA agent activity does the rest in Updating SLA, based on Goal/ Deadline and executing escalation activities.
What is a Work-item level SLA?
- We can configure an SLA to run on the complete workitem life cycle.
Imagine, you are in a repair application. The business is like whatever repair request comes in, it should be solved in 5 days. Irrespective of how many people work, it is basically like tracking the entire life cycle. You can implement a work item SLA to send reminder mail/Advance flow/Auto approve.
We will try to use up the same Leave request flow as an example.
Step 1: Create a SLA – Use the same SLA.
Step 2: Create a Flow rule – Use the same flow 😀
Step 3: In the process tab of the flow rule, add the Service Level agreement.
Actually pySLAName is the property configured in the SLA rule form.
You can dynamically update the value ‘pySLAName in the pyDefault data transform too, at the time of work item creation.
Step 4: Run the flow rule and check the work item urgency.
pxUrgencyWork = @min(100,@max(0,.pxUrgencyWorkClass + .pyUrgencyWorkAdjust + .pxUrgencyWorkSLA + .pxUrgencyPartyTotal + .pxUrgencyWorkStageSLA +.pxUrgencyWorkStepSLA))
pxUrgencyWorkClass – Default work SLA – 10
pyUrgencyWorkAdjust – You can manually adjust the SLA by setting the value here.
pxUrgencyWorkSLA – Urgency configured in the work item SLA – 10
pxUrgencyPartyTotal – Urgency included for each party with the application -0
Based on the flow type, pxUrgencyWorkStageSLA, pxUrgencyWorkStepSLA are assigned.
Since it is Internal process flow, pxUrgencyWorkStepSLA = 10
Let’s wait for goal time and check the case urgency and status.
The Urgency is increased.
Let us now trace and check, what is happening behind the scene.
Step 5: Trace the flow run.
SaveNew – > DefineSLATimes -> OverallSLA (Flow rule)
It is nothing but a parallel flow to the workitem with single assignment shape.
If you see the assignment shape, then SLA is configured. Now it leads to the assignment SLA.
There is a router activity, which routes the assignment to workbasket firstname.lastname@example.org
You may get a question, “So what happens to this assignment? Who will process it?”
Yes, the OverallSLA flow will end, when the main process flow ends.
Tracer snippet after resolving the primary, leave request flow. Overall SLA flow ends with a ticket.
How to configure SLA in a Case?
From the case designer, you can open the case settings tab.
You can configure the goal and deadline time here.
On saving the form, a SLA rule name ‘pyCaseTypeDefault’ is created in that class.
In the case designer, you select parent case or top level case as start time.
Then the SLA rule assignment ready is configured dynamically with a property.
Finally we are at the end of SLA post 🙂
What do we need to remember while configuring SLA rule?
- SLA processing depends on Standard Pega-ProCom agent – ProcessSLAEvents (Discussed in detail in ‘Requestor types‘ (http://myknowpega.com/2017/05/13/requestor-types/) post).
- Remember SLA agent needs lock to update the workitem. If lock is acquired by any other user, then SLA processing will get delayed.
- You can adjust the SLA times dynamically. Pega provides OOTB flowaction ‘pyAdjustSLA’, ‘pyAdjustSLATimes’. Check out these.
- You can delegate the SLA rule to business users.