I’m having issues with a custom microflow that should trigger after a decision table evaluation in our approval workflow. The decision table executes fine and returns the correct output (I can see it in the debugger), but the subsequent microflow that’s supposed to process the decision isn’t being called.
The setup: Decision table evaluates approval requests based on amount and department, outputs an approval level (1-3), then a microflow should route to the appropriate approver group. The decision table output mapping looks correct to me, and I’ve verified the microflow has the right input parameters.
This is causing significant approval delays since requests are just sitting in limbo. Has anyone encountered similar issues with decision table to microflow handoffs? I’m wondering if it’s a permissions issue or something with how the workflow references the microflow.
Timing shouldn’t be an issue - Mendix workflows execute synchronously in sequence. However, I’d check if your microflow is actually being called by adding a log message as the very first action in the microflow. If you don’t see that log entry, then the call isn’t happening at all. Also verify in the workflow editor that the connection line from your decision table to the microflow activity is properly configured - sometimes these can get disconnected during updates.
Let me provide a comprehensive solution based on common issues with decision table to microflow handoffs:
1. Decision Table Output Mapping:
First, verify your decision table is correctly configured. In the decision table editor, check that your output column is mapped to a workflow variable (not just a local decision variable). The output should be: $WorkflowVariable = [DecisionResult]. If you’re using a local variable only within the decision table, it won’t be accessible to subsequent activities.
2. Microflow Permissions:
Even if the workflow role has access to the microflow, check the microflow’s ‘Apply entity access’ setting. If enabled, it will enforce entity-level security which might block operations. For workflow microflows, you often need to set this to false or ensure your workflow context has the necessary entity access rights. Go to: Microflow properties → Security → Allowed roles (verify workflow module role is checked) → Apply entity access (consider setting to ‘No’ for workflow processing microflows).
3. Workflow Configuration References:
This is likely your main issue. After updating decision rules, Mendix sometimes loses the proper binding between activities. Here’s the fix:
Open your workflow in the Workflow Editor
Click on the microflow call activity that follows your decision table
In the properties panel, check the ‘Microflow’ dropdown - if it shows the microflow name but the full path looks odd or has warning indicators, delete this activity
Re-add a new ‘Call Microflow’ activity and select your microflow fresh
In the parameter mapping section, manually map the decision table output: select $ApprovalLevel from the dropdown (don’t just type it)
Ensure the parameter type matches exactly (Integer to Integer, String to String, etc.)
4. Debugging Steps:
Add logging at these points:
End of decision table: log the output value
Start of microflow: log that entry was reached
If you see the first log but not the second, the call is failing
5. Common Gotcha:
If you’re using Mendix 9.18, there was a known issue with workflow variable scope after decision tables. The workaround is to add an intermediate ‘Change Workflow Variable’ activity between the decision table and microflow call, which forces the variable to persist properly in the workflow context.
Try these steps in order and let me know which one resolves it. The workflow configuration reference issue (point 3) is the most common culprit in my experience.
Have you checked the workflow configuration itself? I’ve seen cases where the workflow definition gets out of sync with deployed changes. Try doing a full redeploy of the workflow module. Also, in your decision table, make sure the output parameter type exactly matches the input parameter type of your microflow - even subtle differences like Integer vs Long can cause silent failures in the handoff.
Check your microflow’s execution context. Decision tables in Mendix workflows run in a specific security context, and if your microflow requires elevated permissions, it might fail silently. Go to the microflow properties and verify the ‘Allowed roles’ setting matches what the workflow user context has access to.
Thanks both. I checked the microflow permissions and they look okay - the workflow module role has access. I’m not seeing errors in the console though, which is odd. The decision table output is mapped to $ApprovalLevel, and I’m passing that to the microflow. Could there be a timing issue where the microflow call happens before the variable is fully set?
I had something similar last month. The issue was that my decision table was outputting to a variable, but the microflow call wasn’t properly mapped to use that variable as input. Double-check in your workflow editor that the ‘Call Microflow’ activity is correctly referencing the decision table’s output variable. Also, are you seeing any errors in the console logs? Sometimes these fail silently in the UI but throw errors in the backend logs.
Another thing to check: open the workflow in the Workflow Commons module and verify the microflow is still properly referenced. Sometimes when you rename or move microflows, the workflow keeps an old reference that appears correct in the editor but is actually broken. You might need to delete the microflow call activity and re-add it fresh to ensure the reference is current.