- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
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?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
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:
- Clone each required OOTB notification (e.g., Incident assigned to me, Incident resolved, etc.).
- Apply your required changes in the cloned version.
- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
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:
- Clone each required OOTB notification (e.g., Incident assigned to me, Incident resolved, etc.).
- Apply your required changes in the cloned version.
- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
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
