You’re offline. This is a read only version of the page.
185
I have a workflow set to activate on the update of a field. In the first line of the workflow, a condition checks that field for the value I want. I've validated that the Audit History shows that the field I'm looking for changes multiple times, but only changes to the value I'm seeking once. However, when I go and look at the system processes, the workflow is triggered multiple times and gets PAST the conditional check that (even if the workflow runs more than once) should ONLY pass the condition one time.
Is there a known issue with workflows configured to react to field changes?
Audit History:
Workflow conditional step, workflow is configured to wait a specified amount of time before continuing.
Three duplicate system processes. All three successfully passed the above conditional step.
*This post is locked for comments
As Kokulan suggested, create a CWA to check if there other waiting workflows.
I used the below code to retrieve the waiting workflows from the entity asyncoperation and cancelled these instances. As input parameter, I passed the workflow to be fetched.
You can change it as per your need.
Entity workflowReq = service.Retrieve("workflow", Workflow.Get<EntityReference>(executionContext).Id, new ColumnSet(new string[] { "name" }));
QueryExpression query = new QueryExpression("asyncoperation");
ColumnSet cols = new ColumnSet(new string[] { "asyncoperationid", "statecode" });
//create conditions
ConditionExpression c1 = new ConditionExpression("workflowactivationidname", ConditionOperator.Equal, workflowReq.Attributes["name"].ToString()); // Guid of the workflow -input property
ConditionExpression c2 = new ConditionExpression("regardingobjectid", ConditionOperator.Equal, context.PrimaryEntityId);// entity id
ConditionExpression c3 = new ConditionExpression("statecode", ConditionOperator.Equal, 1);//statecode Waiting
//ConditionExpression c3 = new ConditionExpression("statuscode", ConditionOperator.In, new int[] { 0, 10, 21, 20 });//statuscode Waiting, Waiting For Resources, Pausing and In Progress
//create the filter
FilterExpression filter = new FilterExpression();
filter.FilterOperator = LogicalOperator.And;
filter.AddCondition(c1);
filter.AddCondition(c2);
filter.AddCondition(c3);
query.ColumnSet = cols;
query.Criteria.AddFilter(filter);
//get the collection of results
EntityCollection colResults = service.RetrieveMultiple(query);
foreach (Entity async in colResults.Entities)
{
Entity e = async;
//change the status of the system job
e["statecode"] = new OptionSetValue(3); //cancelled
//update the object
service.Update(e);
}
If your flow triggers on Update of the record, you will still have 3 flows instances firing though unless you schedule you flow do a batch processing sort of thing
If there will ever be one waiting workflow for one record, you can make other workflows not to wait, by querying AsycnOp - this could be done via a CWA.
I have faced this issue and it was due to multiple updates. what happens is 3 - updates - created 3 background jobs to update the field.
Now even if you convert it to real-time , still 3 instance will get created and update the field again.
Solution - change the workflow to Realtime , I ended up creating a flag/boolean field (Name it Dialer List Status Update? with default value as no) . and logic goes like this:
if ( Dialer List Status Update? == No Or Dialer List Status Update? doenst contain data)
{
// do your logic
update the Dialer List Status Update? == Yes.
}
Stop the workflow.
So in next run there wont be any update as we will have the flag updated.
Caution : In my case it was just one time action. As record was cancelling. but if in your case this field gets update everyday or repeatedly , you will have to think of updatting the flag back to No using some other approach post this transaction.
Unfortunately the wait is a requirement due to our integration with the 3rd party. I cannot actually move the record until ~2 hours AFTER the initial status change to 'Completed'. There are definitely other ways to accomplish this, I've contemplated using a Flow. If I can't get the vendor to modify their update process I'll probably look into that. Right now, the Workflow does actually finish and complete, however, it will leave 1 or 2 orphan processes stuck in 'Waiting' that have actually failed because the record has been deleted by the first workflow to complete.
Hi
Yes the waiting is only for Background WF not for RTWF.
The following is just an idea, i have not tried but dont see why its not possible
If the waiting is really important, one trick you could try is to create a CWA that does a
System.Threading.Thread.Sleep(60000);
But if this waiting logic will have to be there, you might again run into similar issue as there will be 3 Thread.Sleeps, Do you really need the waiting logic?
RTWF must not have this possibility because RTWF will force the end user to wait until it is completed. That's why it is not available.
I'm going to ask them about that today. They're really making unnecessary secondary and tertiary updates.
I'm trying to re-configure this workflow to Real-Time, but I no longer have the option to add a wait condition. I thought RTWF could use wait conditions and timeouts as any other workflow could?
We have a 3rd party integration that is updating the status on that record so I cannot throttle it in any way. I will try converting it to a RTWF and if that doesn't solve it, I'll attempt to move it into a plug-in.
Hi
I think the problem you are facing here is due to Dialer List Status fields is changing really fast, so the workflow instances are fired almost at the same time (milliseconds or fractions of seconds gap) so at the time when all three workflow check the condition it is satisfied and that's why they all update.
Could you try the following? you update the Dialer List Status field at least in more than one minute gap (use Thread.Sleep or something similar), only first workflow should update and other two conditions will fail.
You are right in thinking about converting this to Real-Time, that will most likely solve your problem.
One word of caution, firing loads of Real-Time is a bit more expensive than actually moving this code to a plugin. if you convert to RTWF, check the performance as well.
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
291,240
Super User 2024 Season 2
#2
Martin Dráb
230,149
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (