Really simple - I'm wondering if it's possible to pack multiple custom workflows in a single wsp-solution/feature.

I thought I could just create the workflows, and then add multiple instances of elements in the elements.xml, but only one of the workflows is selectable in sharepoint (the first alphabetic I believe)

Is there any way? I would hate to have to create a feature for each workflow :/


To be more specific, what I have is a WSPBuilder w/ workflows project, in which I have a feature, with feature.xml and elements.xml.

Then I have a "WorkflowCode" folder - as supplied by WSP Builder, with 4 different workflows.

In my elements.xml it automatically created a workflow element for my first workflow, looking like:

       Name="CRU Application Class"
       Description="Workflow for creating/editing Application Class"
       CodeBesideAssembly="Elsymboler_workflows, Version=, Culture=neutral, PublicKeyToken=bb4eedb04c635c01"

    <!-- Tags to specify InfoPath forms for the workflow; delete tags for forms that you do not have -->
        <!--     <Association_FormURN>associationFormURN</Association_FormURN>

  <Modification_GUID_Name>Name of Modification</Modification_GUID_Name>

I don't know enough about the parameters and such to tell what is needed and what isn't, but I expected to be able to simply copy/paste this element, and merely changing the name, codebesideclass and add a fresh GUID for the ID, in order to add the rest of my workflows - but this doesn't seem to work?

2 Answers 2


Yes, you can. Just add more workflows and pack them into a single feature. The OOB UI in Visual Studio 2010 should facilitate this nicely.

  • Oh, sorry, I should've clarified - I'm working in MOSS 2007
    – Dynde
    Commented Apr 13, 2011 at 9:15
  • Well, it's working now - even though I didn't do anything else. I guess maybe the GAC just hadn't gotten properly updated or something :)
    – Dynde
    Commented Apr 14, 2011 at 6:24

You can place any number of elements inside one feature, expect some limitations. But this is a bad way of packaging. For workflows you might need a separate packages. it's greatly simplifies upgrading and development.

For deplotyment you can use Activation Dependencies.

  • Why is packaging workflows together "bad"?
    – Kit Menke
    Commented Apr 13, 2011 at 13:26
  • 1
    If you have multiple coded workflows in one assebmly changing assembly version will break all workflows.
    – gandjustas
    Commented Apr 13, 2011 at 13:42
  • Definitely good to know. You could just update the DLL and not update the version number.
    – Kit Menke
    Commented Apr 13, 2011 at 16:29
  • Does this happen with any other code besides workflows? We are about to start using Assembly Versions in solutions with a lot of features/custom class libraries inside them. Would that break too? Commented Apr 13, 2011 at 17:21
  • Any compiled code affected by assembly versioning. But lot of elements binded with code in sharepoint can be simply reprovisoned, expect workflows and webparts. A BindingRedirect solves this issue for webparts. Running coded worflows will fail on changing assemby version, and no builtin mechanism to avoid this.
    – gandjustas
    Commented Apr 14, 2011 at 7:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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