Last activity: 17 Jul 2017 15:54 EDT
SLA and Decision Table
Is it possible to drive an SLA time length (how many days, etc.) based on a Decision Table? In all of the Service Level definintion screens I have seen, and in all of the online help, the SLA time is strictly something entered at the case/flow/section / whatever level, but is not derivable from case data (for customer of type "x", sla is 10 days, for customer of type "y" it is 15 - that kind of thing).
***Updated by moderator: Marissa to close post***
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Did you consider circumstanced rules? This is one of the textbook examples of such.
You can define the SLA times based on a property, so if you wanted to set that value from a decision table in a utility shape on your flow before hitting the assignment, you can definitely do that. If you want something more dynamic, so the SLAs change if the customer upgrades from gold to platinum status for example, things get a bit more complicated. You would need to dequeue the existing queue item and make a new one based on your new property values.
Thanks much - I initially tried something like that, but since the work object or whatever is null, the entire thing blows up when I try to use a decision table to set up the SLA based on a property. If I hit Create Case, i get this nice big jumble o' java error - not even a screen to enter data. Not sure what I did wrong, but it seems to be something about my case being null, so the property that the sla is being based on is null.
Here is the error I get on Create-Case/Run
PegaRULES Request Status fail cannot be null/empty. page: pyWorkPage. Details: Invalid value for aReference passed to com.pega.pegarules.data.internal.clipboard.ClipboardPageImpl.getString(String) jgilbert H7A627D7363E3BB839AC8CC3DF9EED4D1 PegaRULES 7.10 ML7 (coreAssemblyCached_717_644)
- I have a property called "WorkbasketVar" that is built based on a Decision table, which examines a couple of case properties
- I have the SLA defined in pyCaseTypeDefault as "Set to the value of a property" , referencing the .WorkbasketVar property.
I tried setting it to a basic property, that is not driven by a decision table. Same error. So I am not sure how to get around the "Set-to-a-Property" but "On initial creation, all properties are null" loop.
Updated: 26 Mar 2015 12:09 EDT
What if you try updating the pyDefault data transform rule (which should have been generated when you created your app) to set the value of the property you are having trouble with on case instantiation?
Thanks for the suggestion, Brendan. I've never done a data transform before so I'll have to check in to that.
Yeah, this won't work before the item is created. Of course you can't have an SLA on an object that doesn't exist, so generally that's OK. Looking at pyDefault is a good place to start. Also, I assume you have flows somewhere under the covers. You may want to open them up and begin to customize them with your business requirements (i.e. use a data transform, activity, etc. to set the value) some time after the item is created but before it lands on the assignment shape.
Mike is correct that there are no SLA's on an object that doesn't exist. There are also two types of SLA's that need to be considered in the design of your application. This is where it can get confusing because there are two types. The first SLA (Service Level Agreement) that exists is on the Work item. That is, the instance created which lives in or inherits from the Work- class. It is referred to as the Overall SLA and helps drive a request to conclusion. The second SLA is on the Assignment that a user/process is created and works from. This object inherits from the Assign- class and can have a different value than the Work item since it is only one part of the solution to resolving the Work item. The PRPC and Pega7 Online Help files contain a lot of detail on the use of both. Search for SLA and choose the OverallSLA flow and SLA topics to start with. Understanding how each work and interact with one another will help you get to where you can change the rules to do what you want.