workflow fires twice - triggered from status change on quotes

Discussion:

(too old to reply)

Mark

2010-07-22 17:27:17 UTC

I have a workflow associated with quotes that is set to fire when the status
changes. The first line of the workflow checks the status. If the status is
not won, the workflow cancels, if the status equals won, then the steps
continue.

The workflow fires twice most of the time. Both of the workflows that fire
say they fired because a record attribute changed.

I even created a very simple test workflow to rule out an issue with any of
the steps in my real workflow as being part of the issue.

What people are doing is taking a draft quote and activating it, then
turning the draft quote into a sales order. The process (OOTB) of turning a
quote into a sales order automatically marks the quote as status won.

The workflow fires twice for the users every time.

Here's the really weird thing, the workflow only fires once when I go
through the same process. (I'm a sys admin and the owner of the workflow but
I don't see why that would matter)

Has anyone come across this before?

Thanks

Dave

2010-07-23 15:25:45 UTC

Permalink

Post by Mark
I have a workflow associated with quotes that is set to fire when the status
changes. The first line of the workflow checks the status. If the status is
not won, the workflow cancels, if the status equals won, then the steps
continue.
The workflow fires twice most of the time. Both of the workflows that fire
say they fired because a record attribute changed.
I even created a very simple test workflow to rule out an issue with any of
the steps in my real workflow as being part of the issue.
What people are doing is taking a draft quote and activating it, then
turning the draft quote into a sales order. The process (OOTB) of turning a
quote into a sales order automatically marks the quote as status won.
The workflow fires twice for the users every time.
Here's the really weird thing, the workflow only fires once when I go
through the same process. (I'm a sys admin and the owner of the workflow but
I don't see why that would matter)
Has anyone come across this before?
Thanks

Mark,
When your users activate a draft quote, that changes the status. Then
when they turn it into the sales order, the status changes again. So,
the workflow should run twice, and stop at your first IF when they
activate it, and then complete the workflow when they convert it to an
order. Open up the workflows attached to the quote, you should be
able to see this behavior.

It doesn't make sense that it only fires once for you. As workflows
are asynchronous (don't happen immediately), I suspect you may not be
waiting long enough to see that second workflow fire.

HTH,
Dave

-------------------------------------------
David L. Carr, President
Visionary Software Consulting, Inc.
Certified Microsoft CRM 4.0 Consultant
Cell: 503-351-4207
Email: ***@earthlink.net
http://www.vscrm.com

Mark

2010-07-23 22:32:26 UTC

Permalink

Dave, thank you for your reply.

If I activate the quote and do nothing more, the workflow fires once and
cancels (because the status is not won).

If one of my users activates the quote and does nothing more, the workflow
fires twice and cancels twice.

Then if I wait for however long (long enough for any workflow processing to
finish) and convert the quote to a sales order, the workflow fires once and
succeeds because the status is won.

If one of my users does exactly the same thing and converts the quote to a
sales order, the workflow fires twice and suceeds twice.

Its very strange behavior (the firing twice) and it does it with both my
production workflow and my test workflow.

Post by Dave

Mark,
When your users activate a draft quote, that changes the status. Then
when they turn it into the sales order, the status changes again. So,
the workflow should run twice, and stop at your first IF when they
activate it, and then complete the workflow when they convert it to an
order. Open up the workflows attached to the quote, you should be
able to see this behavior.
It doesn't make sense that it only fires once for you. As workflows
are asynchronous (don't happen immediately), I suspect you may not be
waiting long enough to see that second workflow fire.
HTH,
Dave
-------------------------------------------
David L. Carr, President
Visionary Software Consulting, Inc.
Certified Microsoft CRM 4.0 Consultant
Cell: 503-351-4207
http://www.vscrm.com
.

Dave

2010-07-25 16:49:16 UTC

Permalink

Post by Mark
Dave, thank you for your reply.
If I activate the quote and do nothing more, the workflow fires once and
cancels (because the status is not won).
If one of my users activates the quote and does nothing more, the workflow
fires twice and cancels twice.
Then if I wait for however long (long enough for any workflow processing to
finish) and convert the quote to a sales order, the workflow fires once and
succeeds because the status is won.
If one of my users does exactly the same thing and converts the quote to a
sales order, the workflow fires twice and suceeds twice.
Its very strange behavior (the firing twice) and it does it with both my
production workflow and my test workflow.

Mark,
When your users activate a draft quote, that changes the status. Then
when they turn it into the sales order, the status changes again. So,
the workflow should run twice, and stop at your first IF when they
activate it, and then complete the workflow when they convert it to an
order. Open up the workflows attached to the quote, you should be
able to see this behavior.
It doesn't make sense that it only fires once for you. As workflows
are asynchronous (don't happen immediately), I suspect you may not be
waiting long enough to see that second workflow fire.
HTH,
Dave
-------------------------------------------
David L. Carr, President
Visionary Software Consulting, Inc.
Certified Microsoft CRM 4.0 Consultant
Cell: 503-351-4207
http://www.vscrm.com
.- Hide quoted text -

- Show quoted text -

Wow, that IS strange... whenever I start seeing double like that, I
know it's time for new glasses... You might want to log a call with
MS on this one. Especially because, if I'm reading this right, the
convert of quote to sales order fires twice and works both times?
I'm thinking it should not succeed the second time, because you
shouldn't be able to modify a closed/won quote...

But, if you want to continue to try to debug this, let's get more
info....
What is the workflow's scope? Organization?
What have you checked under "Start When"? Record Status Changes?
(And if you fire on a field change, which fields?)
Is it an on-demand workflow, or a child of another workflow?
Does it call any other workflows within it?

Dave

Mark

2010-07-26 16:50:50 UTC

Permalink

Hi Dave, thank you for your help and effort with this. Hopefully if we fix it
others will benefit!

The workflow is set to the organization level.
It is set to fire when "record status changes".
I do have on demand checked but that was only to test the workflow
previously. I know my users are not running the workflow manually.
The workflow does fire a child workflow (that creates a customer survey
record).
Interesting note, the workflow used to fire on change of a picklist (and a
specific value in the picklist) but I removed that setting on the workflow
because users were not always updating said picklist. The status change to
won is a more reliable trigger.

There is a bit field on quotes, lets just call it yes or no.

The first step of the workflow checks the value of this field (the bit field
is formatted as a list as I know that the other formatting methods for bit
fields have issues with workflows).
If the value is not equal to yes, the worklow cancels.
If the value is equal to yes, the workflow continues.
Next, if the value is yes, the workflow checks the status of the quote.
If it is not equal to yes, the workflow cancels.
If it is equal to yes, the workflow continues.

The purpose of the workflow is not to update any fields on the quote but to
create a new related record through a child workflow (I have built a customer
survey feature into CRM and the survey is created when a quote is won).

So, to summarize:
If that bit value equals no, the workflow cancels as it should. But it fires
twice.
If the bit value equals yes, the workflow checks the status and if is not
won, it cancels as it should. But it fires twice.
If the bit value equals yes, the workflow checkes the status and if it is
won, it creates the survey record as it should. But it fires twice and
creates two survey records.
It fires twice for everyone except me.
I created a very simple test workflow that had very few steps in it and it
also fired twice.

Thanks,
Mark

Post by Dave

Mark,
When your users activate a draft quote, that changes the status. Then
when they turn it into the sales order, the status changes again. So,
the workflow should run twice, and stop at your first IF when they
activate it, and then complete the workflow when they convert it to an
order. Open up the workflows attached to the quote, you should be
able to see this behavior.
It doesn't make sense that it only fires once for you. As workflows
are asynchronous (don't happen immediately), I suspect you may not be
waiting long enough to see that second workflow fire.
HTH,
Dave
-------------------------------------------
David L. Carr, President
Visionary Software Consulting, Inc.
Certified Microsoft CRM 4.0 Consultant
Cell: 503-351-4207
http://www.vscrm.com
.- Hide quoted text -

- Show quoted text -

Wow, that IS strange... whenever I start seeing double like that, I
know it's time for new glasses... You might want to log a call with
MS on this one. Especially because, if I'm reading this right, the
convert of quote to sales order fires twice and works both times?
I'm thinking it should not succeed the second time, because you
shouldn't be able to modify a closed/won quote...
But, if you want to continue to try to debug this, let's get more
info....
What is the workflow's scope? Organization?
What have you checked under "Start When"? Record Status Changes?
(And if you fire on a field change, which fields?)
Is it an on-demand workflow, or a child of another workflow?
Does it call any other workflows within it?
Dave
.

Dave

2010-07-27 15:31:44 UTC

Permalink

Post by Mark
Hi Dave, thank you for your help and effort with this. Hopefully if we fix it
others will benefit!
The workflow is set to the organization level.
It is set to fire when "record status changes".
I do have on demand checked but that was only to test the workflow
previously. I know my users are not running the workflow manually.
The workflow does fire a child workflow (that creates a customer survey
record).
Interesting note, the workflow used to fire on change of a picklist (and a
specific value in the picklist) but I removed that setting on the workflow
because users were not always updating said picklist. The status change to
won is a more reliable trigger.
There is a bit field on quotes, lets just call it yes or no.
The first step of the workflow checks the value of this field (the bit field
is formatted as a list as I know that the other formatting methods for bit
fields have issues with workflows).
If the value is not equal to yes, the worklow cancels.
If the value is equal to yes, the workflow continues.
Next, if the value is yes, the workflow checks the status of the quote.
If it is not equal to yes, the workflow cancels.
If it is equal to yes, the workflow continues.
The purpose of the workflow is not to update any fields on the quote but to
create a new related record through a child workflow (I have built a customer
survey feature into CRM and the survey is created when a quote is won).
If that bit value equals no, the workflow cancels as it should. But it fires
twice.
If the bit value equals yes, the workflow checks the status and if is not
won, it cancels as it should. But it fires twice.
If the bit value equals yes, the workflow checkes the status and if it is
won, it creates the survey record as it should. But it fires twice and
creates two survey records.
It fires twice for everyone except me.
I created a very simple test workflow that had very few steps in it and it
also fired twice.
Thanks,
Mark

Mark,
Definitely strange behavior. I've never seen workflows fire twice,
but the status change one is fairly tricky. I was thinking it might
have been a status and a field update were both firing but that
doesn't seem to be the case.

I have one simple idea for you, besides logging this with MS...
(Assuming all you want to do is create one survey, and can live with
the workflow running spuriously).

Before you create the survey (in the workflow), add a conditional
check to see if it exists for this quote... (If you have a 1:N
relationship between quote and survey, you should be able to look down
to the quote... If not, grab the quote_number or name (some uniquei
identifier of the quote), and copy that value to the survey when it is
created.) Then, when the second run ones, it will find that first
one, and not create the survey. (Now, as workflows fires
asynchronously and unpredictably, you may occassionally get two
surveys to be created, but it should be a rare event...)

All I can think is that there must be something strange happening
inside the 'hidden code' that runs when you click that convert quote
button... I'd still suggest calling MS to get to the bottom of
this... but hopefully the workaround above will help in the
meantime. Please post to this thread when solved... Thanks,

Dave

Mark

2010-07-28 18:08:18 UTC

Permalink

Hi Dave, (I wish the email notification for updates was working for this
thread...)

I'm intrigued by your suggestion but I'm not following how I would check for
the existence of a survey related to the quote.

The relationship is one quote to many surveys.

My workflow is related to quotes and so is the child that creates the survey
when the parent tells it to (the one that is firing twice).

I'm not sure how I can check using a workflow for the existence of one or
more many records associated to the one? I was always under the impression
that you could only update the one from the many using workflows but not the
other way around.

What I was thinking (prompted by your suggestion) is to add a field to the
quote, a simple yes/no. When a survey is created that flag would flip to yes.
Then have the worklow check that flag and if its yes, don't fire the child
that creates the survey. The only issue here, like you said, is that the
workflow could well fire a second time before the yes/no field is updated.

Can you let me know how you implement your suggestion of checking for the
existence of a survey?

Thanks again.

Mark

Post by Dave

Mark,
Definitely strange behavior. I've never seen workflows fire twice,
but the status change one is fairly tricky. I was thinking it might
have been a status and a field update were both firing but that
doesn't seem to be the case.
I have one simple idea for you, besides logging this with MS...
(Assuming all you want to do is create one survey, and can live with
the workflow running spuriously).
Before you create the survey (in the workflow), add a conditional
check to see if it exists for this quote... (If you have a 1:N
relationship between quote and survey, you should be able to look down
to the quote... If not, grab the quote_number or name (some uniquei
identifier of the quote), and copy that value to the survey when it is
created.) Then, when the second run ones, it will find that first
one, and not create the survey. (Now, as workflows fires
asynchronously and unpredictably, you may occassionally get two
surveys to be created, but it should be a rare event...)
All I can think is that there must be something strange happening
inside the 'hidden code' that runs when you click that convert quote
button... I'd still suggest calling MS to get to the bottom of
this... but hopefully the workaround above will help in the
meantime. Please post to this thread when solved... Thanks,
Dave
.

AdamV

2010-08-02 10:10:24 UTC

Permalink

Mark, I think your description is what Dave was trying to say (I
certainly read it the way you describe, using the child creation to
"flag" the quote as already processed.

As a bonus (thinking ahead), you could use a date field rather than a
bit field, and record the date the survey was created. This would give
you the ability to choose to generate a second survey anyway if the
previous one was a long time ago, rather than never doing a second one.
This might be overkill in your scenario, depending on how long your
sales cycles are.

Adam

Post by Mark
Hi Dave, (I wish the email notification for updates was working for this
thread...)
I'm intrigued by your suggestion but I'm not following how I would check for
the existence of a survey related to the quote.
The relationship is one quote to many surveys.
My workflow is related to quotes and so is the child that creates the survey
when the parent tells it to (the one that is firing twice).
I'm not sure how I can check using a workflow for the existence of one or
more many records associated to the one? I was always under the impression
that you could only update the one from the many using workflows but not the
other way around.
What I was thinking (prompted by your suggestion) is to add a field to the
quote, a simple yes/no. When a survey is created that flag would flip to yes.
Then have the worklow check that flag and if its yes, don't fire the child
that creates the survey. The only issue here, like you said, is that the
workflow could well fire a second time before the yes/no field is updated.
Can you let me know how you implement your suggestion of checking for the
existence of a survey?
Thanks again.
Mark

Post by Dave

Mark,
Definitely strange behavior. I've never seen workflows fire twice,
but the status change one is fairly tricky. I was thinking it might
have been a status and a field update were both firing but that
doesn't seem to be the case.
I have one simple idea for you, besides logging this with MS...
(Assuming all you want to do is create one survey, and can live with
the workflow running spuriously).
Before you create the survey (in the workflow), add a conditional
check to see if it exists for this quote... (If you have a 1:N
relationship between quote and survey, you should be able to look down
to the quote... If not, grab the quote_number or name (some uniquei
identifier of the quote), and copy that value to the survey when it is
created.) Then, when the second run ones, it will find that first
one, and not create the survey. (Now, as workflows fires
asynchronously and unpredictably, you may occassionally get two
surveys to be created, but it should be a rare event...)
All I can think is that there must be something strange happening
inside the 'hidden code' that runs when you click that convert quote
button... I'd still suggest calling MS to get to the bottom of
this... but hopefully the workaround above will help in the
meantime. Please post to this thread when solved... Thanks,
Dave
.

Dave

2010-08-02 22:18:56 UTC

Permalink

Mark,
You are correct, you can't "look down" as I put it, within a standard
workflow, you can only "look up" (Except when you do things like
creating activities from a workflow, then you can test the existence
of that activity within the same workflow. But I don't think that
would work here, because the survey would be created by a different
opportunity workflow)...

In any event, your idea of the bit on the quote (or Adam's idea of
using a date field) is probably the easiest way out. I have been
working with online recently, so I can't remember if standard workflow
in 4.0 allows you to compare two fields (like online does) So,what
your workflow could look like is something like this:

1) Check to see if that date on the quote (Survey Create Date?) is
filled in.
2) If not, Update the quote attribute "Survey Create Date" to the
workflow execution time value.
3) Wait 05 seconds
4) (In CRM Live, I can actualy compare a field to the workflow
execution time). If equal, exec your workflow that creates the
survey. (If not equal, the other workflow got there before you).
(If you can't compare the workflow execution time to the quote survey
create date, then just execute the subprocess that creates your
survey.

The basic principle is that if the first thing you do is set that
flag, then the next workflow coming behind you will see that flag set,
and exit. You might still get some dupes, but it should be far
fewer. (And, if you can do that same field to workflow field compare
I just demo'd on my live instance, it should eliminate them
altogether.)

HTH,
Dave

This still won't guarantee you only have one survey

AdamV

2010-08-04 09:15:48 UTC

Permalink

I find there is sometimes a dilemma.

Approach 1: always set the flag immediately so any possible duplicate
workflow will be prevented from running. Downside: if for any reason
your workflow stalls or fails, you have set a flag to indicate it is
done when in fact this is not true.

Approach 2: always set the flag last (and possibly within a conditional
test), so you know that everything worked before you set the flag to say
so. Downside: if a second workflow is triggered before the first has
completed, the flag is not yet set and you may get things happening twice.

Anyone have any thoughts, opinions, preferred methods?

Adam

Post by Dave
Mark,
You are correct, you can't "look down" as I put it, within a standard
workflow, you can only "look up" (Except when you do things like
creating activities from a workflow, then you can test the existence
of that activity within the same workflow. But I don't think that
would work here, because the survey would be created by a different
opportunity workflow)...
In any event, your idea of the bit on the quote (or Adam's idea of
using a date field) is probably the easiest way out. I have been
working with online recently, so I can't remember if standard workflow
in 4.0 allows you to compare two fields (like online does) So,what
1) Check to see if that date on the quote (Survey Create Date?) is
filled in.
2) If not, Update the quote attribute "Survey Create Date" to the
workflow execution time value.
3) Wait 05 seconds
4) (In CRM Live, I can actualy compare a field to the workflow
execution time). If equal, exec your workflow that creates the
survey. (If not equal, the other workflow got there before you).
(If you can't compare the workflow execution time to the quote survey
create date, then just execute the subprocess that creates your
survey.
The basic principle is that if the first thing you do is set that
flag, then the next workflow coming behind you will see that flag set,
and exit. You might still get some dupes, but it should be far
fewer. (And, if you can do that same field to workflow field compare
I just demo'd on my live instance, it should eliminate them
altogether.)
HTH,
Dave
This still won't guarantee you only have one survey