SharePoint2013 and Workflow Manager 1.0 cancels my workflow automatically. RRS feed

  • Question

  • I recently updated my SharePoint workflow platform to 2013 by installing Workflow manager 1.0

    I made two simple workflows of platform type 2010 and 2013 and publish it to my list, where both of only change workflow status to 'HELLO'.

    1. When i try to start 2010 workflow it works perfectly fine.

    2. when i try to start 2013 workflow

    •  it does not even show start workflow page, just route me back to my list.
    •  when navigate to my workflows page for that particular list item. it shows its internal status as             canceled.
    •  when i click on canceled worflow to get details, it prompt "Something Went Wrong" an            unexpected   error has occurred.

    Point to note is that, its my first workflow of platform type 2013 and its not working.

    How can i resolve this issue??

    Friday, October 9, 2015 9:40 AM


All replies

  • Hi arslan- this is probably due to a permissions issue, which could be due to many things. Make sure you're not running the workflow with a system account and make sure the workflow has the correct permissions to run. See the following links for more info:



    cameron rautmann

    • Marked as answer by arslan0tahir Monday, October 12, 2015 4:27 AM
    Friday, October 9, 2015 2:16 PM
  • thank you very much :)  ..................it worked like a charm by activating "Workflow can use app permissions"
    Monday, October 12, 2015 4:29 AM
  • but there is still one more issue.

    when i click on 2010 workflow status hyperlink, it shows me a page including Workflow information, Tasks,Workflow History

    but when i click on 2013 workflow status hyperlink, it shows me a page saying "Something went wrong , an unexpected error occurred"

    Monday, October 12, 2015 4:43 AM
  • SharePoint is collocated with the Workflow Manager and whether communication between SharePoint and Workflow Manager over HTTP is allowed, the steps through which this configuration is performed are different and are documented here. For the configuration in this instance we are using SharePoint on the same farm as Workflow Manager and communication over HTTP is allowed.

    Configuration on SharePoint is about creating a service application proxy for workflow that has the service endpoint configuration for the Workflow service. This is done through the use of theRegister-SPWorkflowService cmdlet in the SharePoint Management Shell. There is no UI based way of creating this proxy through the Central Administration application.

    Before we proceed to do this however, let’s take a look at a few things. Here, I am using theGet-WFScope cmdlet to view the scope at the root of the workflow service endpoint. Note: In order to get scope details you’d need to know the ScopeUri of the scope you’re accessing. Without knowing what scopes are on the instance, it is hard to know or remember all the URIs. There is no way to list available scopes through existing cmdlets. Here’s a PowerShell script that helps with this.

    When we create a Workflow Service Application proxy, we add a combination of a SharePoint site collection and the URI of the scope in the workflow service that it is bound to. Looking at the above, we see that there is just one root scope at this point with no child scopes.

    Typically, there would not be a Workflow Service Application or proxy on a fresh new SharePoint environment. Because of whatever experimentation I was doing on my trial environment, I already did have a pair.

    This is understandable since I have not made the connection with the workflow service yet. Just so I understood how this was set up, I ran the following from the SharePoint Management Shell.

    Both scope name and service address come up null. Again, since we have not made the connection with the workflow service yet. I have the option of deleting this proxy set up and starting afresh. Just to see how Register-SPWorkflowService would respond to the existence of the proxy, I went ahead without deleting it.

    And it went through just fine. Or so it seems from the silent return on the command above. So let’s verify.

    First, on refreshing the proxy management page on Central Administration

    Splendid. Now to check on the proxy settings.

    Nice. You can see that a new scope called SharePoint has been created and its address has been bound to the proxy. Let’s hit up this URI in the browser for a second.

    Very cool. There is obviously a lot more going on here than when we hit the root scope URI. One thing that pops out is how the security configuration type isOAuthS2SSecurityConfiguration. This is why we used the AllowOAuthHttp switch parameter when running Register-SPWorkflowService. But all that for a different discussion. Next, a quick look again at the root scope.

    Now checking for the scope in question – the one called SharePoint that is apparently connected to the proxy on SharePoint.

    How do we know this is linked to the proxy we were looking at? Notice the GUID in theUserComments property? Compare that with the Id property of the service application proxy that we got above from running Get-SPWorkflowServiceApplicationProxy. But to have the proof of the pudding, let’s go get the “after” picture on SharePoint Designer 2013.

    1.If you are on a multi-server environment and you set up Workflow Manager on an app server, you have to remember that when you use SharePoint Designer, that works with your web server and therefore, in order to make a connection to the Workflow Manager end points, it will need the Workflow Manager client. Make sure you have installed Workflow Manager client on all of your farm servers.

    2. Sometimes, it requires an IISReset on the server just to shake things up and get them connected properly. There are people who have reported not seeing the SharePoint 2013 Workflow option after configuration and come back the next day to find it magically appear. This is likely because their app pools got recycled overnight. Definitely worth a shot.

    Monday, October 12, 2015 5:38 AM