Decision table lookup fails with dynamic conditions in approval routing

BPM Creatio
, , , , , , , ,
1

I’m struggling with a decision table lookup in our approval routing process. The table works fine with static values, but throws errors when we try to use dynamic conditions from process parameters.

Our setup: Approval process needs to route based on request amount and department. We’re passing these as process parameters to the decision table lookup. The context mapping seems correct in the designer, but at runtime we get:


Error: Unable to resolve parameter value in decision table
Context: ApprovalAmount = [ProcessParameter.Amount]

The decision table has columns for Amount (range) and Department (exact match). When I hardcode the values directly in the process, it works. But using dynamic parameter resolution fails every time. I’ve verified the parameter names match exactly, and the data types are correct (Decimal for amount, String for department).

Is there a specific way to map process parameters to decision table context in Creatio 7.18? Are dynamic conditions even supported, or do we need static value resolution for this scenario?

2

Check your decision table column configuration carefully. For dynamic conditions, the column binding needs to specify the parameter type explicitly. In the decision table designer, each input column should have its data type set to match your process parameter type exactly - not just “auto-detect”. I’ve seen mismatches between Decimal vs Integer cause silent resolution failures that surface as parameter errors.

3

I’ve seen this exact issue before. The problem is usually in how you’re referencing the process parameters in the decision table context. In Creatio 7.18, you need to use the full parameter path notation, not just the parameter name.

Instead of just Amount, try using the complete path like #ProcessSchemaParameter1# where ProcessSchemaParameter1 is the actual system name of your parameter. The decision table context mapping requires these hash-wrapped references for dynamic resolution.

4

Another thing to check - are you using the decision table in a subprocess? I ran into a scenario where parameter context wasn’t being passed correctly across subprocess boundaries. The parent process had the values, but the subprocess decision table couldn’t access them. Had to explicitly map the parameters in the subprocess call configuration.

5

Excellent troubleshooting thread. Let me provide the complete solution for decision table dynamic conditions in Creatio 7.18, addressing all three critical aspects:

1. Decision Table Context Mapping The context mapping requires explicit parameter scope definition. In your decision table configuration, map the input columns like this:

// Decision Table Input Column Configuration
AmountColumn.Value = #ProcessSchemaParameter.Amount#
DepartmentColumn.Value = #ProcessSchemaParameter.Department#

Not just #Amount# - you need the full ProcessSchemaParameter prefix for proper scope resolution.

2. Dynamic vs Static Value Resolution Dynamic conditions work differently than static ones. The decision table evaluates at runtime, so:

  • Data types must match EXACTLY (Decimal to Decimal, not Decimal to Integer)
  • In the decision table designer, set each input column’s DataValueType property explicitly
  • For Amount: Set to “Decimal” with appropriate precision (usually 2)
  • For Department: Set to “Text” (String)
  • Never use “Auto” for dynamic parameter binding

3. Process Parameter Usage Pattern Ensure your process flow is:

  1. User input/script task populates parameters
  2. Add a script task immediately before decision table to log parameter values (debugging)
  3. Decision table element references parameters with full scope notation
  4. Verify in Advanced settings that “Use background execution” is disabled for the decision table element (can cause context loss)

Additional Configuration: In the decision table element properties:

  • Set “Execution mode” to “Synchronous”
  • Enable “Use process context” checkbox
  • Map return values to process parameters using the same scope notation

Common Pitfall: If using subprocesses, you must explicitly pass parameters in the “Call subprocess” element’s parameter mapping section. Parent process parameters aren’t automatically inherited by decision tables in child processes.

This configuration handles dynamic conditions reliably. The key is explicit data type matching and proper parameter scope notation throughout the entire chain.

6

The timing aspect is worth checking. Make sure your decision table element comes AFTER any script tasks or user actions that populate those parameters. Also, verify in the process log whether the parameters actually contain values at the point where the decision table executes. I’ve debugged similar issues where parameters looked populated in the designer but were null at runtime due to execution order.

7

Thanks for the suggestion. I checked the parameter references and they’re using the hash notation correctly. Still getting the same error though. Could this be related to the timing of when the decision table evaluates? Like maybe it’s trying to resolve before the parameters are populated?

8

Found it! The column data type was the issue. Changed Amount column from Integer to Decimal to match the process parameter type exactly. But there was another gotcha - the decision table context mapping syntax needs to be specific about parameter scope.