anchor.diff:  }
   ----
   
  -<1> *autoResolve* flag set to *true* indicates trigger will activate *FIRING* and *AUTORESOLVE* modes. Flag set
  +<1> *autoResolve* flag set to *true* indicates that the trigger will activate *FIRING* and *AUTORESOLVE* modes. Flag set
   to *false* will run the trigger only in *FIRING* mode.
   <2> *autoResolveAlerts* flag set to *true* will automatically mark alerts as *resolved* when *AUTORESOLVE* trigger
  -detect problem is gone. Flag set to *false* will not modify alert lifecycle.
  +detect problem is gone. Flag set to *false* will not modify the alert lifecycle.
   
  -And next fragment will show how to declare *FIRING* and *AUTORESOLVE* conditions linked with the trigger:
  +And the next fragment will show how to declare *FIRING* and *AUTORESOLVE* conditions linked with the trigger:
   
   [source,json]
   ----
  
positive.code: }
  ----
  
  <1> This *id* should match with the *dataId* field defined in the conditions.
  
  Examples can be running using link:/blog/2015/08/19/hawkular-alerts-standalone.html[Hawkular Alert in Standalone]
  deployment used in the previous post.
  
  More details about Hawkular Alerts features can be found at
  
negative.code: 
  ----
  
  <1> *triggerMode* indicates in which mode will this condition be executed, *FIRING* mode is used to detect the
  problem we want to alert. In our example, it is an occurence of the Firefox process not being up.
  <2> *AUTORESOLVE* conditions are executed to detect when the probem is not present.
  
  Finally, in link:https://github.com/lucasponce/hawkular-examples/blob/master/extended-tests/process-autoresolve/send-data-check-process.sh[send-data-check-process.sh]
  bash script we show how we can check and send availability data about process we want to monitor.
  
  The format of the payload is shown in the next fragment:
  