SLM bug We have a SLM created for Critical and High priority tickets and it works just fine, the bug is when tickets are Normal or Low priority. When we create a ticket and it doesn’t’ meet the criteria of the SLA we designed, VSM is entering into the CL_Call_Logging.SLA_SART the date and time the ticket was created. Later on in time when our customers call back and change the criteria of their ticket and it meets the SLA settings that we created, VMS reads the values that it recorded when the ticket was created. The reason that this is a bug: You don’t need a database field to store the SLA_START if you automatically force the CL_CALL_LOGGING.ACTUAL_LOG_DATE into the SLA_START field, you could use the created date time instead. This field should be left blank until the ticket is matched up to an SLA that meets the criteria. I am sure this holds true for OLA’s and any other type of agreements. What should happen is the following: 1. Ticket created, no SLA data is stored into the database unless the ticket meets the SLA criteria. 2. When ticket values are updated the SLA is reevaluated and if the criteria is met, then SLA is then applied with the current date and time of the event recorded into the CL_CALL_LOGGIN.SLA_START. We need some options too so the SLA FCB doesn’t start until the ticket is forwarded from our Service Center to another team. Think of it like a Domino pizza 30 minute delivery, the timer doesn’t start until they hang up the phone. Currently our timer stars as soon as the ticket number is applied. You don’t need a database field to store the SLA_START if you automatically force the CL_CALL_LOGGING.ACTUAL_LOG_DATE into the SLA_START field, you could use the created date time instead. This field should be left blank until the ticket is matched up to an SLA that meets the criteria.