Service Level Agreements in Pega

In this blog article, we will see in detail about Service level agreements.

The main objective of Service Level Agreement is to process any time bound requirements in the Pega application.

Imagine, Timesheet Pega application.

Reminder email – If an employee fails to submit the timesheet by the end of the month (April 30th), then he/she will be sent a reminder email.

Escalation email – If he/she doesn’t submit after the 5th of next month, then the application should send an email copy to the reporting Manager.

SLA can be configured at different levels in a Pega application.

1. Case level
2. Stage level
3. Process level
4. Step level / Assignment level

We will see about these 4 types shortly in this blog article.

What is an SLA rule?

SLA – Service Level Agreement.

SLA rule is part of Process category where you can configure the time-bound configurations like goal time, deadline time and also configure the escalation activities or urgency increase that need to be executed when the time is crossed.

SLA rule can be configured at different levels and uses background processing to execute the SLA activities.

SLA is supported by a Pega OOTB agent – ServiceLevelEvents under Pega-ProCom agent or in the latest versions using Pega OOTB queue processor – pyProcessSLA.

SLAs can update the urgencies as well as execute the Escalation activities (like sending Emails).

How do we create and configure a SLA?

Create a new SLA rule.

Records -> Process -> ServiceLevelAgreement -> Create New

There is single main tab – General

General Tab

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 assignments as well as work item.

– Numeric value can be set from 0-99 range.

In most of the applications, 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 the highest urgency.

Normally for every assignment/case, the urgency is default to 10.

Now if you configure this SLA in an assignment shape with Initial urgency as 10. When the flow reaches the assignment shape, the total urgency will be calculated as  Default urgency (10) + Initial Urgency (10) = 20

We will see about these calculations very shortly. For now, just understand that for every SLA rule, you can already configure an initial urgency.

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 centre division works from 9 p.m to 6 a.m

That means the 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 businesses don’t want to start the SLA from the assignment creation time. This will be mainly handy when you want to process cases within some business days, in those situations you need to strictly consider the business hours!

Hope you get it 🙂

Now, let’s get to the options available:

1. Immediately – As soon as the assignment is created.

2. Dynamically defined on a property – We can refer a property and set the time prior. The SLA time calculation can begin only after this date property value.

3. 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:

1. Goal
2. Deadline
3. Passed deadline

Goal time – Say, I have an Electricity connection and need to pay the bill by 25th of every month. The service providers have some business policies, on the 25th they will send me a reminder e-mail along with payment details. This can be considered as Goal time.

Deadline time – If I still haven’t paid the bill bythe 30th, then they send another reminder email about the deadline.

Passed deadline – Let’s say even after the 30th if the payment is not completed, then for every 3 days ( for a cycle of 3 times) they will send a reminder email by adding Rs.100 each day as a fine amount.

This can be their business policy.

Let’s configure the Service level definitions based on our above requirements!

Calculate Service levels –

We know Assignment ready field (which we saw before) is the starting point for SLA calculation.

a) Interval from when assignment is ready

For the Electricity bill scenario, let’s say if we create the assignment always on the 24th of the month, then we can configure it as Interval from when assignment ready + 1 day

The assignment creation date – 24^th,so goal date will be 25^th.

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 properties like BillGoalDate with values as 25^th of that month.

(For our scenario, this option can be much better to dynamically set the value to a property and use it in the SLA rule). When you use this option, then the Days, Hrs, Mins, Secs block will be read-only.

Escalation activity

In the right block, you can do two actions

1. Increasing Urgency

2. Executing escalation actions.

As per our requirement, on the 25th the company needs to send a reminder mail to the user (me).

So on the goal date (25th), we can configure the SLA as a Notify Party (Considering I am already a work party to the case with my contact details added). You can also use custom Run activity to solve your business requirement.

You also see there are different activities like Resume/advance which can also come in very handy and are often used with wait shapes.

You also have the option to increase the urgency of the case on the goal date.

Now we have configured GOAL.

Deadline – 30^th

Note: The deadline date time interval is calculated from the assignment ready date. Not from the goal date.

So if the assignment creation date is the 24th and the deadline(second reminder) on the 30th, then you can configure the deadline as 6 days.

 Increase urgency value and execute notify party escalation activity.

Passed Deadline – 30^th – It means 3 days after our deadline30^th.

Note: Passed deadline date time interval is calculated from deadline date. So it’s 3 days.

We also saw from the introduction picture, we have an option to repeat the same escalation process n number of times.

Here, in our requirement, it is for 3 times. So by 3^rd , 6^th and 9th  of next month the same passed deadline escalation events  occur.

That is it. The configuration in the SLA rule form. The important thing is rightly map your service level definitions.

Also note it is mandatory to map all Goal, deadline and passed deadline!

Let’s say we have our SLA ready 😊 but where can we refer this SLA rule?

This opens up to the question of different types of SLA that can answer where the SLA can be referred.

What are the types of SLA?

SLA in Pega can be classified based on the location where it gets used.

1. Case level
2. Stage level
3. Process level
4. Step level / Assignment level

Purposefully let’s start first with the assignment level SLA.

What is an Assignment level SLA?

We can specify time time-bound process for particular assignments.

Let’s consider a simple business requirement. For the mortgage application, in the second stage Validation, there is an assignment shape where the Mortgage handler should generate the Valuation report within 5 business days.

Here you have a time-bound requirement on an assignment shape so you need to configure the SLA only on the assignment shape directly!

Now we need to create a specific SLA for the Valuation report assignment.

We already saw how to create an SLA rule manually from Records -> Process -> Service level agreement.

You can also create the SLA in a low-code way from Case designer. Let’s do that.

Step 1: Configure the SLA in the assignment shape.

Open the Mortgage request case designer.

Navigate to the assignment shape and start configuring the SLA.

Here you can say – Never as No SLA, that is the default configuration.

Then you can either use Custom SLA to create your own SLA from here or you can also use an already created SLA using the Existing SLA option.

I will use the Custom SLA option.

Here you have limited configuration. Just save the case type now, that will automatically create the SLA rule. We can update from there, a typical developer place 😉

Step 2: Configure the SLA for testing purposes.

Open the newly created SLA rule and update the time as seconds so that testing can be done quicker.

I set the Goal as 30 seconds and the deadline as 60 seconds.

We will test the SLA only with the Urgency and not with the Escalation activities.

The Urgency configurations are

Initial Urgency – 10;

Goal Urgency – 20;

Deadline urgency 30;

It means by the end of 60 seconds the Urgency should reach around 60. Let’s verify that!

We already configured the SLA in the assignment shape in low-code way.

Let’s also verify the flow rule assignment shape to confirm the SLA presence.

Whenever you see a timer/clock sign in the assignment shape, then it is sure an SLA is configured in the assignment shape.

Step 3: Start your tracer and create a new Mortgage request.

Create a new case M-6003

Step 4: Test the Urgencies

Close the case, Wait for 60 seconds and reopen the case. Just to avoid any lock issues with SLA processing.

From the App Explorer, you can already see the case is updated by the Service Level Agent (SLA Agent)

Click and open the case.

Go to Actions and check the case history. You will find the SLA executed the Goal and the deadline.

Final check on assignment Urgency value. You see the value is 70.

How is the assignment urgency calculated?

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 already anticipated the Assignment urgency to reach 60 as per SLA configuration.

Now we know that Assignment urgency also includes the case urgency of +10 so is equal to 70.

Step 5: Check the tracer

We know that SLA processing happens at the backend via an agent. It means definitely there should be some queueing happening from the front end.

You can see ‘DefineSLATimes’ activity which sets the SLA value to Assign-Worklist class.

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.

You can clearly see it from the steppage -queuePage details

Okay now we know how things work in the front-end for Assignment level SLA.

Let’s also look at different other SLA before looking at how the SLA processing happens at the backend.

There are other types of SLAs like

• Case level SLA
• Stage level SLA
• Process level SLA

What is a Case level SLA?

We can configure an SLA to run on the complete Case 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 continue using the Mortgage request. Let’s say we need time bound reminder on all mortgage requests so that they can completed quickly

Step 1: Configure the Case level SLA from the Case designer.

In the case designer, Settings tab, we can configure SLA for the whole case.

The low-code configuration remains the same as of assignment SLA.

For now, we will just accept everything and save the SLA with the Case type.

This should automatically create an SLA at the back-end.

The most interesting part is to see how Pega handles the queueing part?!! Because here we don’t have any dedicated SLA right!

Step 2: Create a new case and test the invoking part.

Make sure to trace the creation part. Also, enable the flow settings in the tracer.

One interesting thing to note is Pega spins up an internal flow rule

In the clipboard, you should see the new flow spin-up.

You see there are two flows – OverallSLA and pzInternalCaseFlow.

Pega still uses the OverallSLA flow.

These flows are nothing but another parallel flow with an assignment shape and parameterised SLA configuration

You can see it creates another internal assignment and then dynamically uses the SLA rule.

Good to know that Case Urgency is calculated a bit differently than Assignment Urgency using a different declare expression.

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

You may get a question, “So what happens to this Internal assignment? Who will process it or how will it be resolved?”

The OverallSLA flow will end when the main process flow ends. It uses Resolved-Complete ticket at the end shape and can be completed as soon as the main case is completed.

The queuing activity remains the same as assignment AddAssign activity, because of course OverallSLA flow involves an assignment shape

What is Stage and Process level SLA?

From the case design basics, we know that Cases can contain multiple stages and each stage can contain one or more processes.

For the Stage, you can configure the SLA as shown below

For the particular process, you can also configure in a similar way.

So when you configure Stage SLA or process SLA, then Pega uses the OOTB internal flows – pzInternalStageFlow and pzInternalProcess flow

These flows of course involve an internal assignment shape with SLA configured.

So in the end all the queueing mechanism for SLA background processing works the same as an assignment SLA as we uncovered that all other SLA are a disguise of assignment level SLAs.

Before ending this lecture, let’s also quickly check how Pega OOTB agent handles the SLA processing

How is SLA processing handled by Pega background processing?

In the Introduction, we saw that Pega now supports the SLA background processing via queue processors as well.

The Pega customers can decide whether to use queue processing based on DSS settings. – UseSLAQueueuProcessor dynamic setting value. You can set the value to true to enable Queue processing. But just don’t blindly enable it, you may need a process to switch over 😊

Okay, now let’s just analyze only the Agent processing.

In OOTB agent Pega-ProCom, we have the SLA agent

It is a standard agent with AQM enabled.

Agent activity – ProcessEvent

You see 2 Java steps, which help with preparing the SLA processing and also help with queuing. For example, let’s say a goal event is queued from the front end and the SLA agent processes the goal event, then it should queue an event for Deadline event right.. that also happens with the Java steps.

You see an activity ExecteSLA that helps with executing the SLA escalation activities.

Service level class – System-Queue-ServiceLevel. This class is mapped to the database table pr_sys_queue_sla table with some key columns.

I explained it in detail about this SLA agent in another blog article on Standard agent processing. Definitely have a look at the block when I talked in detail about SLA agent processing.

Finally, we are at the end of the SLA post 🙂

What do we need to remember while configuring SLA rule?

– SLA processing depends on Standard Pega-ProCom agent – ProcessSLAEvents or the Corresponding queue processor. The choice can be controlled by a DSS settings.

– Remember SLA agent needs a lock to update the workitem. If the 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.