Just a quick observation that there’s a very important difference between these two definitions:

<FieldBind Field="InParam1" DesignerType="StringBuilder" Id="2" Text="Input parameter #1"/>

versus:

<FieldBind Field="InParam1" Id="2" Text="Input parameter #1"/>

The first shows like this in SPD:

while the latter shows like this:

I’m not sure how helpful these screen shots are but I put in the effort to make them so you have to view them 🙂

The observation is this: StringBuilder allows you to build a string (obviously) by mixing together string literals and workflow data (via the "Add Lookup" button in the lower left-hand corner).  When you use the Add Lookup button, it inserts a token in the form "[%token%]".  When SharePoint invokes your custom action, (C# code in my case), SharePoint passes the token itself, not the value of the token.  If you use the default designer type (the second type), SharePoint expands the token and passes actual value of the token to your action.

StringBuilder = BAD, default designer type = GOOD.

Of course, that’s not what I really mean.  Just don’t try and pass a parameter to your custom action when the designer type = StringBuilder.  Use the default  designer type and chain a StringBuilder to it up front if you need to build complex strings in your workflow (which incidentally is exactly what one does to create a dynamic subject for the email action, but that’s a subject for another blog entry, har har).

<end/>