Create Tasks Repository in Microsoft Sentinel

One of the most important factors in running your security operations (SecOps) effectively and efficiently is the standardization of processes. SecOps analysts are expected to perform a list of steps, or tasks, in the process of triaging, investigating, or remediating an incident. Standardizing and formalizing the list of tasks can help keep your SOC running smoothly, ensuring the same requirements apply to all analysts. This way, regardless of who is on-shift, an incident will always get the same treatment and SLAs. Analysts don't need to spend time thinking about what to do, or worry about missing a critical step. Those steps are defined by the SOC manager or senior analysts (tier 2/3) based on common security knowledge (such as NIST), their experience with past incidents, or recommendations provided by the security vendor that detected the incident.

In Microsoft Sentinel, you can utilize Tasks functionality for this purpose. Tasks can be added manually to the incident after the creation or using rules and/or playbooks automatically on incident creation.

We're happy to announce that Microsoft Sentinel Tasks feature is now generally available (GA)!

But what if we have tasks for dozen incidents that are not the same? Or even few dozen? Creating and managing many rules for each incident or creating many conditions in playbooks can lead to complications and it would be really hard to manage.

In this blog, we will demonstrate how utilization of watchlists, rules, and playbooks can be used as tasks repository that will assign tasks based on incident title on incident creation. We should deploy Tasks Repository in this order:

  1. Watchlist – Permission needed to deploy: Microsoft Sentinel Contributor
  2. Playbook – Permission needed to deploy: Logic App Contributor; Permission needed to assign RBAC to managed identity: User Access Administrator or Owner on Resource Group where Microsoft Sentinel is
  3. Automation rule – Permission needed to create: Microsoft Sentinel Responder


First step is to deploy the watchlist that will be used to store tasks. We can use sample watchlist and deploy it to our environment by clicking on Deploy to Azure.


Watchlist contains Incident title column that is also mapped to SearchKey, and additional 20 columns for tasks.

If there is a need for more then 20 tasks, please use CSV file to add additional columns, and create watchlist manually. Important note, when creating watchlist manually, use TasksRepository for alias, or this field will need to be updated in the playbook after deploying it. Also, map SearchKey to IncidentTitle column as playbook is using it as well.

IncidentTitle field doesn't need to contain full incident title, as we are using contains to compare IncidentTitle field from watchlist with actual title when the incident is created. This is used so that you can utilize dynamic values feature when creating Analytic rules in Microsoft Sentinel. 

Watchlist contain one row sample data, that can be deleted after adding tasks that will be used in production. Please note that if you delete sample value before adding any other rows in the watchlist, you will need to re-deploy the watchlist. Watchlist cannot be empty.

When adding additional tasks, there is a format that should be used so that playbook can map tasks title and description field. Each tasks filed should look like Tasks title, unique separator |^|, followed by Tasks description. Unique separator |^| is used in playbook to separate title and description of the tasks into its appropriate fields. In watchlist example, in column Task01 we can see example – Task 1|^|Task description.

Some additional recommendations around tasks:

  • Maximum number of tasks per incident is 100.
  • Task title length must not exceed 150 characters.
  • Task description length must not exceed 3000 characters.
  • You can use HTML elements like bold/italic/underlined, headings, hyperlinks, indenting.
  • When using hyperlinks, use target='_blank' to open in new tab as link cannot be opened in task itself – example


Second step in the process is to deploy sample playbook that will extract task title and description based on the incident title and write it into the incident tasks.


After deploying the playbook, we will need to assign these permissions to Logic App managed identity:

  • Microsoft Sentinel Responder
  • Next, open Edit mode of the playbook, and add managed identity to Logs action:

Select Create New to save our API connection, and then Save the playbook.

Also, important step is to make sure that For each loop in playbook has correct settings for parallelism so that tasks are added one by one, in order we define it in the watchlist.

In playbook, access Menu for action For each – task, and make sure that field Degree of Parallelism is set to 1.



Final step is to create an automation rule that will run on incident creation on all incidents, and as an action will run playbook. You can also add it to any existing automation rule you have that is being run on incident creation.

  • Title: Tasks repository
  • Trigger: When incident is created
  • Actions: Run playbook -> TasksRepository

After deploying watchlist, playbook, and automation rule, repository for tasks is ready. Add your tasks per incident to watchlist and make sure to update it regularly to remove any old information in the tasks! More information on manage watchlist can be found on Microsoft Sentinel docs.

Learn more about tasks:

Please share feedback and what else you would like to see in Tasks Repository solution using Watchlists and Automation in Microsoft Sentinel!


This article was originally published by Microsoft's Sentinel Blog. You can find the original article here.