Iām not totally clear on the repeat option in the workflow setup.
Iāve got a workflow that runs whenever a case is modified. I want it to run on each case until the conditions are met. Once the condititions are met on the case (which triggers a bunch of tasks being created) I donāt want it to even run again.
Right now, I have a custom field call it ātasks created alreadyā
So the rules on the case are - check everytime itās modified and run workflow IF:
Assigned user is not empty AND the ātasks created alreadyā doesnāt have any value
One of the workflows tasks is to place a value of ā1ā in the ātasks created alreadyā box and then create all the tasks.
Iām finding that under some yet to be determined circumstance, the workflow is being re-triggered so then I end up with a duplicate set of tasks.
The workflow creates like 21 case tasks. Recently Iāve seen a circumstance where the server has returned an error 500 before coming back from finishing the workflow yet all the tasks are there.
Seems like the workflow system is can be buggy?
Iām running 7.2.1 but upgrading might be a nightmare as it would be our first upgrade and weāve done quite a bit of customization so itās never been verified that everything weāve done is 100% upgrade safe. Trying to avoid delay crossing that bridge as otherwise the system is working okay as-is.
So Iāve got a workflow that when the assigned to changes on a case it creates 21 tasks and modfies a couple case records. It takes FOREVER to load the workflow to edit and several times I made a change and saved it before all the action fields had finished loading. Doh!
So then I decided to break the workflow up into chunks. The last chunk modifies the case field that indicates the tasks have been created so they donāt get recreated if the assigned to on the case changes.
The problem is, itās running the last chunk before some of the other work flows so not all the chunks get exectued. How can I control the order the workflows are processed in. Itās obviously not be the date/time the workflow was created as I created them in the order I wanted them executed. If they are run simultaneously then somehow the last chunk is finish before the others.
BTW, the āany changeā condition still doesnāt work. Been a long standing bug. At least when using on the assigned to field in cases. I have to create a custom field to compare to the assigned to to determine if it has changed.
The aow_processed* tables (2 of them) really get HUGE if you have lots of workflow tasks going on, I mean into the GB where the next biggest table is a couple hundred MB on on particular installation.
All my workflows are repeating. Can these tables be periodically emptied without major consequence? Isnāt there a database trim scheduled event? Should these tables be candidates for adding to that script?
Since you made a bunch of Topics for this issue, Iāve moved them all into one topic so all information is in one place.
For future reference, the āRepeated Runsā functionality will cause the Workflow to perform its Action every minute. (Whilst conditions are met)
It is not a good idea to have this turned on unless using the āAny changeā operator on a field as this can cause the Workflow to fire constantly, causing slowdown.
On workflow, you can set it to run on āNew Records, Modified Records, All Recordsā
New Records: The workflow will run on a newly created record. If conditions are met, the Action is performed.
Modified Records: If a Record is modified, The workflow will run on it, and if the Workflow conditions are met, the Action is performed
All Records: Workflow will run on New Records, Modified Records and any time a record is saved. If conditions are met, Action is performed.
It would be a good idea for you to turn off āRepeated Runsā on any workflow that doesnāt explicitly require it and use one of the above conditions.
The workflow should run and fire as you expect.
I would uncheck the repeated runs if the āAny Changeā condition actually worked. It doesnāt. I set a workflow for Cases, condition is field: assigned to condition: any change. To insure it wasnāt something wrong with my huge list of actions, in this test workflow there is only one action, create tast with subject: test
The workflow does NOT trigger when the assigned to field of the case is changed from not assigned to assigned to a user. Why donāt you try and verify it for yourself so maybe then it could be fixed? I am running version 7.2.1. If workflow code has changed since and there is not problem then I will try an upgrade on my development copy to see if that fixes it but I am not going to go through the work until you can verify that Case: Assigned To: Any Change workflow actually works pointing to some issue with my version/installation.
By the way, are the actions in the workflow performed in the order they are listed?
Does the repeated workflow still run every minute if the trigger is record MODIFIED because the workflow runs as soon as save the case record. It would seem to me that a workflow with trigger being modified record even if repeated is enabled would never need to run until a record is actuallys saved?
I think I mentioned this in a thread many months ago. And itās still an issue?
The issue now is, I donāt see the assigned to field in the cases field list so how do I turn off auditing for the assigned to field for the case module or is there some code replacement I can use to fix the problem until it is fixed in a future version?
I still need to know the purpose of the aow_processed* tables. I after fixing the āany changeā condition not working on any field with auditing enabled via code hack, in just a matter of a day I already see these tables still growing even without having repeated workflows anymore and not much use of the system. They are already over 30MB, and besides my tasks_cstm table at 16MB, the next closest table size is tasks at 1MB and then next table is 0.5MB. Seems these aow_processed tables grow large very fast when using workflows. Can they me emptied periodically without serious consequence or trimmed based on datetime stamp?
