InfoPath Dev

Hi all, I developed a form a few years ago that's been integrated Sharepoint.

On the form I have 10 or so properties that have been promoted. I use those properties in workflow to perform several tasks.

About a year ago when we migrated from sharepoint 2007 to sharepoint 2010, about 5% of the time (5 out of every 100 forms), the workflow starts before the properties are set. I found this out by adding logging to the workflow and I output the value of those properties to the log (appended to some text labels) and they were blank when it ran resulting in an unknown error being thrown. The properties are definitely there though, they were just blank when the form ran.

I added a pause event to give the workflow a few seconds to wait for them in case the form was being saved prior to the properties being set but it appears that once a workflow has started, even with a pause, if the fields were blank when the workflow started, the fields remain blank after the pause, also verified. Logging before the pause showed them to be blank, logging after the pause show it to be blank.

That got me thinking that maybe the submit was the "on create" and the property save was an "on change" event, so I added the logic in the on create workflow to the on change workflow and removed the "on create" event and the workflow was never fired.

Does anyone have any ideas on what I can do to fix this issue or what I can do to avoid the issue? I can provide any additional information if needed, just let me know.

Hey dlcj21,

dlcj21:

On the form I have 10 or so properties that have been promoted. I use those properties in workflow to perform several tasks.
..., about 5% of the time (5 out of every 100 forms), the workflow starts before the properties are set.
... so I added the logic in the on create workflow to the on change workflow and removed the "on create" event and the workflow was never fired.

 

Okay, so you have the promoted properties, no problem, you could promote 100's is you wish.

What 'tasks' does your workflow perform? Updating other lists items, creating other lists items?

The workflow could not start 'before the properties are set', although there are reasons why you may wish to put a pause into the workflow in case there were multiple people updating the item almost simultaneously (yes I've been through all of the blogs and posts relating to this error) . I guess that the actual workflow log just states something like 'The workflow cancelled due to errors' with no other logging? (A really helpful error message when you have a large complicated workflow)

So firstly, he's what I suggest:

• Thoroughly check that any fields used to evaluate logic are the same data type as the other field/data of the other operand. ie do not have an If <Field> (of text type) = 0 (a number type) etc
• Thoroughly check that any calculations that are being performed are all on a numeric data type, sometimes a text data type will not convert properly into a numeric to perform the calculation.
  
• Thoroughly check that the field type of any other lists that are being updated or inserted into are the same type text=text, number=number etc
• Determine if the failed forms are coming from the same users! If so, check their permission on every list that you reference in your workflow. (Permissions to a single list caused me havoc for months in a workflow involving a lot of lists and a lot of people!!)
• Check the failed forms to see if there are any validation errors that are being allowed through specifically if you are allowing text into a what you assume is a numeric field or the values are out of bounds etc (again this is high on the list of things that could go wrong.)
  

So, now to the 'on create' and 'on change' workflow's. The 'on create' workflow will run every time an item is created, in other words ever only once. The 'on change' workflow will run every time an item is changed, in other words every time other than when it was created. It is possible to have the 'on create' workflow trigger the 'on change' workflow which are some of the reasons why you may wish to put a pause into the 'on change' workflow so that the 'on create' workflow has time to finish. Your Sharepoint timer service is probably set to a few minutes so if you say 'pause for 1 minute' then it may actually pause for up to 5 minutes anyway.

From what I can gather you are only concerned about the 'on create' workflow, so I would enable your logic on that workflow only, unless you wanted it to be enabled on both of those events? 

Hope this helps?

Cheers

Thanks for the response.

What 'tasks' does your workflow perform

The workflow on that library simply creates an entry in another library for tracking purposes. The other library is where I have all of the workflow logic built to send out notifications letting approvers know they have work to do. I've never had an issue with the workflows on that library. When the workflow on the form library fails, it does not create an entry in the other library which results in no communications being sent out, which means we have to have people manually getting involved when it should be a completely automated process, which it is, 95% of the time.

The workflow could not start 'before the properties are set'

Could you explain that a little? I'll clarify what I meant when I thought that the on create was running prior to the properties being set.

For example one of the properties I have on the form is FormType. It is not a field that's editable by the users and it defaults to the type of form it is, for simplicity sake, lets say it defaults to FormType1. My first step in the workflow checks to see if the FormType is FormType1, which it always should be, but at the time the workflow starts, FormType is blank. If I add a pause or a wait for FormType to have a value, the workflow will be paused or waiting forever even though when I go to the sharepoint library, under the FormType column, it shows FormType1.

This is where I mentioned that I added logging to the workflow. I added a Log to History step with the text qualifier of "FormType: " then I put the formtype field after it. On the forms that resulted in a failed workflow, the log showed "FormType: ". On the forms where the workflow was successful, the log had "FormType: FormType1" in the history, so that's what lead me to believe that the properties weren't set when that workflow was initially fired on the forms that failed.

So firstly,...

I'll go through the process of verifying the evaluating the logic but I don't have any extravagant calculations being done. The one thing you mention about permissions is an area I'll focus in. On this sharepoint site I have everyone with network authentication set to the contribute role so permissions shouldn't be an issue but the forms that fail are related to 2 users mostly but those users have some that go through fine and others that don't.