Table of Contents
DCR Portal 7.6 introduces FEEL Context.
When we model processes in DCR, the dynamic, real-world behavior is defined by its core business rules—the conditions that must be met, the include and exclude rules that control which tasks are available, and the response rules that chain logic together. Rules can be controlled by Guards.
A guard is an expression that must evaluate to true for the rule to be applied. This expression is where the logic lives—it's the "if" statement for the rule.
This is precisely where the FEEL Context becomes essential.
The expressions inside these guards are written in FEEL (Friendly Enough Expression Language), and they read their data from the FEEL Context to make a decision. The context is the structured "case data" (like Applicant or Loan Details) that the expression queries.
The power of the FEEL context, therefore, is in making these crucial, guard-level expressions readable, structured, and aligned with the business.
It Models Real-World Business Structures
This is the most important benefit. Business data isn't flat. You don't just have applicant_age, loan_amount, and applicant_city as one long, flat list of variables.
Instead, your business has a concept called a "Loan Application." This application has an "Applicant" and it has "Loan Details." The context lets you model this reality perfectly.
Using our Loan Application example, the context structure (which looks just like JSON) would be:
This structure is a massive improvement over managing 20 separate, flat variables. It encapsulates data, makes it easier to pass around, and intuitively matches how business experts think about their data.
It Speaks the Language of Business
Because your data is now in a logical, business-alike structure (from Point 1), the FEEL expressions you write against it become incredibly clear.
This is the "before and after" that executives and analysts love.
- Before (Flat/Cryptic Data):
if (var_10 < 50000 and var_04 > 18)...or...if (data.get("loan_data").get("amt") < 50000 and data.get("app_data").get("age_yr") > 18) - After (FEEL Context):
"Loan Details".Amount < 50000 and Applicant.Age > 18
This transparency is the goal. Business analysts can read, validate, and even help write the core logic that runs their process.
It Bridges External Data and Business Rules
An Effect (think of it as a "connector") is associated with an activity in the DCR graph, like "Check Credit." When that activity is executed, the Effect is triggered.
The Effect's job is to interact with an external system and then transform the data it gets back into the easy-to-read FEEL context.
For example, an Effect might get a complex JSON payload from an external service. It then translates that payload directly into the simple, business-readable Applicant."Credit Score" data that your rules are built to understand.
This creates a clean separation. Your guards (like Applicant."Credit Score" > 700) are stable and simple. They are completely insulated from the technical, complex data formats that might come from external systems.
An example - WZ.GetEntity
KMD WorkZone supports static as well as dynamic effects. The classical effect, GetValue, could retrieve one specific value from WorkZone. The dynamic effect WZ.GetEntity can retrieve a collection of data attributes from any entity in WorkZone.
The graph below (https://www.dcrgraphs.net/Tool?id=2003595) shows how this works.
We convert the output from the WZ.GetEntity into a FEEL context using the expression: "from json(Data)".
Once we've done that, we can refer to the elements of the FEEL context directly in the value expressions, e.g.:
FEEL_Context.Created
which will return the created date.
An updated version of WZ.GetEntity will return FEEL context directly but as this requires a new updated version of KMD WorkZone we do not change the effect yet.
We hope this will be available in WorkZone 2026.0.