Skip to main content


We sometimes face the challenge that the output of an action is intended to be displayed to the analyst (such as a Splunk search result in the form of a table), but doing that via an insight is limited by the rather small height of insights.


Is there a way to provide a downloadable file (preferably csv or json) to the analyst which we e.g. create via TemplateEngine and store either in the case or in the filesystem?


To my understanding, communication outside of Siemplify would need 2 components:


2a. either another action to fetch replies (if via email) or query the opened ticket for immediate updates, in a very short (<10min) time span


2b. or a job to periodically check for news (email replies meeting a certain criteria, ticket updates) and write them to the case wall, as long as the case is open





What I do not get is how Siemplify intended to point out to an analyst that an update has occured.


How can we point out to our analysts if a ticket received an update (by a syncing job) after
e.g. a
day? Would our analysts have to go through the open cases manually, or is there any other mechanism that I currently do not see?



Hi
@Marek Kreul
! In general, when the action finished running, you get a push notification. Can you clarify the specific use case?



Hi
@Yuli Dubrovski
who's "you" ? The analyst previously assigned to the case?


In my scenario, an email is sent out (or a ticket is created), and the reply email (or an update to the ticket) takes a day or two to come in.


How can we point out to the analysts that the current case
currently
has no active todo (while waiting for the reply/update), and as soon as the update was received, point out that now the analysis / playbook / case work needs to be resumed?


Our analysts work in shifts, thus pushing a message to the analyst who was last assigned is not a good option.


Also, we wanted to assign the cases to a "virtual" role ("@customer"), in order to tell the analysts that the case is currently not in their responsibility, which obviously makes the above not work in the first place.


Ideally, when an update is received we'd like to e.g. add or remove a tag to the case or change the assignment, which in turn should trigger a playbook or building block to be executed.



Hi
@Marek Kreul
, It's Tom from the product team here.

I think that there are multiple potential options to handle your use case..

I would recommend to use case stage or case tag to mark pending cases.

For example -


Send email <>


Change case stage -> Pending for user <>


Wait for reply <>


Change case stage -> Tier 1<>
In this case you can exclude this case stage / tag from the case queue and make sure you see only relevant cases which pending for your analysts.


You can also order your case queue by case modification time to make sure you notice any change in the case.





If you have any alternative idea - I would like to hear about it



Hi
@Tom Shilansky
we came up with a similar process yesterday in a call with Idan, who wanted to check if he can find other good approaches to this challenge.


From your reply, the "exclude this case stage / tag from the case queue" would mean all of our analysts would need to manually configure a filter on the case queue? How can we achieve "excluding" certain tags?



@Marek Kreul
Starting from 6.0 analysts working with cases will be able to use a sophisticated filtering system including And/Or, and Is/Is Not Operators to display Cases that they want to work on.


So you will be able to exclude specific tags when filtering.



@Yuli Dubrovski
That's great news! However, is my assumption correct that this would be the individual analysts task to create the relevant filters, and there's no way of pre-defining some useful filters in the form of generic system settings?


I envision a number of buttons to have "quick-filters" for the case queue, such as "only show cases without a 'pending' tag, "only show cases currently assigned to roles" (not to individuals), ...



So actually we added a “saved filters” feature as well. At first phase each user will be able save filters for a future occasion. In one of 6.0 minors we are planning on adding a more generic option, do define saved filters for each SOC role. So each analyst will be able to use the predefined instead of creating custom saved filters for himself.
@Marek Kreul



YEAH! Sounds very promising, can't wait to get my fingers on v6 again


Reply