Skip to Content
Author's profile photo Colleen Hebbert

Determining the Logic behind Decision Tables

3/Nov/2016 Blog updated for re-tagging due to SCN migration

Predicate and Propositional logic was the only subject in university that I failed (if only partial points were awarded for partial proofs!). Yet, I find myself applying this form of mathematics all the time in work as part of troubleshooting and problem solving. I must admit also, I can barely do the proofs anymore (goes to show what happens when you stop practising). However, the parts of this maths discipline is around reasoning and logical deductions – the type of mathematics we all use daily without realising. Yep – problem solving! By understanding logic and the concepts, it has helped me to troubleshoot and simply requirements. And in some cases, it has help me provide solutions to questions asked in this space.


So what has this really go to do with GRC? A tad random for me to be writing about something with no direct connection to GRC. Then again, the thought for this blog came to me after assisting a few recent questions relating to MSMP and BRF+ Decision tables. Members of this community were not asking how to resolve an error (that is, they knew how to configure workflow) but more around their design of their workflow and decision table entries (they didn’t know what values to specify for the steps). Logically, it became evident that logic was missing.


I won’t attempt to provide a lesson in this mathematics (I couldn’t imagine anyone willing to learn from a self-proclaimed failure). However, I thought I might share a slither of my thought process and approach to designing the decision table rules in hope it can help you to determine yours.


I have used this recent question from GRC space as an example of breaking it down – GRC 10.0 BRM : Issue with Decision Table. My workings this blog are not 100% the same as to the answer I gave as I have separated the steps out. However, the answer I provided would also have covered the requirement.



Step 1 – Gather and Record your Requirements


This step does not require changes to your system. Hold back on configuring your system until your think your requirements through. Therefore, you’re working with pen and paper and figuring out your design.


Requirements gathering in its simplest form involves obtaining business statements of what is needed. In this step, avoid the use of technical jargon and write your requirements out in simple English (or whatever your native language is).


You can ask yourself questions such as:

  • Do I have different workflow scenarios depending on the request?
  • What sort of scenarios are they?
  • Will these scenarios require different approval steps?
  • Who are my different approvers (agents)?


In this example, the requirements were already provided (off to a good start to designing the table)



If I select Composite Role it has to go Approver 1 irrespective of any criticality of the role whereas for Single Role if the role criticality is HIGH it has to go to Approver 2 and If the role criticality is MEDIUM and LOW it has to go Approver 3.



Step 2 – Identity your Inputs attributes


By the time you get to step 2 you should have written down all of the scenarios that you can think off for your requirements. The next stage is to go through and find the condition values (attributes) that you can use to configure your rules.


My approach on this one is to go through your statements with a highlighter and colour the attributes that you can see exist for the request type. Depending on how visual you and are how complex your requirement, you might want to use different colours to group the attributes.


For later use (in step 3) you can also highlight the output paths. In this case, these output paths are the identified Approver groups (return results).


1 bus req highlight.png


Once you have gone through and found your condition values, you can then group them together as to identify the attributes:

  • Role Type (e.g. Composite Role, Single Role)
  • Criticality Level (e.g. High, Medium, Low, Any) – in BRF+ it will display as “Crit. Lvl”


At the end of this analysis, you now know that you have two input attributes to use. You can now build the structure of your decision table (you know the inputs from this analysis and you have the outputs due to the rule type – initiator).


2 decision table structure.png


Step 3 – Sequence and Simplify your conditions


As entry to this step, you know you the attributes to enter as the column headings. In this stage, you need to return the original business requirements and rewrite them as a pseudo-logic format based on your inputs and outputs.


3 rule break down.png

Now an example of where Logic comes in (allows you to build a logically equivalent rule) and shows an example between how I wrote suggested the solution versus how it was built is Rule 1.


4 rule example for logic.png

A Logical equivalent of this rule would be replacing the criticality is asterisk with the use of an OR operator and listing out ALL POSSIBLE VALUES for Criticality level


5 rule example for logic equiv.png

The risk of switching to the OR operator is if new Criticality Levels are built, then you have not factored them into this scenario. You then have to update the decision table. For this reason, when you requirement does not require the use of the attribute, I would specify the asterisks. However, the two rules above will return the same result (so long as there are only those 3 criticality levels).


You could approach this sequencing and simplification by drawing a decision tree. If you have completed business process flows, you may not even need to go through this process as the steps are already defined for you. Example of the decision tree, provides a visual flow of your rules which may help you validate them later when you test the rules. It is also a useful approach to use when you are analysing gaps in your requirements.


6 decision tree.png


When breaking this one down, as it was a simply scenario, I realised immediately that 3 lines were needed for the different scenarios. However, where it becomes more complex, you might need to work through a decision flow and refine it until you can see all of the scenarios.


Step 4 – Add your catch-all


Depending on how thorough your rules are, you may have no rules left to capture. This step is important to analyse the business rules that you have devised to make sure you did not miss any possible combinations. If you miss a scenario then your end user will receive an “on submission” of the workflow error.


In this step, you need to look at your business rules and compare to your IMG configuration to determine if there are any possible inputs not yet catered for. In some cases you may be able to simplify your rules by changing the OPERATOR. In other scenarios, you may need to add additional rules (another line item).


As an example, ROLE TYPE is a potential gap. The original requirements only considered two roles types – Single and Composite. However, there are other roles types to choose from (profile, derived, composite, etc). It is hard to know if this is an oversight as part of it comes back to IMG configuration for choosing which role types are in scope. For the purposes of this blog, let’s assume that all role types are required.

The second potential is PRIORITY. If you only list the explicit values – LOW, MEDIUM and HIGH – you risk missing any other configured values. You also risk future IMG configuration requiring creation of a new criticality but the BRF+ decision table is forgotten. For example, there might be a value call CRITICAL.


There are a few ways to add the catch-all



Option 1 Rewrite your rules to cater for them

In the case of the first attempt – you can go through your rules and incorporate it. The risk of this path is that you implicitly include it in an Approver Path instead of going back to your business requirements and confirming them. This option really depends on how well you captures you business requirements in the first place.


For example, in rule 2 and 3 change it to Role Type <> Composite instead of Role Type = Single. For rule 3, change the criticality to not equal high. You have now removed the gap for Role Type and Criticality.


7 catch all rewrite.png


Your risk is whether you have interpreted the requirement correctly in simplifying. For example, what if Non-Composite Roles that have Criticality level of Critical need to go to a different approver (approver4)? This rule will not provide that option. Therefore, your simplification becomes invalid.



Option 2 Add entries to the bottom for each scenario

For each gap, you need to define the requirement and capture it. For example, you have determined that there are only two role types (Single and Composite) but there is another Criticality level – Critical – and you want to route to Approver2.


8 catch all add entries.png


If you have a decision flow diagram, then you would need to update it to reflect the new rule. For each scenario, you would add a new rule to your table.



Option 3 Edit your Existing Rules to Expand

An alternative to Option 2 could involve editing the existing rules to include the missed scenarios. This would depend on the missing gap. Using the same requirement Options 2 (criticality of critical for single roles should go to Approver2) would result in editing rule 2.


9 catch all edit entry.png


Option 4 Wildcard catch all at the very end

If your decision table properties has been configured to only return a single result (which is the first rule evaluated) then you can add a wildcard catch all to the very end. This rule will only be evaluated if all other rules have failed. In this case, would configure an Approver_X (unknown) and consider routing it in MSMP to an Administrator to investigate.


10 catch up wildcard.png


Step 5 – Build and Test your decision table


Finally, you’re at the stage where you have translated your business requirements into business rules. Time to hope into BRF+ and create the decision table. Once you have completed, activate the decision table, functional and application. Finally, you can simulate your rules to verify that you receive the expected result based on your inputs (your decision tree might even help you with your test scenarios).


11 decision table complete.png

Note: configuration screen shot taken from the original thread referenced at the top




Hope this helps you think through your rules and apply a little logic. If you happen to be interested in logic as a topic (and succeed where I failed), this site is useful and includes a Teach Yourself Logic Guide.


What is your approach to breaking down BRF+ rules? Do you take a similar approach or do something different altogether? I would love to hear your thoughts in the comments below.




Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Rakesh Ram
      Rakesh Ram

      Hello Colleen,

      Thanks all lot for taking tons of TIME to drive in the logic to be used while building a decision table.

      While I was building the above mentioned decision table, I couldn't find * for the composite role. That's the reason why I used each criticality level individually.

      I went into SPRO and also checked there for * and i couldn't find it there either in criticality level.

      Is it something I need to add manually?

      The article deserve 6 stars on a scale of 5.....Thanks a lot once again


      Deepak M

      Author's profile photo Tom Cenens
      Tom Cenens

      Hi Deepak M

      Did you try using "matches pattern" and then direct input value * ?

      Best regards


      Author's profile photo S A
      S A

      Hiya Colleen,

      'Predicate and Propositional logic', I wasn't even aware such a subject even exits. If it is as complicated as its name, I am sure I wouldn't have faired that well either. Your topic on the other hand is quite the opposite. It makes so much sense that if we know the logic behind something (problem/task etc), it is a lot easier to figure out the solution and your document drives home this message rather well so I would like to thank you for that!

      I've got a query though. My understanding of a catch all is:

      If the following three conditions are not met, then it should have a condition defined to cater to the rest of potential scenarios, so we don't get that 'on submission' error message.


      Please correct me if I am wrong, shouldn't the catch all condition be something along the following lines:

      If Role type <> Single OR Composite AND Criticality <> Low OR Medium OR High Then approver is approver 3

      As opposed to your catch all:


      Wouldn't this condition conflict with the other three conditions or am I missing the plot here??



      Author's profile photo Colleen Hebbert
      Colleen Hebbert
      Blog Post Author

      Hey Leo

      You are correct from a point of view of avoiding conflict. If all rules were evaluated in the one I wrote it then you would get two outcomes

      However, in the decision table in BRF+ you can define whether to check all rules or return the first hit. Therefore, the rules would be evaluated in the order you add the so you would only get to my 4th one if you didn't meet any of the others.



      Author's profile photo S A
      S A

      Thanks Colleen.

      We are currently using BRF+ only for multiple role owners (Region specific - same role but different country), which is determined by the Role Sensitivity in the Initiator rule!!