SOAR Case

@Ishans_crest ,

It usually depends on your workflow, but you are correct. In the current implementation of SOAR, there is no ability to update the alerts that have already been created.

So, if you need updated data to work on a playbook and you can't just use an action to get recent data based on some identifier, the only option left is to ingest it as a new alert. However, if it is possible to get the recent data from the source system using some sort of identifier before performing X, you may not need to create a new alert.

Thanks for quick revert.
In that case, ideally we should close the existing alerts while we create another alert?
We would want to dedup the data, what is the best case scenario to ingest data whose sub parameters keeps on updating by third party frequently. 

@Ishans_crest, it depends on the flow you would like to follow or on how you are planning to work with those alerts. You may close those alerts/cases way before the updated alert comes, or you may develop some custom job that, once a new alert is created and an existing one is found, closes the older alert. 

To be honest, I never saw anyone do it with a custom job. Usually, you just re-run the same playbook on the updated alert as well as it was done in the old alert, and the last step will be case/alert closure.

Depending on the logic in the connector, the rerun should not reingest the old/updated alert.  The conector keeps a local table of IDs we ingested, or the creation-timestamp of the latest thing we ingested.

For this you need a "Job" to keep the alert in sync, the availability of Jobs depends on the Integration pack.  I know one exists for Sentinel, but other cases may vary.