- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-10-2023 02:46 PM
Hi,
I'd like to create a custom notification (message, logo etc) for when SLA has reached 75%. I know that the OOTB notification triggers for both 50% and 75%, but I want mine to only trigger at 75%.
How do I go about working on this? Do I modify the OOTB notification or make an entirely new one and deactivate the OOTB? What are the specific steps?
Thanks in advance.
Edit: I'd also like to create a custom notification for when the SLA breaches. Can someone point me in the right direction?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-10-2023 02:58 PM
Hi @JordyZ ,
There is no point in triggering two notifications which is actually for same purpose. Personally, I would suggest you use the OOTB notification and modify it according to it your need. Having said, I almost get pulled to create a new notification as well. Eventually it's all about sticking to OOTB. So, I would stick to OOTB and modify it.
For the third point, we do have OOTB notification which gets triggered at 100%, which is SLA breach time. You can again use this.
P.S - I was in the similar situation for one of my clients and we decided with OOTB notification.
Please mark helpful/like, if the solution was in line with your expectation.
Regards,
Gagan k
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-10-2023 02:58 PM
Hi, this is driven by the Default SLA flow or workflow of your SLA definitions, which one (flow or workflow) will depend on age of your instance.
You can update the default flow\workflow to remove the 50% trigger,
or possibly update the OOB SLA warning notification to include a condition of sla % is >= 75%.
/nav_to.do?uri=sysevent_email_action.do?sys_id=9660628ed7a2220035ae23c7ce61039e%26sysparm_view=advanced
If updating to flow\workflow you have option to modify OOB record,
or you can copy\create your own and then update your SLA definitions to use your new version.
Updating the trigger conditions of the notification would be the simplest solution and is easily reversable if you decide to revert to OOB.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-10-2023 02:58 PM
Hi @JordyZ ,
There is no point in triggering two notifications which is actually for same purpose. Personally, I would suggest you use the OOTB notification and modify it according to it your need. Having said, I almost get pulled to create a new notification as well. Eventually it's all about sticking to OOTB. So, I would stick to OOTB and modify it.
For the third point, we do have OOTB notification which gets triggered at 100%, which is SLA breach time. You can again use this.
P.S - I was in the similar situation for one of my clients and we decided with OOTB notification.
Please mark helpful/like, if the solution was in line with your expectation.
Regards,
Gagan k
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-10-2023 03:15 PM
Hi @Community Alums
Thanks for your reply. In the "who will receive" section it says Event parm 1 contains recipient, but I'd like the recipient to be the person in "assigned to" field of incident form. But since the table of the notification is task_sla, I cannot put "assigned to" as who will receive.
Who will receive the notification since "event parm 1 contains recipient" is ticked?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-10-2023 03:34 PM
I would expect this value to be the assignee, but you can validate by reviewing the SLA flow\workflow that triggered the sysevent.