Ideas for inserting timeouts for existing processes

1

Hi Daniel,

Have you tried manually inserting data into wftimeouts table?

Our licence does not allow to INSERT/UPDATE any piece of the data in our database (to be more specific: DDL and DML operations are not allowed). You can lose your guarantee!

Timeouts for already registered items, without passing through the path are quite dangerous - you can create some entry which is impossible to run. Let's say timeout should generate an email notification 7 days before the "Due date". When we are after that date, what should happen with the timeout? Should it be omitted or send anyway?

In my opinion we should create a cycle action and some path - technical one, not visible for ordinary users. Cycle action will find any item which is in the valid step, then move these instances through the path (action "Move workflow (SQL)"). On entry to the step, timeout will be registered.

This solution is able to develop, using only a standard actions, it is registered in the item's history and you can stop the cycle, when it will be unneeded. We try to keep that simple rule, that all actions in the BPS is caused by something, and users can easily monitor, when an action was executed, what was a trigger and what is a result of it.

Thanks for the input. My thoughts went along a similar solution.
We should (can) not circumvent the default logic for timeout creation. So we need a looping path for sure.
Since this is an administrative path it would be hidden in the diagram as well in the form.
The big question is how it would be triggered on option would be the cycling action Paweł mentioned. I would take a different approach though.

I have an "administrative" process in mind. One where you can provide a workflow ids, and path ids which these workflows would need to execute.
Why would I prefer this instead of the cycle:
- It can be reused for other bug fixes
- It can be hardened overtime to prevent bugs
- The cycling action has only one use case and can/should be removed afterwards. This would result in an additional deployment which in turn may require tests, depending on the regulations which apply for the environment

Thanks again for the input

Hi,

You can also use our REST API to edit elements. Thanks to this, you can use tools such as Postman Runner or write your own script that will iterate through the collections of elements and on each of them will go the desired path.

Somehow this thread moved from timeout to the options how an administrative path could be executed. :)

Thanks for this idea and I have one more.
The path is configured to be only visible in admin mode and quick path option is enabled.
In this case you could prepare the URLs with the necessary workflow ids and open the URL in the browser. Depending on the number of workflows it could be the fastest approach.
Depending on the authentication, Windows or Azure AD, you could easily create a PowerShell script to open all URLs. Azure AD authentication would be more complex.