
- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
on 08-12-2024 10:31 AM
Continuing with our series of options to consider before customizing , In this article we will talk about the modification of Out of the box Business Rules
Please refer to the previous article here Options to consider before customizing - Script Includes
Assumption : Adding a new Business Rule to compliment the baseline is not possible e.g. a baseline rule on a CMDB table is validating the record on update for certain field and hence adding a new Business rule is not going to cancel the action performed by the baseline business rule
Identify the Business Rule that needs to be changed
Identify the Out of the Box Business rule that needs to be changed
Check if the Business Rule is protected or not
Usually if there is an Out of the box Business Rule that needs a change due to any reason, we need to check if it's protected or not?
In case if it's editable given the assumption above we can simply go ahead and modify (Reason being while upgrading this Business Rule would be highlighted and once can check if the modification is required anymore or not). It helps with easy reconciliation.
If it's protected then we need to check the 'type of operation' we need to perform via this business rule. Let's say if you want to abort an action via the business rule . In this scenario create a business rule that executes before the existing Out of the box Business Rule to abort the action being performed.
In case if the action required needs logic to be indirectly modified such as via a script include, another Business Rule, events etc. then we can modify the underlying logic. E.g. by writing a new Business Rule that triggers after the baseline one and make the changes.
Else we can simply copy the Business Rule, put our custom logic there and deactivate the original one.
Here is the pictorial representation of the text above
- 566 Views