In our application, we work with multiple records simultaneously and the system is not based on a single table structure. User actions are triggered from forms or buttons, and when an action is executed, only the row or rows that the user is actively interacting with should be affected. Specifically, certain fields such as status or assigned worker need to be updated only for the selected job. Updating the entire table is never the intended behavior; the operation must strictly remain row-specific.
To implement this logic, I created a manually triggered workflow. The trigger type is explicitly set to manual, and inside the workflow I use row-level actions such as setting column values. For targeting, I rely on the “Current Row” context, assuming that the workflow would inherit the row context from the button or form that triggered it. From a logical perspective, this should ensure that only the active record is modified.
However, the workflow does not behave as expected. In some cases, the manual workflow does not execute at all. In other cases, it executes but completely ignores the current row context. Instead of updating the selected record, the system either modifies the first row in the dataset or applies the changes to all rows in the table. This behavior strongly suggests that the workflow is running without any awareness of the active row that initiated the action.
This issue is critical for our use case because the application logic is more complex than a basic single-table, single-row scenario. The system is designed to handle multiple records, multiple datasets, and form-based interactions where precise row targeting is essential. Without reliable row context propagation, it becomes impossible to safely use manual workflows for real operational processes.
At this point, the problem appears to be related to how manual workflows handle or lose row context, rather than an incorrect configuration of the actions themselves. I am trying to understand whether manual workflows are actually capable of receiving and respecting a current row context. If they are, what is the correct and supported way to pass that context into the workflow? If they are not, what architectural pattern is recommended to safely achieve row-level updates in a multi-table, form-driven workflow setup?