Azure App Services and SharePoint 2016

Yesterday Microsoft announced the availability of Azure App Services, a new high-level grouping of services for building apps on Azure cloud platform. According to the announcement blog post:

App Service is a new, one-of-a kind cloud service that enables developers to build web and mobile apps for any platform and any device. App Service is an integrated solution that streamlines development while enabling easy integration with on-premises and SaaS systems while providing the ability to quickly automate business processes.

I immediately saw “On-Prem SharePoint Server” in the list of the available connectors for Logic Apps and API Apps.


Also, SharePoint is visible in the API Apps catalog in Azure, too.

API Apps Marketplace

It has made me think that a SharePoint 2016 could, in theory, use the new Azure App infrastructure to run workflows (now called Logic Apps, similar to BizTalk orchestrations) that span multiple services: SharePoint, Exchange, public and private social networks, data stores and so on. The logic of the workflow would be based in Azure and it would consume the other services through the connectors. The authentication clould be brokered by the Azure AD.

I like the idea. Only the Ignite will let us know how much of the idea holds true.

Detecting a SharePoint Designer Workflow Association

In a recent project, I had to find out which of the workflows in the site collection were made with SharePoint Designer. I did a recursive code that checked in all SPList instances in every SPWeb for the following combination:

  • For each SPList.WorkflowAssociations
    • SPWorkflowAssociation.BaseTemplate == null
    • SPWorkflowAssociation.InternalName.Contains(“Xoml”)

I also checked to see if the workflow association was active (SPWorkflowAssociation.Enabled == true) because the previous versions of the SPD workflows are also stored as associations, but they are disabled.

I hope this little snippet can help you in similar cases. Have a nice coding!

“This form has been closed” and “The specified form cannot be found” When Using SharePoint Default Workflows

A really weird bug with SharePoint happened today.


You have a standard MOSS 2007 Approval or Collect Feedback workflow configured in a document library or a content type. You try to:

  • Open a task created by the workflow
  • Modify the workflow association data of an existing workflow
  • Create a new workflow association

SharePoint displays “This form has been closed” or “The specified form cannot be found” trying to display the form. Sometimes it shows the InfoPath Forms Service message box with the same information.


The standard out-of-the-box workflows have been messed up after their creation, by unknown causes.


Uninstall and reinstall the standard workflow feature, using the following sequence of command line operations:

  • stsadm –o deactivatefeature –name ReviewWorkflows –url YOURPORTALURL –force
  • stsadm –o uninstallfeature –name ReviewWorkflows –force
  • stsadm –o installfeature –name ReviewWorkflows –force
  • stsadm –o activatefeature –name ReviewWorkflows –url YOURPORTALURL

Thanks to Patrik Luca on MSDN Forums.

User Profile Sharepoint Designer Activities 0.2.0

UPDATED 04/07/2012: I had issues with SkyDrive and lost the files but the WSP file has been retrieved by one of the previous downloaders. The link is fixed.
UPDATED 28/08/2008: I released an updated version (0.2.0) that solves a previous bug when choosing the action in SharePoint Designer didn’t add the action to the workflow actions list. Please download the new version if you need to use these activities. The installation instructions have also been revised.
UPDATED 07/07/2008: I finally corrected the issue with the feature activation and web.config modifications. The files for download are updated.
I finally decided to post some useful code for the SharePoint community. I present you the “User Profile related SharePoint Designer Activities“. It’s a solution package (.WSP file) that contains four SPD actions (workflow activities) for the SharePoint Designer workflows. This package is only for MOSS 2007 installations. It will not work on WSS 3.0 machines. (I’m preparing a similar package for WSS).
The available actions are:

  • Get user title – use it to get the user job title, when you need to route the workflow to different people depending on the originating user, for example.
  • Find manager of the user – it retrieves the Manager property of the specified user profile. The most frequent use of this action would be to set an approval task for the manager of the user.
  • Find display name of the user – it resolves the user display name instead of DOMAINusername, useful if you combine text in task descriptions or in emails.
  • Find department of the user – use it to route workflows depending on the originating user deparment or to check that the workflow can only be initiated by a specific department, for instance.



You can download the WSP file here:!1496


The WSP package is easy to install:

  • Copy the EdinKapic.SharePoint.WorkflowActions.wsp file to a folder of your choice
  • Open a command prompt (CMD) with path access to the STSADM tool
  • stsadm -o addsolution -filename EdinKapic.SharePoint.WorkflowActions.wsp
  • stsadm -o deploysolution -name EdinKapic.SharePoint.WorkflowActions.wsp -allowgacdeployment –immediate -allcontenturls
  • If the solution package fails when it tries to register itself in web.config,  you will have to manually add this line to your SharePoint web.config, under the System.Workflow.ComponentModel.WorkflowCompiler / authorizedTypes tag:

<authorizedType Assembly=”EdinKapic.SharePoint.Workflow, Version=, Culture=neutral, PublicKeyToken=968b39d77135aa09″ Namespace=”EdinKapic.SharePoint.Workflow” TypeName=”*” Authorized=”True” />

  • Do not forget to activate the feature “User Profile SharePoint Designer Activities 0.2.0” in SharePoint Central Administration site, under Applications/Web Application Features


I’d appreciate any comments about these actions/activities. Feel free to use the comments feature of this post.

The Legal Mumbo-Jumbo

I release this code under the Ms-PL (Microsoft Public Licence).

How to Optimize SharePoint Designer’s Use of Content Types in a Workflow

I’m annoyed by many little details of the SharePoint Designer Workflow editor, but the main one is that it profligates in the creation of content types. It creates one content type for any custom form that you create when collecting data from a task. Moreover, it doesn’t give you the chance to reuse an existing type….every new task is a new content type in the Tasks list.

However, you CAN reuse existing content type for the Tasks list. You just have to create the first form as usual and then create a second form with a easy-to-find name such as “DUMMY”. Then, a little bit of manual work follows:

  • Open the XOML file of your workflow with right click, choosing “Open With” then “SharePoint Designer (Open As XML)
  • Find the first “CollectDataTask” action, such as this one

    <ns0:CollectDataTask x:Name=”ID15″ ContentTypeId=”0x01080100AC1C1A96057F4B4897ED6C99E92728F500A85399B392A23943B207F10B3F8BB318″ TaskId=”{ActivityBind ROOT,Path=taskAM}” Title=”CAF Approval 1″ InProperties=”{x:Null}” __Context=”{ActivityBind ROOT,Path=__context}” OutProperties=”{x:Null}” AssignedTo=”{ActivityBind ROOT,Path=userAM}” />

  • Copy the line after the x:Name field
  • Find the CollectDataTask with the Title=”DUMMY”
  • Replace the content of the line after the Name field with the first action copied data

That’s it! Now you can safely remove the DUMMY content type from the Task list and Site Content Types list.