Best practice for trigger a process definition after a long period of time.

Hi Marciano Ballestero,  We now have many process definitions with wait events.  Some for just hours, some for days.  We don't have anything over months though.   While it seems to be happy with these sitting in the cron table (I guess that is where they live) and they function well  - I do like your question and would be interested to hear an expert opinion too ;-)

Our original integrators also created a way to expire warranties in our system which runs custom code ('Job') from the Scheduler (runs daily).   In my mind this seems preferable to filling up the cron table with pending rows of 'stuff' waiting.   I think?...    And that may be a more in depth code implementation than an simple admin function like BPM would be.   It maybe depends on how many records you are talking about to know if you could expect performance issues?   I suspect 120 days is perfectly OK for process Definitions if the amount of records is reasonable.

Sorry this is not an 'answer', I am just interested also in the same question ;-)

Luke.

Hi Marciano,

I also had a request for a process that would wait 120 days for a change.  I recommend that you make that process separate from any other function in your system AND your should have an "Escape" clause to end the process if the change doesn't happen or some other change takes place.

I'm not aware of how specifically the workflow maintains long processes run - that only developers know, but in general, the "hibernation" of the generic process instance increases the risks of technical failure at times.
Therefore, I'd suggest just setting a-day-to-return in the database (versus relying of probably temporary storage) and set up a generic daily process of filtering the records to review on the basis of a-date-to-return

This approach is employed by Need To Do Viewer addon for managing dates not-to-miss: integroscrm.com/.../