Tag Archives: Error

SharePoint Designer Workflow Intermittently Fails to Update an Item in Another List

SharePoint Designer Workflow Intermittently Fails to Update an Item in Another List

Symptom: Workflows periodically fail with the following error message in the Workflow History Log:

The workflow could not update the item, possibly because one or more columns for the item require a different type of information

Possible Data Causes

The data used in the update is invalid, such as putting text in a number field or not providing a value for a required field.

The data used in the update does not provide a unique value in a field that requires unique values.

The data string used in the update is too long, such as putting a string that is more than 255 characters in a field with a data type of “single line of text”

Workaround: Compare the data type and validation rules between the two lists to find the mismatch. You might also add one or more Log to History steps to capture the value of certain fields prior to the Update step. Correct the validation rules in the list from which the data is being transferred to match the validation rules in the list receiving the update.

Possible Permissions Cause

The workflow initiator does not have the level of permissions required to perform the list update. In this case, you may see that some initiators always have their workflows complete, while other initiators always have their workflows fail.

Workaround: In a 2010 Workflow, use an impersonation step to have the update complete using the permissions of the workflow author. In a 2013 Workflow, use an App Step to allow the update to be performed with App level permissions, which allows read and write access to all items on the site.

Possible Performance Cause

On updates that require complex data manipulation or lookups, or updates that require a secondary workflow to complete before the next step in the current workflow, the workflow may error out if the dependent actions have not yet completed when the workflow attempts the Update action. This may also be a problem with high numbers of simultaneous workflow initiations or in environments with known bandwidth issues.

Workaround: Add a step to pause for X number of seconds to allow the dependent actions to complete before attempting the Update step.


InfoPath Form in SharePoint 2010 Error: Root of the Certificate is Not Trusted


An InfoPath 2007 form deployed in 2010 gave repeated errors on opening, including:

“You do not have permission to access a web service.”

“The root of the certificate is not a trusted root authority.”


The InfoPath form in question was an administrator-approved form which called a SharePoint web service called GetUserProfileByName in order to pre-populate several fields with the current user’s data.  Permissions were checked and the data connection (UDCX) files were examined for errors, including incorrect URLs. The form threw no errors in SharePoint 2007.  A search for the correlation ID in the Windows Application Event logs revealed an error regarding the main wildcard SSL certificate for the site. This certificate had a valid date range and was working correctly to authenticate https traffic.


Several blogs (Share-n-dipity Eric Kraus’ SharePoint/.NET Blog ) pointed out that SharePoint 2010 has its own trusted authority store, separate from the Windows certification registry; these blogs were focused on the error when using claims authentication. This forum: InfoPath Form Errors after In-Place Upgrade from MOSS 2007 to SharePoint 2010 was more InfoPath specific. By default, only the “local” trust resides here (Central Admin>Security>Manage Trusts), but additional certificates may be added. Do not delete the “local” connection; it is used internally by SharePoint.

“I trust you, baby. I just don’t trust your friends.”


The error in the event logs meant SharePoint was complaining that the root of the authentication chain was not listed as a trusted certificate-issuing authority in the SharePoint trusts store.  In other words, SharePoint was saying, “This document looks legitimate, but are you sure the person who gave it to you was legit?” Registering the issuing authority’s certificate verifies that the authority is a trusted source. If your SSL cert includes a certificate hierarchy, all the certificates in the hierarchy must be listed in the managed trust store of SharePoint 2010.

Let’s Play “Find the Cert!”


To identify the issuing authority certificate(s) in use, find your SSL cert in the certification management console on the server on which the certificate has been installed. (Run > certmgr.msc) You may have to look under the Personal folder to find the SSL certificate (or if someone else installed the certificate, it may be under their Personal folder when logged in under their profile). In our case, the SSL cert had a 3 tier hierarchy. We noted the certificate names and exported each certificate by right clicking the certificate in the list and exporting it using the default settings to produce a .cer file. We then uploaded them to the Managed Trusts site in Central Admin, giving each a reasonable name and providing no other optional info.

One thing to note: the name displayed in the certificate hierarchy is not the name listed in the certificate list, but rather, the “friendly” version of that name. In our case, they were nothing alike, and we had a difficult time locating one of the certificates because the friendly name did not display in the regular screen display. To see the heirachical name, the user must scroll several fields to the right.

Additionally, the listing of certificates in SharePoint’s Managed Trusts center was required with this InfoPath form because the form was an administratively-deployed form containing code. InfoPath forms which do not contain code and which are published to SharePoint by users will likely not encounter this problem.