Retroactive SLA doesn't run unless using "Repair SLA"

[Bastian_E]

Hi,

I have defined an SLA that's not starting as expected. Is this possibly because I'm using dot-walked fields? Or because it has retroactive start?

If I use the "Repair SLAs" functionality by Related Links, the SLA starts as expected.

And, if this is the issue, what would be the best solution of fixing it? Adding an SLA workflow that repairs the SLA at regular intervals?

Customer wants to keep things as much OOB as possible, without fixes or workaround solutions.

[Tony Chatfield1 · Accepted solution]

Hi, unfortunately a partial screenshot does not provide any useful information for diagnostics, but I would not normally expect retroactive start or dot.walking to impact the triggering of an SLA.

What diagnostics have you undertaken?
It should be simple to prove any start condition flag or dot.walking condition issue simply by testing identical tasks in dev without these values.
Also if you are running OOB SLA engine and the stop or cancel conditions are met when the start conditions are met, then an SLA will not trigger; and this may be an issue that is not encountered when repair sla is later used.

I would recommend that you start by validating that start\stop\cancel conditions, then work through the SLA definition lifecycle step by step.

If you require additional support from the community, then please attach an xml text file of your SLA definition and clear details of any configuration\process\function that is unusual during the SLA's intended lifecycle, so that we are in a position to review\better understand the issue.

[Bastian_E]

It seems the dot-walked fields which weren't populated right away were the issue. I re-made the logic and it seems to work as expected now.