You can set the SLA in the SOAR settings and could configure based on case priority, alert, etc. If you're focused on the first alert in the case, case priority may be the best option here. After that, you can choose a priority option and specify the SLA time for the different levels. From there, you can create a SLA playbook block and use the Get Case SLA notification and different notification actions in the event SLA is exceeded.

Can you share me screenshot of you using these SLA in a playbook creation step? which parameter should be pass to access the sla.

Try the Get Case SLA action and then you could use Get Current Time and compare them with a condition.

Something like this as a start:

Get Current Time returning epoch:

Comparison with condition:

Now i get what i was doing wrong. when i ingest alert as testcase the SLA was not showing up as its the testcase and i was not able to retrieve any info from get_ALERT_SLA action. This is what i was struck with

I used the Set Case SLA action just to make sure I had a SLA for my test case.

So as you can see i had injested the #8985 alert as test case but why is it considering #8992? what coud be the issue?

I believe this is working as intended. When you test with the simulator, a simulated case is created. For example, when I tested, I had a different case ID and pulling that case ID up, I can see the label "Simulated Case".

SLA's are not getting applied to Simulated cases in my environment

For testing with simulated cases, can you add the Set Case SLA action prior to the Get Case SLA?