Skip to main content


7 Best Practices for Oracle Fusion Business Rules

7 Best Practices for Oracle Business Rules

7 Best Practices for Oracle Fusion Business Rules


7 Best Practices for Oracle Business Rules

Oracle Business Rules are an effective tool for dealing with human nature, order irregularities and help eliminate some of  the chaos related to managing orders and fulfillment.  In order to get the most of them you need to give them attention and care to keep them effective.  Here are 7 Best Practices for Oracle Fusion Rules to design and develop better business rules.

One – Use only one tool for creating business rules

There are two rules engines available for the creation of Oracle Business Rules.  They are the Oracle Business Rules  (OBR) Engine and the Visual Builder. Some rule functions allow you to choose to create rules using either Oracle Business Rules or Visual Builder.  Oracle cautions against mixing the use of both in those cases because there could be unwanted interactions based on the way the two methods work.

Visual Builder creates a duplicate rule automatically in the Oracle Business Rule format in some of the functions. Thus using Visual Builder makes some amount of sense in most situations. Visual Builder is easy to manage and the ability to create rules is within the abilities of most functional types.

Oracle Business Rules are more complex in the way they are created and as such are better created by a technical role.  OBR does provide a more robust dictionary and in some cases allows the definition of attributes you choose.

Two – Use a Design Document

It’s a good idea to create some type of design documentation when creating an Approval Rule.   It helps contend with potential issues that could arise in design and development.  If possible, use a template that outlines conditions to look for. Include items like Where Used lists for attributes and a standard test plan (more on that later).  Methodology is a matter of choice, so go with what you know.

When you are designing a rule, consider what other rules act on the same attributes you considering for your new rule.   The Where Used list mentioned above can be a useful tool in figuring this point out.

Consider consolidating like rules into one rule using Else Clauses.  This helps simplify maintenance of rules and raises awareness of rules or clauses that may conflict with each other.

During development, be vigilant for conflicting statements and consider what actions to take if an attribute in the rule is null.  If you find that an attribute is not working in the way you expected, sometimes there is a similar attribute that will achieve your desired outcome.

Three – Use a dedicated Environment

Oracle - Guide to Oracle Cloud: 5 Steps to Ensure a Successful Move to the Cloud
Guide to Oracle Cloud: 5 Steps to Ensure a Successful Move to the Cloud

Explore key considerations, integrating the cloud with legacy applications and challenges of current cloud implementations.

Get the Guide

It is recommended that you use only one environment to develop Business Rules.  This is because of the way that migration between instances works. More on that later in this blog.

Another good reason for using a dedicated environment is that you have ALL of your rules in place.  For that reason, it’s a good idea to refresh the environment from Production before starting a major rule creation event.  Having all of your rules together minimizes the chance of ending up with conflicting rules after an addition.

Four – Testing, Testing, Testing…

After you have designed and developed your rule, test it, test it,  and test it again.

Be sure to include regression tests in your standard battery of approval testing requirements in addition to the conditions you designed for.

It is imperative to test with as recent a copy of your production pod as possible.  This is for two reasons; First, to ensure your regression tests cover all the rules that exist in your Production Pod.  Secondly, to guard against losing existing rules in Production if you are using the Migrate functionality.

Five – Rule Administration

It is helpful to periodically review your approval rules for relevance.  This is ensure accuracy of the rules in the face of changing product lines and customer flux.  It also helps cull rules that are no longer necessary and clear the landscape to make rule maintenance easier.

As mentioned earlier, if two or more rules are of a similar nature, it might be helpful to combine into one rule using Else statements.  However, there sometimes comes a point with similar rules where there are too many to put in one rule and still be able to find the clause you’re looking for.

Six – Limit access to Development

It is also helpful to limit the number of people with access to the Setup and Maintenance of rules.  It prevents overlap of rules, conflicts and stops the publishing of unwanted rules to Order Management.

If more than one person is involved in rule creation it is important that they talk to each other about their respective rule projects.  They should coordinate on publishing and migrating rules as well.

Seven – Use the Migration Process

Oracle has created a process to migrate rules from one environment to another for many kinds of rules.  This helps to ensure the rules set stays intact.  This process goes hand in hand with best Practice Number Three.  One of the characteristics of the process is that it deletes any rule not in the source environment.  Moving your your rule sets from Production to the Development environment ensures that you don’t accidentally lose a rule after development.


We have looked at 7 Best Practices for Oracle Fusion Business Rules . We identified some critical points to consider when designing and creating rules.  Feel free to reach out to us here at Perficient with your questions and needs.


For more detailed information about Oracle Cloud OM Business Rules, try this link:

For more information about Oracle Fusion Business Rules in Order Management, check out this blog:

Oracle Cloud OM Business Rules – A Primer

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Gene Gysin, Senior Solutions Architect

Gene Gysin is a Senior Solutions Architect with over twenty years of experience with Oracle SCM ERP and Cloud implementations. Before that, he served in the US Navy, retiring as a Chief Petty Officer. He lives in Northern Michigan with his wife where they enjoy hiking, canoeing and touring the vast number of light houses in the area.

More from this Author

Follow Us