5 Replies Latest reply on Jun 15, 2016 7:42 AM by rs090

    Breach time on closed incidents


      Hello, I'm looking for the table in which the breach time is stored even after an incident is resolved or closed.   Once the incident gets resolved or closed the breach time field contains a null value.   I need to be able to report on the last breach time value prior to the ticket closure but can't find any table in SLQ that would store this info.   Anyone know which table that info may be stored in?   Thanks in advance.


      Edit forgot to mention: I do see a possible solution in joining the lc_response_level table and the related incident guid; In turn using the lc_turnaround_time + im_create_date to calculate the breach time.  Just thinking there has to better solution than this.

        • 1. Re: Breach time on closed incidents

          I think the breach time attribute is calculated for you as a system variable so so you might need to stash the current value away as part of the process.

          • 2. Re: Breach time on closed incidents

            Good suggestion and easily implemented, thank you!

            • 3. Re: Breach time on closed incidents

              OK maybe not so easy .    I thought all this would take was to create a new datetime field on the incident form, then write a formula to copy the value of the breach time field in to the placeholder field. 


              *EDIT*  It works if I use the following calc: except that on close it sets still sets the placeholder value to null also, which I don't think it should based on the if statement.  Any ideas how prevent it from setting the placeholder to null on ticket closure?   


              import System

              static def GetAttributeValue(Incident):

              if Incident.BreachTime != null and Incident._BreachTimePlaceholder != Incident.BreachTime:

                 return Incident.BreachTime

              • 4. Re: Breach time on closed incidents
                Adam Wilden Expert

                Yeah - we've had trouble with attributes that seem to be calculated on the fly.


                The simplest solution we found was to change the dependency - e.g. in this case perhaps change it from "Breach Time" to "Response Level".

                That way it will update when the RL changes, but not when the breach time clears itself.

                Untitled 8.jpg


                This might not suit all your requirements, so other workarounds include:


                Setting the value via process (e.g. automated action just before resolution - can be a pain if you have more than one).

                Recreating the calculation on Resolution object with resolution creation date as dependency



                • 5. Re: Breach time on closed incidents

                  Adam that was very helpful and based on the testing from this morning it looks like your first suggestion will satisfy this requirement.

                  It does appear trying to use values that change on the fly have some sporadic behavior , I'd guess something to do with the commit order to the database and it not seeing the correct values at the time the event is fired.


                  Your reply is much appreciated.   We are still implementing the product so I'm sure before we go live we will run in to a case where we have to use your second example of setting a value through a process.   Thanks again.