Skip to main content

Use bidirectional comments in incident workflows

Bidirectional communication between Moogsoft Cloud and a supported external system (such as ServiceNow) makes it possible to keep incident information in sync between the two systems. When a change occurs on the external system, it is propagated to Moogsoft. And when a change in incident information occurs in Moogsoft, the change is propagated to the external system.

Set up bidirectional comments

To sync incidents between an external system and Moogsoft, you will need to configure both systems to communicate with each other. The exact settings vary, depending on the type of external system and other use case requirements, but the specific Moogsoft components to sync comments include:

  • An incident webhook configured to:

    • Trigger when comments are updated

    • Communicate with the intended external system endpoint

    • Send a payload body including the incident comments to sync with the external system

  • An incident workflow configured to:

    • Send updates using the incident webhook

    • Filter messages based on comments changes

The incident properties you can use with bidirectional comments include:

  • changes

    A property that holds the name of the last change to the incident.

  • comments

    An array of comments, each listed by a unique ID. You can retrieve a comment from a specific position in the array using comment[x] where x is the position of the comment.

  • last_comment

    A property which retrieves the most recently added comment in the array, including these details:

    • id - the internal ID of the comment

    • comment - the comment text

    • type - the type of comment (such as STANDARD, RESOLVING, ANNOUNCEMENT)

    • created_by - the email address of the user that added the comment

    • created_at - the millisecond timestamp of when the comment was added

    • is_edited - a Boolean flag that indicates id the comment has been modified

Prevent update loops

One potential drawback with syncing between any systems is the potential for looping. An incident change occurs on System A, which is sent to System B, which then detects a change and sends it back to the System A. The solution is to use the originator property in a workflow trigger filter. The filter checks that any change initiated by the external system does not trigger an update back to the same system. This prevents any incident change from making a round trip back to the originating system and creating a problematic loop.

In some situations, it is also possible to use the source property. You can configure the workflow which sends updates to the external system to not trigger when the value for source is the same as the external system.

Note

In Moogsoft this is primarily an issue with incident comments, although it may be possible to encounter the looping issue with other fields, depending on individual configurations.

In this section: