Preventing Endless Loop Communication

General Add comments

endless likeOnce I was working for an IT Service Integrator who uses Incident management in a Multivendor environment. In this environment there was made an explicit distinction between Customers, Internal IT staff and IT suppliers.

In ServiceNow terms they use Incident and task tickets where incident tickets fulfill the communication between customers and internal IT staff. Incident task tickets are used to allow communication between Internal IT staff and IT suppliers. IT suppliers are not allowed to look into the Incident tickets.

My job was to arrange the communication between IT staff and IT supplies so that update made on the Incident ticket should be forwarded from incident to incident task and vice versa without lacking information to inappropriate parties. I encounter problems with the updates when pushing information between the two ticket types.
The system got stuck in an endless loop.

To solve this, I have to determine from which direction the update is made.
When it is done from the incident task to the incident ticket then the update from the incident to the incident task is blocked. When it’s done the other way around the update from incident task to the incident is blocked

To configure this I have added a piece of code in the business rule which figures out from which direction the update is done. The following code is used to determine this:


Next I’ve created a before business rule on Incident that is triggered when an update is done. In my example the Work Notes on Incident is updated.
Using the determination code describe above. The destination of the update is checked whether the update is done from the incident. The update is discarded when it is done by the incident itself which causes the endless loop.

On the same way you have to create a before business rules on incident task which is triggered when an update is done on the Incident task.
Now bidirectional communication between incident and incident tasks tickets has been set up without getting into an endless loop.

I hope this was helpful! Please let me know if you have any questions. Comment below or send me an email: .img[at].img

5 Responses to “Preventing Endless Loop Communication”

  1. Saranesh Says:

    Hi Mike,

    I could see another option, suppose if we use Incident.work_notes field on both forms i.e., incident and incident task and i have notification on change of work_notes, that would suffice your requirement. Let me know your thoughts.


  2. Mike Says:

    Hi Saranesh,

    When you use Incident.work_notes on both forms than this issue does not occur. Because updates are done directly on the Incident table without the use of business rules.

    This issue only occurs when business rules are used for doing this copy.

    Hopefully this answers your question.


  3. Saranesh Says:

    Yup. Thanks Mike.

  4. Oliver Says:

    Hi Mike,

    Instead of checking the URL, you could naturally also just check the table class. So current.sys_class_name == “incident” or current.sys_class_name == “u_incident_task”.

    Also, what is behind the updateIncident/updateIncidentTask functions? If you are updating the other record, might as well make the Business Rule run on After instead of on Before to ensure no blockage for the user, maybe even Async depending on the speed requirement.


  5. Mike Says:

    Hi Oliver,

    Your conclusion is partly correct. The challenge is to determine from which direction the update is done. Checking the current.sys_class_name is not enough because you still do not know from which direction the update is done.

    The updateIncident/updateIncidentTask functions can contain anything.
    For instance setting the incident state to “Updated” when the update on de field comments is done from incident task. When the update is done from the incident an email to the caller is sent.

    Hopefully this answers the question.


Leave a Reply