Community

I make a flow like like this:   It works as intended and the result in /admin/processes is: ``` "status": { "statuscode": 999, "data": { "dummy": "dummy" }, "statuskey": "stop", "statusmessage": "string", "name": "Stopped", "error": true }, ``` Now I add a timer to the flow. The result will now be: ``` "status": { "statuscode": 999, "data": { "dummy": "dummy" }, "statuskey": "complete", "statusmessage": "string", "name": "Completed", "error": true }, ``` All parameters are the same as I sent in status, except statuskey that does not accept "stop" and will show "complete" and the name "Completed". Here is how it looks in the list:  I was under the impression that "Stopped" could and should be used for when an error occurs like this:  It also makes it easy to search for stopped/failed processes in /admin/processes (visually, as this field is a visible field). (I of course understand that to get the real errors you could search for status.error:true.) Can a timer triggered flow never get the status "Stopped"? Is it by design or a bug? If it is not a bug you might wanna add something about this to the documentation, for example after this section <https://support.onify.co/docs/workflows-2#process-status> ``` Process status The status is something that is set for the entire process, not for a specific state. Here are the different statuses that can be set: continue - To continue the process complete - The process should be considered completed with success pause - The processes should be considered to be paused stop - The processes should be considered to be stopped To mark something to be wrong, set error to true. You can update process status via flow or via API. ``` If could say "Note: Timer triggered flows will always be considered completed after running, so there is no need to try and stop them". In <https://support.onify.co/changelog/onify-hub-api-2110-released> it says "improve: support for nonpersistent processes (and workflows) Process flow will run to end without possibility to be resumed or return any output Process state and status is still possible to update and retrieve **If the flow stalls for some reason, e.g. by a long running timer or waiting for user input, the process will be stopped**" You might wanna add there too that is not the case for timer triggered flows, if it is by design. PS. I hope its a bug that can be corrected, because to me it is strange that a flow that was interrupted by an error and not "completed" should have the status "completed". I'll send the bpmn-files if you need them.

In /admin/processes the column "User" shows 1. For manual triggered flows - the name of the user who triggered it 2. For timer triggered flows - the name of the user who last published the flow Point 2 will make it hard to distinguish if a flow was triggered manually or by timer. Also if you just want to filter on processes triggered by user xxx you will get a lot of false positives. Finally - if you remove this user, maybe the person started at another company, the flow will not be triggered at all until you republish it with an existing user!!! It wood be good if all flows triggered by timer had a generic username like "Timer" to distinguish them. Or it could be definable in a setting like /admin/settings/user_name_to_trigger_timerbased_flows

 <br /> If I go to /admin/processes?term=workflow:<any-flow> it seems only the first 10 items in the list in the field "Flow" will have the checkbox checked. This seems similar to the fix in 2.12.3: fix: schedule and nextRunAt fields in admin interface when listing workflows Maybe that fixes this field too (I did not install it yet, so I don't know) but as the fix mentions two specific fields in another view, it might not. Just so you can check it.