I just came across an interesting issue related to resource throtteling and workflow associations:
When assigning a workflow which should automatically start on item creation or change to a list we automatically try to create a new column in the list which is used to carry the workflow status information. I said "try to create" because the creation routine checks the number of lookup fields on the list and compares it against the threshold for lookup colums configured in the web application general settings:
In case that the maximum number of lookup columns has already been exhausted the workflow status column will not be created - instead the field name "ows_" will be returned and added to the workflow association.
As soon as this workflow association is adjusted (e.g. new workflow instances should be allowed) an exception occurs because the internal logic checks for the existence of the configured workflow status information field "ows_" which does not exist:
Exception information: Exception type: ArgumentException Exception message: Column 'ows_' does not exist. It may have been deleted by another user.
To correct the issue it is not sufficient to just increase the configured threshold as the incorrect status field information has already been persisted in the workflow association. It is required to remove the workflow association and add it back later after the threshold has been adjusted.
To correct this problem the following steps should be applied:
What I find interesting is the whole path to finding this...
Could this occur on Office 365 SharePoint as well? My workflow status columns won't create on my list unless I create a new list. Support had to escalate this issue to "operations".
from my perspective this can happen on Office 365 as well.
Instead of deleting the associated web application, is there any alternate route? We have production systems running an affected workflow. Disassociating is not an option for us.
you need to use the steps outlined above.
If this really is the answer, shoot me now.