What is FEEL?

FEEL (Friendly Enough Expression Language) is a powerful and flexible standard expression language developed by the OMG® (Object Management Group) as part of the Decision Model and Notation (DMN™) international standard.

Request a demo


It is a valuable tool for modeling and managing decision logic in many domains, including healthcare, finance, insurance, and supply chain management. FEEL is designed specifically for decision modeling and execution and to be human-readable to business users, while still maintaining the expressive power needed for complex decision-making. Its simplicity, expressiveness, domain-agnostic functionality, strong typing, extensibility, and standardization make FEEL a valuable tool for representing and executing complex decision logic in a clear and efficient manner. Organizations using FEEL enjoy better collaboration, increased productivity, and more accurate decision-making.

What Are Expression Languages?

FEEL is a low-code expression language, but what is the difference between Expression Languages, Scripting Languages, and Programming Languages. They are all different types of languages used to write code, but they have distinct characteristics and uses.

Expression Languages

Expression languages are primarily designed for data manipulation and configuration purposes. They are focused on evaluating expressions rather than providing full-fledged programming capabilities. Expression languages are normally functional in nature, meaning that at execution the expression will be replaced by the resulting value. What makes them attractive to both citizen developers and professional developers is that they are usually simpler and have a more limited syntax compared to general-purpose programming languages and/or scripting languages. Due to their simplicity, expression languages are often more readable and easier to use for non-programmers or users who don’t have an extensive coding background. FEEL is a standard expression language.

Scripting Languages

Scripting languages provide abstractions and higher-level constructs that make programming using them easier and more concise than programming languages. They are usually interpreted rather than compiled, meaning that the code is executed line-by-line by an interpreter rather than being transformed into machine code before execution. Popular examples of scripting languages are Python, JavaScript, and Ruby.

Programming Languages

Programming languages are general-purpose computer languages designed to express algorithms and instructions to perform a wide range of tasks and create applications. They offer extensive features and capabilities for developing complex algorithms, data structures, and user interfaces. They offer better performance compared to scripting languages due to the possibility of compiling code directly into machine code. Examples of programming languages include C++, Java, and C#.

Is FEEL Like Microsoft Power FX (Excel Formula Language)?

FEEL and Power FX are both expression languages used for data, business rules, and expressions, but in different contexts. Power FX is a low-code programming language based on Excel Formula Language, tailored for Microsoft Power Platform, with some limitations in handling complex decision logic. As soon as the business logic gets a bit tricky, Power FX expressions tend to become highly complex to read and maintain. On the other hand, FEEL is a human-readable decision modeling language, designed for business analysts and domain experts, offering a rich set of features for defining decision logic, including support for data transformations, nested decision structures, and iteration. FEEL provides clear logic and data separation, making it easier to understand and maintain complex decision models.

While Power FX has a visual development environment in the Microsoft Power Platform, FEEL is primarily used within business rules and decision management systems supporting DMN and process orchestration platforms. FEEL is a language standard across multiple BPM and decision management platforms, providing interoperability, while Power FX is tightly integrated with Microsoft Power Platform services. For further comparison, Bruce Silver’s articles FEEL versus Excel Formulas and Translating Excel Examples into DMN Logic.

FEEL Benefits for Technical people and for Business people.

Technical Benefits of FEEL

Decision focus language

FEEL is designed specifically for decision modeling and business rules. It provides a rich set of built-in functions and operators that are tailored for common decision-making tasks. This decision focus nature makes FEEL highly expressive and efficient for modeling complex business logic.


FEEL supports common mathematical operations, string manipulation, date and time functions, temporal logic and more. This expressiveness enables the representation of complex decision rules in a concise and intuitive manner.

Decision Table Support

FEEL has native support for decision tables, which are a popular technique for representing decision logic. Decision tables provide a tabular representation of rules and outcomes, making it easy to understand and maintain complex decision logic.

Strong typing and type inference

FEEL is a strongly typed language, which means it enforces strict type checking. This feature helps prevent common programming errors by ensuring that values and operations are compatible.

Boxed Expression Support for FEEL

Boxed expressions allow FEEL expressions and statements to be structured visually including:

  • If, then, else statements
  • For, in, return statements
  • List membership statements
  • … and more.

These visual constructs, along with autocomplete make creating, reading, and understanding complex expressions easy to model and debug.

Flexibility and modularity

FEEL supports modular rule definitions and reusable expressions, promoting code reuse and maintainability. It allows the creation of decision models and rule sets that can be easily extended, modified, and updated as business requirements change. This flexibility ensures agility in decision-making processes.

Testing and Debugging

FEEL expressions can be tested and debugged independently of the larger application or system. This enables users to validate and verify decision logic before deployment, ensuring accuracy and reliability. FEEL also provides error handling and exception mechanisms that help identify and resolve issues in decision models.

Execution efficiency

FEEL expressions are designed to be executed efficiently, providing fast and scalable performance. FEEL engines often use optimized evaluation algorithms and data structures to ensure high-speed execution of decision logic, even for complex rule sets.

Integration FEEL

can be easily integrated with other programming languages and platforms. Many decision management systems and business rules engines provide support for executing FEEL expressions alongside other code or as part of a larger application. This enables seamless integration of decision logic via services into existing IT architectures and workflows.


FEEL can be extended with domain-specific functions and operators to cater to specific industries or business domains. These extensions can be defined to encapsulate common calculations, business rules, or industry-specific logic, enabling greater reusability and modularity.


FEEL also enables the sharing and reuse of decision models across different organizations and applications.

Business Benefits of FEEL

Standardization and Vendor-neutrality

FEEL is a standardized language within the OMG DMN standard, which means it has a well-defined specification and is supported by various software tools and platforms. Standardization ensures interoperability, as FEEL expressions can be used across different DMN-compliant systems without compatibility issues. FEEL is designed to be portable across different platforms and implementations.


FEEL focuses on capturing business rules and decision logic in a way that is intuitive and natural for business users. This allows subject matter experts and domain specialists to directly participate in the decision modeling process, reducing the dependency on IT teams and accelerating the development cycle.

Simplicity and Readability

FEEL has a syntax that is easy to read and understand – even for non-technical users like subject matter experts and citizen developers. It uses natural language constructs including spaces in names and common mathematical notation. This simplicity enhances collaboration between technical and non-technical stakeholders, facilitating the development of effective decision models.

Ease of Use

FEEL is supported by various decision management tools and platforms. These tools provide visual modeling capabilities, debugging, testing, and other features that enhance productivity and ease of use. The availability of modeling and automation tooling support simplifies the adoption and usage of FEEL.

Decision Traceability

FEEL expressions support the capture of decision traceability, allowing users to track and document the underlying logic behind decision-making processes. This traceability enhances transparency and auditability, making it easier to understand and justify the decisions made within an organization.

Decision Automation

FEEL has well-defined semantics that support the execution of decision models. It allows the evaluation of expressions and decision tables, enabling the automated execution of decision logic. This executable semantics ensures that the decision models defined in FEEL can be deployed and executed in a runtime environment with other programs and systems.

Compliance and Governance

FEEL supports the definition of decision logic in a structured and auditable manner. This helps businesses ensure compliance with regulatory requirements and internal policies. FEEL’s ability to express decision rules transparently allows organizations to track and document decision-making processes, facilitating regulatory audits and internal governance practices. FEEL includes several features specifically tailored for decision modeling and rule evaluation. It supports concepts like ranges, intervals, and temporal reasoning, allowing for precise specification of conditions and constraints. These domain-specific features make FEEL particularly suitable for industries where decision-making based on rules and constraints is critical, such as healthcare, finance, insurance, and compliance.

Decision Analytics

FEEL provides the foundation for decision analytics and reporting. By expressing decision logic in FEEL, organizations can capture data and insights related to decision-making processes. This data can be leveraged for analysis, optimization, and continuous improvement of decision models. FEEL’s expressive capabilities allow for the integration of decision analytics tools and techniques, enabling businesses to gain deeper insights into their decision-making processes.

Trisotech FEEL Support

Most comprehensive FEEL implementation

Trisotech provides the industry’s most comprehensive modeling and automation tools for DMN including support for the full syntax, grammar, and functions of the FEEL expression language. To learn more about basic types, logical operators, arithmetic operators, intervals, statements, extraction and filters supported by Trisotech see the FEEL Poster.

FEEL Boxed Expressions

Boxed Expressions are visual depictions of the decisions’ logic. Trisotech’s visual editor makes the creation of Boxed Expressions and FEEL expressions easy and accessible to non-programmers and professional programmers alike.

FEEL Functions

FEEL’s entire set of built-in functions are documented and menu selectable in the editor. The visual editor also offers supports for the Trisotech-provided custom FEEL functions including functions for Automation, Finance, Healthcare, and other categories.


The Trisotech FEEL autocompletion feature proposes variable and function names including qualified names as you type when editing expressions thus saving time and improving accuracy.

FEEL as a Universal Expression Language

Trisotech has also expanded the availability of the international standard FEEL expression language to its Workflow (BPMN) and Case Management (CMMN) visual modelers. For example, FEEL expressions can be used for providing Gateway logic in BPMN and If Part Condition expressions on sentries in CMMN.

FEEL Validation and Debugging

Trisotech provides validation for FEEL and real-time full-featured debugging capabilities. To learn more about testing and debugging read the blog Trisotech Debuggers.

Additional Presentations and Blogs

You can also watch a presentation by Denis Gagne on using FEEL as a standards-based low-code development tool and read a blog by Bruce Silver about how using FEEL in DMN along with BPMN™ is the key to standards-based Low-Code Business Automation.

OMG®, BPMN™ (Business Process Model and Notation™), DMN™ (Decision Model and Notation™), CMMN™, (Case Management Model and Notation™), FIBO®, and BPM+ Health™ are either registered trademarks or trademarks of Object Management Group, Inc. in the United States and/or other countries.



View all

BPM+ Virtual Coffee
5 min Intro to CMMN

A short introduction to the Case Management Model and Notation (CMMN)

Presented by

Denis Gagne, CEO & CTO at Trisotech

Good day and welcome to our BPM+ virtual coffee. I am Denis Gagne CEO and CTO of Trisotech, and this is a five-minute introduction to CMMN.

Some of the motivations or characteristics behind Case Management, as opposed to process management, was that we wanted to deal with business processes where the sequence of activities is not well defined. Contexts in which activities may happen in all kinds of different orders and we must deal with these evolving circumstances. We also wanted to make sure that the evolution of the Case depended on decisions made by the Knowledge Worker. The Knowledge Worker is front and center to the notion of Case Management. It is all about managing a particular context, which is the Case. To support the performance of the Knowledge Worker required that we had a great deal of flexibility due to the dynamic nature of the work. You can think of it as your input box being your Case File, a manifold where different data comes into it, and you must react to this new information and progress with the work needed by the Case. This requires a lot of adaptability to the information context where this context of information is really the Case File. We also wanted to leave to the Knowledge Worker complete control over what to do next, for him to figure out what’s the next best action. But we also wanted to provide some scaffolding to the Knowledge Worker by also providing ideas of what could be done next. These ideas of what co be done next is where the Case Plan Model comes into play.

CMMN stands for the Case Management Model of Notation, and it is an open standard produced by OMG. The spec is available at the URL here. I invite you to go and consult this specification document.

Fundamentally CMMN is about managing a context to achieve a desired outcome where the context is a Case File. A Case in CMMN consists of a Case File and a Case Plan Model. The Case Plan Model is there to help the Knowledge Worker to figure out what possible next action would be ideal in the current context, but the activities to be carried out are really decided by the Knowledge Worker. This provides a lot of flexibility where everything is decided at runtime rather than pre-defined at design time as in the case of BPMN.

CMMN is as easy as one-two-three because CMMN uses an Event-Condition-Action (ECA) semantic. This means basically that when a particular Event happens, if a condition is met, then a possible an action is available. CMMN offers all the variations of ECA. We can have Event-Condition-action or just Condition-Action or just Action. You therefore have the full flexibility of defining the needed activities.

Now looking at the CMMN notation, the folder shape depicts your context. This gives you the information context of the Case File in which you are working. We then have different symbols to capture the notions of Event, Condition and Actions. Events can be actual Event Listeners, like for example Timer Events or User Events but it can also be Case File Events. For example, a new Case File Item being provided into the Case File, or a particular information item is updated, or a document is done or updated. We use these events as triggers, and we verify whether a particular condition is met. An Entry Criterion will be a condition for entering into this element and an Exit Criterion will be the Criterion for terminating the work. We then have our actions. In this ECA depicted here we have a Timer Event trigger, so when this Event happens, if the Condition is met then I can do this Task. We also have the notion of Discretionary Tasks. The Planning Table is a way to turn on and off, and controlling, which Discretionary Tasks are available. A Planning Table at the top of the folder is managing basically the floating Discretionary Tasks within the Case context and a Planning Table on a Task is managing the Discretionary Tasks that are attached to this particular Task. We then have that when the Event happens, if the Condition is met, while I am in this Task, there are other Discretionary Tasks that I can take on. Then we have the notion of Stages, where you can structure your Plan Items and mostly helping you to create some kind of the life cycle for accomplishing the desired outcome of the Case. We also have the notion of Milestones and different triggers.

So, this is a very quick and broad review of CMMN. There is book on CMMN that I highly recommend you read. It is the CMMN Method and Style from Bruce Silver. You can go and read that book. It will give you an intro to CMMN and provide you with some Style and Method on how to do a good CMMN models.

That was our five-minute introduction to CMMN.

View the slides


Recorded webinars

View all videos
Attend a live webinar

Sandy Kemsley's Vlog - Design tips for combining BPMN, CMMN and DMN models
Sandy Kemsley

Design tips for combining BPMN, CMMN and DMN models

By Sandy Kemsley

Video Time: 5 Minutes

Hi, I’m Sandy Kemsley of column2.com. I’m here today for the Trisotech blog with some practical design tips for when you’re combining process and decision models.

let’s start with the big three modeling standards for processes and decisions. There’s BPMN for structured processes, CMMN for case management and DMN for decisions. The standards tell you how to combine the models and you can look at graphical versions like Trisotech Triple Crown infographic to see how this works. Basically, process models and case models can call each other, and then either of them can call a decision model. Now what the standards don’t show is why you would use a particular model type to model different parts of your operations? Now, this might seem like a really silly question. If you have a process, you model it using BPMN, if you have a case structure, you use CMMN and if you have a decision you use DMN. But the real world is not that simple. In any sort of business, operation, any sort of complex business operation, you’re going to have a combination of process, case, and decision logic. And you need to be able to use more than one model type together. Now when you start doing modeling, you’ll find that process people and rules people come at these business models from different directions: if you’re a process person, like me, then you’ll tend to start with a BPMN or a CMMN model and that’s going to show the overall flow, and then you’re going to add in decision tasks where you need to call out to more complex decision models and then build the DMN models that are called from there. Now, on the other hand, a rule specialist will start by modeling the key decisions in the business operation and then they’re going to add processes to tie those decisions together.

Watch this short video for more…

Follow Sandy on her personal blog Column 2.

Blog Articles

Sandy Kemsley

View all