Syncing Cases Across Greymatter, Servicenow, and Secops

Hello everyone,

Has anyone implemented a reliable way to synchronize incidents and cases across ReliaQuest GreyMatter, ServiceNow, and Google SecOps SOAR?

We want to maintain linked records across all three platforms and synchronize relevant information, including state/status changes, analyst comments, work notes, and resolution details. Ideally, analysts could work from their respective platforms while keeping the other systems updated.

Our current setup

• We already have bidirectional synchronization between GreyMatter and ServiceNow.

• We use Google SecOps SOAR playbooks that create ServiceNow incidents through the ServiceNow integration actions.

• We are evaluating the ServiceNow connector and available synchronization jobs to bring SecOps SOAR into this workflow.

Proposed approach

I am considering using ServiceNow as the central source of truth for shared incident information, with GreyMatter and SecOps SOAR synchronizing against the corresponding ServiceNow record. We would also define which platform controls specific fields and how conflicting updates should be handled.

The intended behavior would be:

• When a SOAR playbook creates a ServiceNow incident, subsequent updates synchronize with the original SOAR case.

• When an incident originates in ServiceNow or GreyMatter, a SOAR case is created if a corresponding case does not already exist.

• Once linked, the records remain synchronized without duplicate tickets, repeated comments, or updates continuously cycling between platforms.

Main concern: duplicate ingestion

My concern is that a ServiceNow incident created by a SOAR playbook could subsequently be picked up by the ServiceNow connector and ingested as a second SOAR case.

From the ServiceNow integration documentation, I see that the ServiceNow – Sync Incidents job uses the ServiceNow Incident Sync tag and a TICKET_ID context value containing the ServiceNow incident number.

Could we have the originating playbook set those values immediately after creating the ServiceNow incident to establish the relationship with the existing SOAR case? Would we also need connector filtering or additional correlation logic to prevent that incident from being ingested again?

I would appreciate insight into the following:

1. Architecture: Has anyone successfully used ServiceNow as the central coordination point for these three platforms, or found another approach that works better?

2. Linking and deduplication: How are you distinguishing ServiceNow incidents created by SOAR from incidents that should create a new SOAR case? Are you using correlation fields, custom fields, connector filters, or another supported mechanism?

3. Synchronization jobs: Which jobs and configurations are you using to synchronize comments/work notes, status changes, closure, and reopening on existing linked records? Are you maintaining the relationship at the case or alert level?

4. Update loops and conflicts: How are you preventing copied comments and automated state changes from being treated as new updates and sent back through the integrations?

If anyone has implemented a similar setup, I would appreciate any lessons learned, configuration examples, or limitations to account for before we build this out.

Thank you,
Blake