You have gotten all the necessary approvals, the contract is signed, the instance is live, and you are staring at the Visual Playbook Editor wondering where to begin.  This is where we were a couple of months ago, allow me to guide you through what worked for us, some roadblocks and how we came through. Our first step was to gather a list of the playbooks we wanted and to sort them by priority.  Once this list was validated by the stakeholders, we found common actions that needed to be repeated by multiple playbooks.  Tasks like artifact enrichment, ticket creation, update, closing, interaction with SIEM and notables immediately surfaced, and our first actions were to implement these as input playbook that we could use repeatedly.  While developing these may set you back from pushing your first playbook to prod, you will save a lot in the long run by reusing these. A couple of things we found out along the way: The Format action block is your friend!   Properly format SPL queries;  If you have a list of hosts and need to search each host in a tokenized splunk search, if you pass the list as is, Splunk will search for the list.  In order to search for each host in a list, you need to format the query like below.  In the block, define your parameter.  The presence of the %% will tell SOAR to start a search for each artefact present in the parameter. %% index="myIndex" sourcetype="mySourcetype" host="*{0}*" earliest=-4d@d | table field1, field2, field3 %% Sending an HTML email; Again, the format block is useful to write the HTML code for an HTML email you want to send and add the artifacts from previous block.  We use this when an account is compromised and need to change the password.  An email is sent to the user’s manager after a password reset. Can’t find the field from a previous block in the data picker? If the field is not a known default field, you might need to manually add it using the little + sign present in the data picker.  Here is a video from Kelby Shelton demonstrating this: Why choose Filter vs Decision block? The decision block will route the flow to one output depending on the logic, while the filter block will route the flow to all the outputs matching the logic.  For example, let’s say you want to create a playbook that will enrich artifacts, but you only want to have one playbook for all types of artifacts.  If your input accepts IPv4, IPv6, hashes and URL, if you split your flow using a decision block and your first logic checks for IP address first, the flow will always be directly there when an IP address is sent, even if there are other artifacts in the input.  On the contrary, a filter block will route all the artifacts to their proper lane, making sure to check all artifacts in the list input. Hope these few points can be as useful to you as they were to us.  For us, the Splunk community Slack was a huge part of our success! Thanks for reading! ... View more