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!

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.