There is a "Google Chronicle Sync Job" that can be configured under Response -> Scheduled Jobs  that will sync the status from SOAR back to the SIEM alerts overview.  

These are environment specific so you'll need to configure 1 per environment.  The value for "User's Service Account" will be the contents of a backstory service account .json file,  you may need to request one of these from your support or your account team if you don't already have it saved.

what does the other one do? "Google Chronicle Alerts Creator Job"

"This job creates all alerts from Google SecOps SOAR to Google SecOps SIEM, including overflow alerts. The Google Chronicle Alerts Creator job doesn't replicate alerts that originate from Google SecOps.

The Google Chronicle Alerts Creator job queries the SOAR platform using the Python SDK for non-synchronized alerts. The job sends non-synchronized alerts to SIEM individually. SIEM updates and returns the identifiers of the corresponding SIEM alerts, and SOAR saves the identifiers using the SOAR platform API through the Python SDK."
https://cloud.google.com/chronicle/docs/soar/marketplace-integrations/google-chronicle#alerts-creator-job

Hey! 
I was wondering can we do the same for crowdstrike? So there were many connector options that are available for crowdstrike. my environment is setup in such a way that Crowdstrike -> siem -> Soar. now which one would be the appropriate connector that needs to be setup to automatically sync the alerts status to crowdstrike if we closed them in soar? Do i get duplicates if i add a connector between SOAR and crowdstrike? 

The Crowdstrike integration doesn't include a sync job for periodically closing alerts on the CS side as it finds the case is closed on the SecOps SOAR side.  Instead it includes actions for updating status on alerts, detections, and incidents (based on what the event initially was) that you can include in your playbooks to set the status as the case is worked.  This is a different work pattern but should get you to the same place. 

The purpose of those connectors is to pull alerts/detections/incidents from CS and to create events in SOAR; the connector won't push the results back to CS.  If you create a new connector to directly ingest data to SOAR that you are already receiving via the SIEM you would receive duplicate events.

Along that line of thought, Crowdstrike does treat Incidents, Alerts, Detections, Identity Protection Detections and Streaming events as distinct data.  Between the variety of data sources available and API changes it would be a good idea to review what Crowdstrike data you are ingesting into the SIEM and make sure you are getting everything you expect.  I know we recently added the capability for querying CS Alerts to the 'CrowdStrike Detection Monitoring' feed but it can only query that data if the API key gets Read:Alerts permissions added on the CS side.

'Instead it includes actions for updating status on alerts, detections, and incidents (based on what the event initially was) that you can include in your playbooks to set the status as the case is worked.  This is a different work pattern but should get you to the same place' 

I don't think this proposal is correct. Yes, the actions can be used in a playbook but the platform does not allow playbooks to run after case closure so you either need to close the source alert/incident on ingest or setup an elaborate flow of sync jobs/actions to get around this omission.