In a couple of previous posts, we discussed why you should not use a Workflow to implement business logic. Business processes (e.g., Workflow, Rule Flow, Data Flow, etc.) are for orchestrating the sequence of tasks to be executed.

In this post, we are going to show you an example on how to apply a decision to model simple workflow rather than chaotic ones, the we are going to discuss other benefits of this approach.

Let's say we have a generic flow that executes tasks based on person's title (i.e., Infant, Kid, Teen, Young, and Adult).

If you are going to model the entire logic as a process, you will end up with something similar to the following flow:

simple workflow


As you can see in this flow, the logic of the business definition for a Person's Title is modeled inside the flow itself. This approach has many issues, including:

  • It makes the process convoluted and less clear. (Hard to understand and Change)
  • This logic implementation does not have anything to do with process goal itself. (Single responsibility violation)
  • Changing the logic (e.g., range of ages for different titles) will require a process change. (Change/Deployment complexity and overhead)
  • The logic is not reusable between different processes and/or applications. (Reusability issue)
  • Logic cannot be tested without running the whole flow. (Testability issue)
  • Testing the logic can be done only by asserting the impact of it on the entire process. (Testability issue)

These will introduce a technical debt, and like any other debt your have to pay it otherwise the consequences of not addressing them a barrier to operating business.


We just need to introduce a decision model to encapsulate the Person's Title decision. This can be simply done by using a Decision Table, as shown below:

simple workflow

Now by modeling this logic separately, we can reference and use it in the process, and the result will look much better:

simple workflow

As you can see now, the flow (i.e., your business process) is much less complex.

Please note this is just a simple workflow and those are also conditions are mutually exclusive (a person cannot be a teen and an infant). In a real business process, the conditions can be satisfied using multiple different routes and the process itself is more complex. Extracting the business logic from the process will significantly reduce the complexity. So you can model a simple workflow (i.e., business process) and manage it more easily.

Also, if the logic is more complex than a single Decision Table, you can always use Decision Requirement Diagram to handle interaction between decisions.


In this example, we replaced 9 different nodes in the original flow with 1 Decision Table! Extracting the business logic and definitions from your process model (e.g., flow) will not only significant reduce the complexity of the process itself, but also have the following positive impacts:

  • Logic can be shared between other processes (flows) and applications
  • Quality of logic can be increased and guaranteed as the intention of the logic can be tested
  • Process (e.g., flow) can focus on its goal rather than trying to implement business logic (Design benefit)
  • Process can take advantage of complex decision-making models (Decision model and Notation)

Learn More

  1. Automated Fraud Detection and Human in the Loop
  2. Successful AI Strategy
  3. Policy Automation
  4. Refactoring Business Decisions
  5. Fundamental of Organizations – Business Decisions + Knowledge
  6. Custom Scorecard for Credit Card Approval Decision
  7. How to start your first Decision Intelligence project?
  8. Data Exploration by Decision-Integrated Monadic Data Query
  9. Standardizing Credit Ratings
  10. Automated Deployment of Business Decisions

Last updated September 22nd, 2020 at 11:31 am, Published September 1st, 2015 at 11:31 am