If you have started using the new SIR workspace, and are in the journey of creating new processes for each of your playbooks built using Flow Designer, then this article is for you.
We understand how difficult a journey it must be for you to start all over gain building all the playbooks using Process Automation Designer while you have already invested all your efforts building seamless playbooks using Flow Designer. This could slow down your overall adoption. That is why we have come up with an innovative solution to make your adoption journey seamless.
The latest version of SIR Workspace application (v1.2.2) has the tool to render your existing playbooks built using flow designer directly in the workspace by generating wrapper processes. To get this functional and running below are the pre-requisites:
- Security Incident Workspace Application (v1.2.2)
- Platform version of Tokyo Patch 7 and upwards
- Basic understanding of Process Automation Designer: Process, Trigger Conditions, Lanes, Activities, etc.
When the pre-requisites are met, install the update sets available in the KB1500714
The documentation attached to this article explains the detailed steps that are needed to be performed to generate the wrapper processes with ease. Once the wrapper processes are generated and activated, the playbooks get rendered in the Playbook tab of the security incident automatically based on the triggered condition. In addition, these newly generated playbooks can be added manually within a security incident as needed.
While the tool helps you jump start your journey for the existing playbooks, please see the below comparison to have a better understanding of using this approach vs building the processes from scratch for future requirements:
|
Playbooks built using flow and wrapper processes
|
Playbooks built using processes
|
|
Takes less time as flows are already existing. All existing flows can be easily converted into a wrapper process to take advantage of the playbook experience in the workspace.
|
Takes a lot of time to as process has to be built from scratch along with activities and their definitions.
|
|
As flow designer is known area for all customers, no new learning curve is required.
|
Quite a learning curve as Process Automation Designer is new concept relatively.
|
|
It can help achieve automation orchestration.
|
It can help automation and orchestration if proper activities are defined. In addition, inline orchestration can also be enabled from manual intervention.
|
|
In the workspace only response tasks-based experience can be rendered.
|
In the workspace, rich user experienced enabled actions can be rendered.
Example - Email can be directly drafted and sent from the playbook experience of workspace.
|
|
Multiple playbooks can be added and rendered in the workspace.
|
Multiple playbooks can be added and rendered in the workspace.
|
|
Playbooks can be cancelled if not required.
|
Playbooks can be cancelled if not required.
|
|
Steps within playbook cannot be cancelled directly in the workspace.
|
Steps within playbook can be cancelled if cancel action is configured for the activity.
|
|
In the backend flow, branching can be implemented easily using if and else ifs.
|
Implementing branching logic is difficult, multiple lanes cannot be directly skipped. It requires updating the run condition of all subsequent activities and lanes.
|
|
In workspace all response tasks of a specific state are rendered in a single activity called “Steps”. As a result, progress information that is shown on left panel does not reflect the actual progress of each response task.
|
In workspace, each activity has its own card experience. Progress is clearly reflected on the left panel. User experience is better.
|
A quick demo of this for your easy reference:
Credits: @Yashodhar , @Prudhvi T , @Anil Kumar Thal, @Harish80
Demo Credits: @Prudhvi T
