Why dot-walked conditions on SLA Definitions should never be used


A very common use case for many users is to have, for example, SLA Definitions on the sc_task table with at least some portion of the Start, Pause, Stop, or Reset conditions based on values from fields/variables in the sc_req_item table.

This is never a good idea and will break core SLA functionality for task SLAs based on those SLA Definitions where dot-walking is used. This theory of never using dot-walked conditions in SLA Definitions is not exclusive to the above example - but covers all dot-walked fields across all tables when building SLA conditions.

The reason this kind of implementation should never be used, at minimum, is that it will break SLA Repair and SLA Timeline functionality for the task_sla records where dot-walked values are used in their related parent SLA Definitions. For example, when utilizing Repair SLAs on the example SLA Definition (based on the sc_task table, but taking values in some of the conditions from sc_req_item fields), is that when SLA Repair is utilized, it will never walk back through the history of dot-walked values. The SLA Engine is only ever going to run against the current record and the audit history on that current record. Because dot-walked fields are never walked through like the audit history of a record is walked through, this will break the SLA Repair and SLA Timeline functionalities by providing inaccurate results.

The correct and recommended method to create SLA Definitions and to build the conditions therein is to only utilize fields from the table specified in the "Table" field of the SLA Definition. In other words, do not dot-walk Start, Pause, Stop, or Reset conditions away to any other table value, ever. When building conditions, use only the fields on the table the SLA Definition is created to run against.