Ever since we started using the SLA module we configured our SLAs to run in the foreground. We have SLAs on initial Response (assign to an individual), Time to fix, based on priority, etc., so if a ticket is assigned or someone changes the priority it triggers the SLA module/process to add or modify the sla breach or status, etc. in the ticket. The problem is that the SLA process does not respect locked records therefore one of the most common issues when updating tickets is the message "This record has been modified since you loaded it" (or something similar), because the sla process has modified the ticket while we are still working on it.
Although we don't know if there any significant benefits, we are considering changing our SLA configuration so that they run in the background. We are wondering if anyone else out there has done this and would offer an opinion. Does anyone run their SLAs in the background and are there things that need to be considered before switching? Any significant risks? Switching them to run in the background seems to add a schedule record which is processed a couple of minutes or so later, instead of immediately, so this at least gives our users a brief window to finish their update and get out of the ticket without getting this error. Alternatively does anyone know how to get the SLA module to recognize locks, so that our users can finish their work in the ticket before the SLA process comes along and changes it.
Any thoughts, suggestions, or information would be appreciated.