OOTB Notifications Best Practices

abigailtaba
Tera Expert

There are a lot of comments regarding the OOTB notifications.

I need to make major changes to the following notifications:

  • Comment left on Incident
  • Incident assigned to me
  • Incident assigned to my group
  • Incident commented for ITIL
  • Incident resolved
  • Incident opened

Based on your experience, what would you recommend? Is it better to create clones of these notifications and deactivate the OOTB ones, or to modify the existing notifications?

1 ACCEPTED SOLUTION

Tejas Adhalrao
Kilo Sage

@abigailtaba  ,

Hi,

Based on experience, for major changes to OOTB notifications, the recommended approach is to clone the notifications and deactivate the OOTB ones, rather than modifying them directly.

Reasoning:

  • Upgrade safe: OOTB notifications may be updated during upgrades. If modified, you can face conflicts or skipped records.
  • Easy rollback: If something goes wrong, you can simply reactivate the OOTB notification.
  • Clear separation: Keeps standard functionality untouched and makes it easy to identify customizations.

Recommended approach:

  1. Clone each required OOTB notification (e.g., Incident assigned to me, Incident resolved, etc.).
  2. Apply your required changes in the cloned version.
  3. Deactivate the corresponding OOTB notification to avoid duplicate emails.


Only consider modifying OOTB notifications if the change is very minor (like a small subject tweak). For structural or logic changes, cloning is the safer and cleaner approach.

Thanks

 

View solution in original post

2 REPLIES 2

Tejas Adhalrao
Kilo Sage

@abigailtaba  ,

Hi,

Based on experience, for major changes to OOTB notifications, the recommended approach is to clone the notifications and deactivate the OOTB ones, rather than modifying them directly.

Reasoning:

  • Upgrade safe: OOTB notifications may be updated during upgrades. If modified, you can face conflicts or skipped records.
  • Easy rollback: If something goes wrong, you can simply reactivate the OOTB notification.
  • Clear separation: Keeps standard functionality untouched and makes it easy to identify customizations.

Recommended approach:

  1. Clone each required OOTB notification (e.g., Incident assigned to me, Incident resolved, etc.).
  2. Apply your required changes in the cloned version.
  3. Deactivate the corresponding OOTB notification to avoid duplicate emails.


Only consider modifying OOTB notifications if the change is very minor (like a small subject tweak). For structural or logic changes, cloning is the safer and cleaner approach.

Thanks

 

Tanushree Maiti
Kilo Patron

Hi @abigailtaba 

 

Recommended approach is generally to modify the existing Out-of-the-Box (OOTB) notifications in place rather than cloning the OOB notification.

 

Once an OOB component is modified, any upgrades will treat it as a skip-level activity if new OOB features are introduced to that component. To prevent technical debt, it’s important to merge both the newly added features and your customizations.

 

Refer this helpful Article: Modify In Place vs. Clone: FSO Best Practice Guide for Implementation Partners

 

 

Please mark this response as Helpful & Accept it as solution if it assisted you with your question.
Regards
Tanushree Maiti
ServiceNow Technical Architect
Linkedin: