0

I am working on a Sharepoint Online environment. I have a 2013 Main Workflow running sub 2010 workflows. Let me set this straight: everything worked properly until today. I never saw this error before, and I am finding the waste of time trying to search online as to what this generic stupid error could really mean extra-annoying.

The main workflow is being accessed as supposed to, the history logging is being done properly in this first stage. Once the sub workflow is accessed, immediately the error is logged in the history list. And when I say immediately, I mean immediately, the first command is not even done. (In fact Status is saying: Failed on start)

Status:

Failed on start (retrying)

Description:

The workflow could not create the list item. Make sure the list exists and the user has permissions to add items to the list

Outcome:

Unknown error

The thing is, the 'Create item' command in the sub workflow, comes after the Sub workflow would supposedly have already created 2 history logs. These are nowhere to be seen in the history list: I only see the error. So Sharepoint is telling me that the item could not be added because: the list may not exist, or the user may not have permissions, BUT the flow would not have reached that point, as no logs are actually surpassed! Nice one Sharepoint :')

I changed the permissions of the client experiencing this issue to be global admin, but it didn't solve the problem. I am trying to run them from my account but still: same problem.

I found somewhere that the problem could be with cache, but I cannot seem to find from where I can reset it. Besides, having to reset the cache because of this idiotic problem. to me, really makes no sense.

Any suggestions would be appreciated.

UPDATE: The workflow is working properly on previously created list items. The issue is happening on newly created list items. Other workflows are working properly too: for example, I have a workflow which runs automatically on creation/update and it's working as supposed to.

  • Check are you SuperReader and SuperUser accounts still active. Had similar issue recently when those accounts were disabled (by default SP doesn't auth with those accounts just uses them to build cache so the lastLogin in AD is not updated never and our AD cleanup job picked up accounts and marked them as disabled I got all sorts of strange issues I couldn't explain) – Marek Sarad Nov 14 '16 at 16:07
  • Thank you @MarekSarad Where do I check whether the SuperReader and the SuperUser accounts are still active? – Jurgen Cuschieri Nov 14 '16 at 16:10
  • There is one more thing that may throw off your app. As I understand the issue you are experiencing is with the SP2010 workflow. How they were created? There is this bug that WF will execute under account that created them, when that account is disabled/deleted (when user leaves company) the WF published under that identity are failing. – Marek Sarad Nov 14 '16 at 16:10
  • To get SU and SR run those commands in Sharepoint PowerShell $wa = Get-SPWebApplication -Identity "[URLofAPP]" $wa.Properties["portalsuperuseraccount"] $wa.Properties["portalsuperreaderaccount"] after you get SU and SR you can try to log in with those accounts to the web site. – Marek Sarad Nov 14 '16 at 16:12
  • You mean to tell me that the 2010 workflows I created (around 20), cannot be run by employees of the client company who are obviously using the Sharepoint site under their own accounts? – Jurgen Cuschieri Nov 14 '16 at 16:12
0

Granting full control permission to workflow solved my problem. This solution was provided by the Microsoft Office 365 support team after opening a support request.

Important: The procedure assumes the following:> The procedure must be completed by a user that has Site Owner permissions.> The workflow must already be published to the SharePoint site.

To grant full control permission to a workflow

  1. Click the Settings icon as shown in the figure.

  2. Go to Site Settings.

  3. In the Users and Permissions section, select Site app permissions.

  4. Copy the client section of the App Identifier. This is the identifier between the last "|" and the "@" sign, as shown in the figure.

  5. Navigate to the Grant permission to an app page. This must be done by browsing to the appinv.aspx page of the site.

Example: [http://%7bhostname%7d/%7bthe]http://{hostname}/{the Site Collection}/_layouts/15/appinv.aspx.

Note: The 'app' in this step refers to the Workflow app in general and not just a specific workflow. Individual workflows cannot be access controlled. When you enable app permissions you are enabling for all workflows within the Site Collection.

  1. Paste the client id in the App Id field and then click Lookup, as shown in the figure.

  2. Paste the following Permissions Request XML to grant full control permission.

    <AppPermissionRequests> <AppPermissionRequest Scope="https://domain.sharepoint.com/sites/NameofSiteColeection" Right="FullControl" /> </AppPermissionRequests>

Caution: There are no placeholders in the Scope value above. It is a literal value. Enter it exactly as it appears here.

  1. Click Create.

  2. You will then be asked to trust the Workflow app. Click Trust It.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.