Using Jump-To for Workflow Rejection: Limitations and Correct Backward Targeting (Mendix 10.24.10)

0
I am implementing a rejection (send-back) feature in a Mendix Workflow (version 10.24.10), and I am currently evaluating whether the built-in Jump-To functionality can meet the business requirements.I understand that Jump-To allows navigating to UserTasks within a workflow, but I have the following concerns:Backward-only targeting: For a rejection scenario, only activities that occurred before the current position should be selectable. However, the current Jump-To options do not seem to guarantee that only previous steps are listed.Timeline consistency: When a rejection occurs, the workflow timeline and audit history must remain logically consistent (e.g., no future steps should appear as completed before the rejection point).Branch-aware behavior: If the workflow has branching paths, the rejection logic must correctly follow the actual execution path taken and only allow returning to valid previous steps in that branch.Given these requirements, it appears that the existing Jump-To functionality may not fully meet the needs for a robust rejection feature.Has anyone implemented a rejection mechanism under these constraints using Jump-To, or are there recommended design patterns or alternative approaches in Mendix 10.24.10?Any guidance or best practices would be greatly appreciated.
asked
3 answers
1

Jump-To technically allows jumping to a UserTask, but it is not a good fit for a proper rejection / send-back scenario. It does not guarantee backward-only steps, can cause timeline inconsistencies, and is risky in workflows with branches.


The recommended approach is to use a Decision activity instead of Jump-To. After each important UserTask, add a simple Approve / Reject decision. The Reject path should be explicitly connected to a clearly defined previous step in the workflow.


With this design, the workflow does not “jump back” unexpectedly. It continues in a controlled and logical way, so the timeline and audit history stay clean and easy to understand.


This approach also works better with branching workflows, because the rejection follows the actual execution path. For Mendix 10.24.x, designing rejection flows with Decision activities is the simplest and most accepted best practice.

answered
0

Are you saying that after Reject, we should place a “Content Revision” user task and then use a Jump activity to return to the first approval step?

answered
0

Actually, I’m not suggesting “Reject → Content Revision task → Jump back to the first approval step”.


What I mean is: don’t use Jump-To at all for send-back/rejection. Instead, model the “send back” as a normal, explicit path in the workflow.


A simple example:


  • Draft / Content Revision (User Task)
  • → Approval 1 (User Task)
  • → Decision: Approve / Reject
    • Approve → next approval / end
    • Reject → goes to Content Revision (User Task)



answered