SLAs behind the scenes

To understand how SLAs work, its good to follow along how things get setup on a new entity that is enabled for tracking SLAs.

1. First lets go over the 3 entities that define the SLA:
1. SLA: This is the main SLA record. This entity records whether its the default SLA, to which entity it applies, etc. In addition it has a collection of 1 or more SLA Items:
2. SLA Item: The SLA item contain information as to what criteria should be used to apply the SLA Item (each of which can define a different criteria under which they apply (Applicable When) and each of which may have a different set of time limits and actions. The SLA item also tracks which field on the entity it is supposed to update (this is used by the SLA KPI instance). In the above case, the SLA Item would be pointed the new_resolvebykpi. One could add more than one SLA KPI field.
3. SLA KPI Instance: When the entity gets created, a SLA KPI instance is created to track the SLA. This SLA gets the details based on the SLA and SLA-Item records at the time of the entity creation (an important thing to remember, as changes dont get applied retro-actively to existing SLA KPI instances). A separate KPI instance will be created for each KPI being tracked on the entity.
2. When you enable an entity for SLA: (Red boxes)
1. The entity gets a lookup field created called SLAID, that points to the SLA
2. In addition, on the SLA KPI Instance entity, a new N:1 field is setup that allows the SLA KPI Instance to point at the entity on which the SLA is being tracked.
3. When you add a KPI field (you do this by setting it up as a lookup to SLA KPI Instance) (green box)
1. The new field allows CRM to track each KPI separately.
4. Workflows that manage the SLAs:
1. Once the SLAs have been created and a new entity is created on which an SLA is being tracked, the work-flows fire and setup the fields on the SLA KPI Instance records based on the SLA details.
2. These workflows can be found by performing the following advanced find:
   
3. Something to note: You will find multiple work flows when you run your search. If you sort it by status, lets first go over the workflows that are in activated status:
1. There is one workflow that will have the name of your SLA. This is the main workflow and is invoked by the system and creates the SLA KPI Instance records. It also updates the SLA KPI Instances based on pause statuses, etc.
2. There is a workflow for each of the SLA items you created. These workflows have wait steps that allow the workflow to track the Warning timeout and failure timeout values. These workflows look basically like this:
   
   These workflows run in the background and hence there can be timing issues and the UI doesnt always update when the timers run out. This is the same reason that when you perform a resolution action (Such as setting a boolean field like First Response Sent), it doesnt update the UI immediately and you sometimes have to refresh the UI to see the updated status.
3. Finally, you will find that there are some workflows that are in a draft status. Everytime, the SLA is deactivated and reactivated, it creates a new copy of the Workflows and deactivates the old ones. This does clutter the system and I have not found a way to clean up these old workflows. My best guess is that these workflows are kept around for historical purposes. I am not sure if a background process comes along and deletes these workflows later.