Enhanced Workflow Initiation Forms in SPD – Part II

“I reserve the right to be smarter tomorrow than I am today.”   – Dr. Alexander Elder

Or, as an alcoholic might  say, “I had a moment of clarity”.

It turns out there is yet an easier way of enhancing workflow Initiation forms. In short, all you actually have to do is follow these few simple steps:

  1. Create a new ASPX page in SPD and add a Custom List Form for the list your workflows are associated with. It should be an Edit form.
  2. Open your Initiation form in SPD.
  3. For each field you want to “inherit” directly from your list, simply copy the markup between the <tr> tags delineating that particular Edit form row.
  4. Paste to replace the corresponding field in the Initiation form markup. For example, if you want to use a People Picker field called “Issue Assignee” from the edit form, you will copy/paste the SharePoint:FormField markup into the Initiation form to replace the asp:TextBox field SPD generated from your “IssueAssignee” Initiation form variable (System.String type).
  5. Delete the line of SharePoint:FieldDescription markup.
  6. Now replace the “post as” variable in the __designer:bind attribute of this FormField markup (e.g. ‘@Issue_x0020_Assignee’) with the variable name of your Initiation variable (e.g. ‘@IssueAssignee’).

That’s it, and you can (and probably should) disgard the Edit Form page you built. This is a flexible and powerful way to get around the apparent limitations of SPD workflow Initiation forms. In the case of using a People Picker for example, you do not need the JavaScript driven approach others have shared.

A quick note on the custom content types that may be used in your list. I have found with these process-to-task-to-workflow mappings that it can be helpful to use content types in a hierarchal fashion. That is, using the Item content type as the parent type, but in the opposite way from Type inheritance. Instead of using Item as a base type that you expand into sub-type specializations, you can use Item as a content type containing all your columns. This is of course what Item represents before you enable your list for content types. There are a number of advantages to this approach that I’ll detail in another post, but for this topic it allows you to generate a complete set of list fields for the cases where you use custom content types to “partition” your list fields. If this part of the subject is not meaningful, then you probably don’t care about it right now :-)


About generation12

I am a SharePoint/.NET consultant in the twin cities.
This entry was posted in Customization. Bookmark the permalink.

7 Responses to Enhanced Workflow Initiation Forms in SPD – Part II

  1. machewd says:

    Thanks so much for an excellent post!!!

    This really made my day and project. The people lookup worked perfectly and your post saved me a ton of time and frustration.

  2. vivasuzi says:

    Thanks this is cool.

    One thing you didn’t point out (unless I missed it) is that you have to make sure to ID the new fields to match the ID of the old fields. Otherwise you may end up with duplicate IDs and the form will yell at you.

    I had to change the following items: id=”ff1{$Pos}” and concat(‘ff1’….

    Because when I pasted over the sharepoint tag it had ff2 there which was already being used by the second field.

  3. vivasuzi says:

    I’m having trouble getting this to work with Rich Text Fields. I can get it to display on the form fine using the method above, however when my email sends, that particular field shows ?????. All regular text fields work fine, just not the Rich Text one. Any ideas?

    My current work around is that this field is display only and I tell the users that if they want to change what gets sent, they have to re-write it (which won’t usually happen in this case, but they have the option to). Not a big deal since most users will be fine with the text as is, but just wondering if there’s a way around this or if I am doing something wrong.


    • generation12 says:

      Email me at rramirez@digineer.com There are 2 field rendering types and 1 storage type (that corresponds to the SQL type for the column in the AllUserData table in the Content DB). You have the field working in Edit mode in the form, but I believe the storage type has to be changed. I’m too busy at the moment to look at this right now, but I’ll email you tonight if you don’t get it solved by this evening.


  4. jspruance says:

    Re step#2 – does this refer to ‘_layouts/IniWrkflIP.aspx’? I cannot seem to open this file in SharePoint designer and unfortunately I don’t have access to the box where the SharePoint site is hosted, so I can’t open it in VS. So is there any other way for me to complete the above steps? Thanks.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s