what is assignment type in pega

Service Level Agreement – its Configuration, Usage & Execution

This article discusses about SLA in PEGA, its configuration, Usage and back end 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 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.
• 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 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.

• Urgency gets increased by 30.

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 .

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

• 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

• 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.
• 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

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.

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.

• 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 !!!

OSP Editorial Team

We are a team of 3 CLSA’s who strongly believe in the fact that Learning is nothing without sharing.

OneStopPega is purely out of our love and passion for PEGA.

Recent Jobs from our community

Join the discussion cancel reply.

Feel free to post your questions here about this topic if any. We will definitely get back to you ASAP !!! If you have any off-topic questions, Let's discuss at OSP Forum

Save my name, email, and website in this browser for the next time I comment.

Enable this to get email notification when someone respond back to your comment

Enable this to Subscribe for instant email notification on new article

21 comments

Great Article, thank you. At our implementation we are dealing with a collection of about 25 casetypes having different SLA settings. It would really help if we could have a report showing the evolution of a case SLA and urgency over time, for all the casetypes. Somebody have examples? Maybe also on business configuration choices in a complex environment? What is a good practice in using the 1-100 bandwidth in urgency over time? You do not want to blow all your points to fast… thanks!!

Thanks @Marc Bakermans

We will explore few things and answer your questions shortly. In the mean time we are keeping comment section open for all readers to reply.

Happy Learning from OSP 😊

Thank you very much for such a wonderful article, any layman can understand.

Good to hear that you liked it @Dilip

Happy Learning from OSP😊

Great post 😉 Thank you very much for providing such a good one with example.

we are honored @Lokesh

Today I created an SLA in Dev studio. And I was forced to configure the deadline. My line of business only want to have goal. I am working in Pega 8. Do I have to create a rule to omit the Sla event kick off for the deadline? Is there an alternative approach?

In SLA, you can’t configure a GOAL event without a Deadline event. Only the Passed Deadline is optional. You can possibly try out the below options,

1) Just try having an empty Goal event as (0,0,0,0) and configure your times in the Deadline event instead of Goal. 2) Try if this can be replaced with Wait. Since you have only one event to configure, we feel that the wait shape would suffice. You can refer to our below article on wait shape. https://onestoppega.com/background-processing/wait-shape-its-configuration-usage-execution/

Nice write up. I have a question to ask on how servicelevelevent agent pick the queues which were reached to their goal time and do processeevent take care sending notification to manager here. It will be really helpful if you can throw some light here.

pxMinAgeForProcessing will have the time set accordingly bro just like how agent processes our normal requests.

what is the puropse of creating internal flows when the case has a SLA?

Any way an entry will made into System-Queue-Serveiceevel table and an agent picks it and process the case.

why pega is creating those flows and why they are resloving?

can u explain logic behind that?

Each of the internal flow has its own unique feature. For Eg: OverallSLA is an internal flow created to handle case level SLA. When we resolve the case at any given point, the system handles it using the ticket mapped in this flow. The same applies to Stage Level, Step Level SLAs.

Thanks for such a great post !!. I have a question regarding queuing an event to pr_sys_queue_sla. usually this will be taken care by addassign activity. But, when we configure an SLA with Assignment ready option as “Dynamically defines by a property” or “Time delay”, System will queue an entry to pr_sys_queue_sla table when this time passes. How this will be handle by system? something like system will add this time(timedelay/ dynamically delay) to pyminimumdatetimeforprocessing field?

What ever the option we select from Assignment ready field, Queue item will be persisted to pr_sys_queue_sla table. Where as when we choose Timedelay, this time is getting added to goal time(pyminumumdatetimefor processing). I tried with Option Dynamically set to property, no changes to goal time.

Thank you very much for such a wonderful indetail article.

I have one question. If we use is there any posibilities to use all these SLA type in a case type .

For ex -what will happen we use Case level and Stage and Assignment level SLA’s together

The formula that is used to calculate the urgency will consider Work+ Stage + Step+ Assignment level values.

Nice Article, In which table stage level goal and deadline properties are saved?

I have a question like, is there a way(OOTB activity or function or any other process) we can remove SLA on existing work items. other than deleting SLA entry from pr_sys_queue_sla table.

If there are multiple SLA defined like assignments and flow level which takes the precedence..? while executing

Further reading

Tickets in PEGA – its Configuration, Usage & Execution

Queue Processor – its Configuration, Usage & Execution

Job Scheduler – its Configuration, Usage & Execution