Skip to main content
Question

Can the Salesforce SOAR integration automatically create and synchronize tickets from Google SecOps cases?

iLotuus
Forum|alt.badge.img+1

Hi everyone,

I’m evaluating the Salesforce integration for Google SecOps SOAR and would like to confirm whether it supports this workflow:

  1. A case is created in Google SecOps from any connected alert source.
  2. A corresponding Salesforce Case (ticket) is created automatically.
  3. Relevant changes in SecOps, such as priority updates, are reflected in the Salesforce ticket.
  4. When I close the case in SecOps, the associated Salesforce ticket closes automatically.

I would use Salesforce to escalate cases to customers and communicate through the customer portal instead of email. For now, I don’t need customer replies in Salesforce to synchronize back to SecOps.

I already have Google SecOps SOAR with playbooks enabled.

My questions are:

  • Does this SOAR integration support creating and updating Salesforce tickets from SecOps, or is it intended only for ingesting Salesforce data into SecOps? I want to clarify the difference between this integration and the Salesforce SIEM ingestion feed.
  • Is the recommended approach to use the integration’s Create Case, Update Case, and Close Case actions within playbooks?
  • How can I synchronize subsequent changes, especially case closure after the initial playbook has completed? Should I use case-level triggers, a scheduled job, or a custom integration?
  • How should I maintain a one-to-one relationship between each SecOps case and its Salesforce ticket, prevent duplicates, and associate the ticket with the correct customer account?

Has anyone implemented a similar workflow? I’d appreciate any practical experience, known limitations, or recommendations.

Thanks!

2 replies

MitchellR
Forum|alt.badge.img+3
  • MitchellRBronze 1
  • Bronze 1
  • October 22, 2026

Hey ​@iLotuus, 

While this integration doesn’t come with a job out of the box, a similar workflow could be achieved with some customization. As-written, the actions are really specific to atomic activities carried out as part of a playbook as opposed to being a continual sync job. 

I would recommend adding a custom Job to this integration so you can leverage the existing `SalesforceManager` and then oftentimes for these types of dual-sync Jobs, I’ll run them on a 15-minute cadence where it polls open, applicable cases on the SOAR side and open, applicable tickets in Salesforce, and reconciles changes against one another (updating with applicable details, closing out, moving queues/labels, etc). 

dnehoda
Staff
Forum|alt.badge.img+19
  • dnehoda
  • Staff
  • October 22, 2026

Yes it can create tickets into SalesForce.  It can update and close but the sync is the problem.  If you look at the JIRA integration there is a job scheduler which syncs the tickets every hour I believe.  

We would need to create a custom job or ask for an enhancement.  

 

This would also be a use case for reaction triggers.  

 

Synchronizing Subsequent Changes & Case Closure

Once the initial playbook finishes creating the ticket, standard ingestion triggers will not fire again on that case. How you synchronize subsequent updates depends on the event type:

Lifecycle Event in SecOps Recommended Mechanism How It Works
Priority Updates (or Stage, Assignee, Comment changes) Case-Scope Reaction Triggers (Pre-GA feature) Create a playbook with Scope: Case and select the Reaction tab under Triggers. Use the Case Priority Changed trigger (e.g., from ANY to ANY), retrieve the stored Salesforce case_number from Case Context, and run Salesforce - Update Case using the [trigger.to_state] placeholder.
Manual Case Closure via SecOps UI Custom Scheduled Job in the IDE (Best for standard UI workflow) Case closure is not a valid playbook trigger in Google SecOps SOAR, and unlike the Jira or Cortex XDR integrations, the Salesforce integration does not bundle a pre-built Sync Closure Job. Build a Scheduled Job in Response > IDE and run it every 5 minutes in Response > Jobs Scheduler to query recently closed SecOps cases tagged Salesforce, read their SFDC_CASE_NUMBER context value, and invoke the Salesforce API to close the ticket.
Playbook-Driven Closure Reaction Trigger (Case Tag Added / Case Stage Changed) or Manual Playbook Block (Zero-code alternative) Instead of clicking the top-bar Close Case button, analysts apply a tag (e.g., Close_With_SFDC) or run a manual playbook block. The playbook executes Salesforce - Close Case first and immediately runs Siemplify - Close Case to close the SecOps case in tandem

 

Maintaining a 1:1 Relationship, Preventing Duplicates, and Account Mapping

In Google SecOps, multiple related alerts are automatically grouped into a single Case container. If you attach a ticket-creation playbook at the Alert scope, SecOps will execute the playbook for every grouped alert and create multiple Salesforce tickets for the same case.

Use the following design pattern to enforce a strict 1:1 relationship and associate the customer account:

Requirement Implementation Pattern in Google SecOps SOAR
Run Once Per Case Create your ticket-creation playbook with Scope: Case rather than Alert. Google SecOps limits automatic ingestion attachment to one case playbook per case specifically to support opening a single external tracking ticket per incident.
Store the 1:1 Mapping ID Immediately after Salesforce - Create Case runs, call Siemplify - Set Scope Context Value with Context Scope: Case, Key Name: SFDC_CASE_NUMBER, and Key Value: [Salesforce_Create Case_1.ScriptResult]. Also call Siemplify - Case Tag to add a Salesforce tag to the case for easy filtering.
Prevent Duplicates on Reruns At the very beginning of your creation playbook, add Siemplify - Get Scope Context Value (Context Scope: Case, Key Name: SFDC_CASE_NUMBER) followed by a Condition flow. Only proceed to Salesforce - Create Case if SFDC_CASE_NUMBER is empty/not found.
Retrieve Ticket ID in Update/Close Flows In your Reaction Trigger playbooks (and Scheduled Job), call Siemplify - Get Scope Context Value (Context Scope: Case, Key Name: SFDC_CASE_NUMBER) and pass its output into the Case Number field of Salesforce - Update Case or Salesforce - Close Case.
Associate Customer Account (AccountId) Option 1 (SOAR IDE): Map each customer to a SecOps [Case.Environment] (or use Salesforce - Search Records to look up AccountId from an entity email/domain), and pass AccountId via a customized Create Case IDE action.
Option 2 (Salesforce Flow): Pass [Case.Environment] and [Case.Id] in the Subject or Description of the standard Create Case action, and use a Salesforce Record-Triggered Flow to set the AccountId and a custom SecOps_Case_ID__c field (which can also be marked as an Unique External ID in Salesforce to block duplicates at the database level).
Terms & ConditionsAccessibility statement
Privacy Policy Terms of Service Gen AI Policy Community Guidelines Cookie Settings

© 2025 Google. All rights reserved.