Post
Ask Question

SharePoint 2013 Troubleshooting - Workflows Failed To Publish / Something Went Wrong

Problem Description

 
Workflow Error
 
Users are unable to publish new or existing 2013 workflows from SharePoint Designer to subsite. All attempts to publish 2013 workflows in this subsite fail with an error:
 
Microsoft.Workflow.Client.InvalidRequestException: Scope is not in an updatable state. Its current state is 'Unregistered' Microsoft.Workflow.Client.InvalidRequestException: Scope '/SharePoint/default/ee24f72e-04d0-420c-8264-cfbbc83ffd76/867bb878-7803-4b19-a8b3-f642b4315e94' is not in an updatable state. Its current state is 'Unregistered'. HTTP headers received from the server - ActivityId: 7c0b71ae-78a5-466c-b244-2d63303e38e4. NodeId: ASP2013. Scope: /SharePoint/default/ee24f72e-04d0-420c-8264-cfbbc83ffd76/867bb878-7803-4b19-a8b3-f642b4315e94. Client ActivityId: 6d99399f-e005-b0aa-d004-0beeb6698e25. ---> System
 
 

Browser Error

 
Something went wrong. To try again, reload the page and then start the workflow.
 
 

Cause

 
As the error indicates, workflow publishing failed because the Workflow Manager scope for the site was in an unregistered state. We verified that the scopes for the site and the subsite were listed as unregistered in the Workflow Manager Resource database (WFResourceManagementDB).
 
When a site collection is deleted, SharePoint signals the Workflow Manager farm to unregister the scopes for that site and all child subsites. As a result, WFM deletes all in-progress workflow instance data related to the site as well as the internal links that make workflow history possible. The site was restored from the site collection recycle bin using Restore-SPSite, but restoring a deleted site does not re-register WFM scopes related to the site. Since the entire site had been deleted, the WFM scopes for all subsites within this site collection were also in an unregistered state.
 

Resolution

 
To resolve this issue, I deleted unregistered scope related to the site and its child subsites.
 
With no scope entry for a given site/subsite, SharePoint will re-create the entry the next time a 2013 workflow is published to that site.
 

Powershell

 
From a SharePoint server, Open PowerShell_ISE as Admin and identify the ID of the affected subsite by using the below script.
  1. Add-Pssnapin “Microsoft.SharePoint.PowerShell”        
  2. $webUrl = 'https://global.sharepoint.com/sites/sp/workflow Jump '  
  3. (Get-SPWeb $webUrl).ID  

SQL Instance

 
Open the SQL instance for the Workflow Manager which is hosting the Workflow Manager databases, confirm that the scopes are actually unregistered by running the below Queries.
 
Find the scope(s) related to the subsite by using the below Query,
  1. --===============================  
  2. -- Use the web ID here...  
  3. DECLARE @webID nvarchar(50) = '867bb878-7803-4b19-a8b3-f642b4315e94'  
  4.   
  5. --Change below to correct resource management DB name if needed  
  6. USE [WFResourceManagementDB]  
  7.              
  8. SELECT s.ScopeId, s.ParentScopeId, s.Path,  
  9.        s.Status, s.HasTopic, s.Description,  
  10.        s.RevisionNumber, s.Created, s.LastRevised,  
  11.        s.DisplayName, s.RowVersion  
  12.   FROM Scopes s WITH(nolock)  
  13.   WHERE description = @webID  
  14.   OR path like '%'+@webID+'%'  
  15.   ORDER BY s.Path  
  16. --===============================  
Using the ParentScopeId values from the output of 2a, find the parent scope..
  1. --===============================  
  2.  -- Use ParentScopeId from 2a here...  
  3.  DECLARE @parentScopeId uniqueidentifier = 'EABD89EE-B1A9-C480-D381-4EF089DD2617'  
  4.     
  5.  --Change below correct resource management DB name if needed  
  6.  USE [WFResourceManagementDB]  
  7.     
  8.  SELECT s.ScopeId, s.ParentScopeId, s.Path,  
  9.            s.Status, s.HasTopic, s.Description,  
  10.            s.RevisionNumber, s.Created, s.LastRevised,  
  11.            s.DisplayName, s.RowVersion  
  12.   FROM Scopes s  
  13.   WHERE s.ScopeId = @parentScopeId  
  14.  --===============================  
Note
We are just making sure with the above two Queries to confirm that the scopes are Unregistered.
 
Identify and delete the related unregistered scopes as needed.
  • Identify the related scopes, using same value from @ParentScopeId from 2b above. (If this doesn't work use the below one)
  • Use the below Query, I just passed the Web Id instead of the parent scope id. To check the status of the scope is “Unregistered”.
    1. SELECT * FROM Scopes s WITH (nolock)    
    2. WHERE s.Path like '%867bb878-7803-4b19-a8b3-f642b4315e94%'    
  • We will only want to delete the scopes from this result set that are in an unregistered state.
  • Delete only the unregistered scopes, using the same value from @ParentScopeId from 2b above. (If this doesn't work use the below one)
  • I just passed the Web Id instead of the parent scope id (as explained earlier). You could see that the result is “Unregistered”. And you can delete this unregistered scope.
    1. DELETE FROM Scopes    
    2. WHERE Path like '%867bb878-7803-4b19-a8b3-f642b4315e94%'    
    3. AND Status = 'Unregistered'    
Republish
 
I republished all 2013 workflows within the affected sites / subsites and  now it worked :).


Similar Articles