I just finished building a massive SharePoint feature that provisions a list, adds a web part to a page, installs a workflow, associates that workflow with the list, adds settings to the web.config and encrypts them, and then makes you a sandwich when it's done.

This workflow is automatically kicked off when an new item is added to the aforementioned list. Now I don't know the details here, but it seems as though the first time a workflow instance is kicked off, it adds a field (with the same name of the workflow association, of type hyperlink) to the list that takes you to the workflow tasks for the instance.

However, it only adds this field to the default view. This is a bit annoying, and like I said, I don't know the details, so I don't know if you can turn this off or change it somehow. So, being the stubborn SharePoint guy that I am, I went ahead a did it myself. :)

The SharePoint code I'll share below is fairly straight-forward. The challenge was determining when and where to execute this code. Since we are (apparently) abstracted as to when the workflow creates this field, I had to figure out the right moment I would have programmatic access to it.

The answer is in the "onWorkflowActivated_Invoked" event of your workflow. At this point, the list item for this instance has been created (since this is what activated the workflow) and, after checking the columns in the list at this point, I found that the workflow field was indeed in the list. So all we have to do is add this field to any views we want.

In my case, I wanted it on all views, so the logic is more trivial. Here's what to do:

The _workflowProperties is a member field that WF wires up for you (you can name it anything you want). I iterate through the view collection on the list backwards so I can modify each one on the fly. And finally, make sure to use the internal name of the view field when making existential checks (unlike the display name, like you do for list fields). Otherwise, it could be added to the view twice. I didn't think this was possible, and it looked screwy on the site, and even threw JavaScript errors when using it! Everything else is normal SharePoint code.

(Quick note on field internal names: they are not necessarily intuitive. For Example, "field name" will be something like "field_x0020_name" internally. Also, for these workflow fields, the system will generate the internal name. For example, a workflow association I created was called "Timesheet Approval" and then internal name of the field was "Timeshee" - so be careful! It might be worth your time to write a quick bit to dump the internal names of your list into a text file for reference.)

I know this might seem like a lot of work to do for a pretty specific result, but if you are creating SharePoint features, you need to provision everything precisely the way you want it. Since things are easy to customize out-of-the-box in SharePoint for end users, there is going to be very little patience for "sloppy" features.

Have fun!