InfoPath Dev

This is a strange behavior that we haven't been able to solve.  We have a large form library (50k+ InfoPath forms) with a SPD workflow set to trigger on change.

The example is:

1. I use the Edit Properties ribbon button on my library view to edit a column value on a form.

2. I change the value of the "Request Status" column which is in the InfoPath form's custom content type for the library from "COMPLETE" to "BEGIN" and click Save.

3. I can check the View Properties button on my library view and it shows "Request Status" is now set to "BEGIN" 

4. The workflow is triggered but the is uses the old value "COMPLETE" instead of my new value "BEGIN"

We think maybe there is some issue where the event handler is triggering the workflow and the workflow runs before the value change is committed or something like that?  Any ideas to help us get to the bottom of this would be appreciated.

Thanks,

Eric

Hi Eric,

Did this start happening recently? If so, I'm guessing your hunch might be right for large libraries. If not, it was always happening, right? 

On the other hand, the list/library column data is stored in a single SQL table in SharePoint and that table would also trigger workflows. The reusable workflow can only see the value if it's promoted as a column to the library so it should be seeing the correct value. You're not doing some Nintex XML lookup or something are you? 

Keep in mind that property demotion (setting field data back from library) is inherently a bad practice because no XML validation happens and the forms could break (won't open again) without you knowing. Simple workaround would be to ask people to open the forms in the browser to change status.

Bottom line: this shouldn't be happening based on ShP architecture, but your form library is also way too large. Please consider archiving in separate libraries or moving it all to SQL.

 Hi Patrick,

 This is more of a recent development, it has not always occurred.  Our SP Dev resource has been working on our retention/archive WF for several weeks now and we are finally beginning to see it work properly in our QA environment after several failed attempts, we hope to have it loaded on our production form library at the end of this week so we can start getting these forms archived.  Ideally we should have less than 7500 requests with our planned retention policy.

 We do not normally allow setting promoted column values manually from the library. Either the values are set in the form or by the workflow directly.  I only manually change values to get the form back into a state so I can terminate a failed workflow and restart it.  I notice this issue sometimes when manually changing values but it also appears from the file versioning history to happen (although I can actually prove it) when users use the browser-based form to trigger status changes on promoted columns.

It's all very strange.  We will work on archiving down to a reasonable size and see if it goes away.

Thanks again.