Problems starting an SLA from a business rule

[geek1]

Anyone have experience starting an SLA from a business rule?

What I'm doing is pretty basic:

//p1 = sysid of SLA
var sla = new GlideRecord('task_sla');
sla.sla = p1; // Priority 1 OLA Response
sla.task = getTask.sys_id;
sla.insert();

The above starts the SLA exactly when it's supposed to, there's no problem there. However, when I drill down into the SLA itself (from Task SLAs on the incident form) and click the reference icon for this specific SLA.. I click 'Show Workflow' and it loads an empty workflow. The workflow is named properly on top of the page but it loads empty.

I got worried so I added the Workflow field to the Task SLA form and sure enough, it loads shows the name of my workflow exactly how it is. When I click Show Workflow it loads an empty workflow, too! It's so strange. The SLA itself looks perfect, but the workflow doesn't fully attach to it.

When you manually load an SLA via a business rule do you need to do anything beyond what I did above to get the workflow to attach and run properly?

[Daniel Draes]

Hi,

why would you want to start the SLA fro the business rule directly ? I would rather modify properties of the incident record you work on and have the SLA start based on these changes. Kind of a shadow field if needed.

Fogg

[geek1]

That is an interesting approach to the problem at hand. We are manually running an SLA via a business rule because we can easily track when a field changes (specifically, we are restarting the SLA when the assignment_group changes).

I'm not sure how I'd go about changing something on the incident form to signify when the assignment_group changes. Any thoughts on that?

[Daniel Draes]

Getting a bit closer to the requirement now 🙂

Restarting an SLA when the assignment group changes is probably not best practice. Is this really an SLA that you promise your customers/end users? I sounds more like an OLA where with each change of an assignment group a new OLA should be started. This way you can also report quite easily which assignment groups do a good job and which not.

Sticking to your question, how to identify a change on assignment group to trigger the SLA. It is easy to set a flag for the SLA to react on, it gets more tricky to reset that flag in order to prepare for the next change.
Just dropping some ideas...
- Depending if there is a limit for reassignment in your case you could build up a series of SLA's and react on the reassignment_count field and start based on that - which would work without coding. Just the number of SLA's to build might be tedious.
- If you don't mind the SLA to be restarted at every change you could have the system start the SLA on status (as you most probably do), and instead of firing a new SLA for every changed group you could modify the elapsed time in the SLA on the change event back to 0 and the start time to now. Would probably need some additional checks if other fields need to be reseted as well for proper counting.

[smurphy]

Did you ever get this to work the way you wanted?

We have a similar requirement to trigger an OLA workflow for assignments and I would like to have a stop condition when the assignment group changes. Only problem is that it seems like a Business Rule has the functionality to use .changes() whereas in the SLA definition you can only use canned conditions (and field changes isn't one of them).