UPDATE: See this MSDN discussion, especially the last entry: http://forums.microsoft.com/MSDN/showpost.aspx?postid=2631057&siteid=1.  It describes a condition that may short circuit this whole thing.  In short, it may be as simple as making at least one of the fields mandatory.

I have a document library that supports eight content types.

I have a SharePoint Designer workflow that wants to calculate and assign a "reminder date" by simply subtracting 30 days from another column, "due date".  This should only happen for one of the content types, "Insurance".  The business objective is to produce a KPI that shows two categories of insurance documents: "about to expire" and "expired."  (You can read more about this kind of KPI and more substantial drill-down here).

I have configured the workflow to fire when a new item is created and when an item is modified.  The idea is that when an insurance document is uploaded, we calculate a "warning date" based on the expiration date.  A pair of views work in connection with a KPI List to highlight these conditions when users hit their home page.

This strategy does not work when I upload a document.

I upload the document and I am presented with the meta data entry screen.  At this point, I’m already in trouble.  SharePoint has already, prematurely from my perspective, fired the workflow.  I haven’t had a chance to pick the correct content type nor assign a due date.  At the same time, the workflow does not fire when I hit the submit button at this time.  There’s some built-in logic that "believes" that first submit is part of the "create" event.  So … my workflow has fired and when it executed, it was passed default meta data values. 

The best work-around I know of is to insert a "pause until" activity in the workflow.  I have the workflow pause for 1 minute.  While it’s pausing, I select the correct content type, enter the meta data and submit.  The pause completes and the workflow proceeds as needed.  (Note that in my environment, timer workflow activities from SPD do not work out of the box.  You may have the same trouble.  See here for more details).

I don’t like "magic delay" work-around.  What happens if the user uploads a document and the phone rings and the ensuing conversation outlasts the pause?  I can make the pause longer, but I still don’t like it.

I wrote about this on the MSDN forums here: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2430725&SiteID=1 

Once or twice month, someone posts a forum question: "How do I include hyperlinks to URL’s that are clickable from a SharePoint Designer email?"

Presented without further comment:  (well, actually there is further comment after the image):

Becky Isserman follows up with a helpful explanation on how to embed a link to an item in the email: http://www.sharepointblogs.com/mosslover/archive/2007/11/20/addition-to-paul-galvin-s-post-about-sending-an-e-mail-with-hyperlinks-in-spd.aspx

Scenario: I have an InfoPath form that front-ends a workflow process implemented using SharePoint Designer.  At one point, a manager must approve the form.  Since I cannot count on workflow history to meet my auditing requirements, I decide to store my own auditing message directly on the form itself.

Overview:

Design the form and publish it as a content type and the form itself to a document library.  Mark desired form fields as being updateable from MOSS.  The form is tied to the content type and the content type is "attached" to a forms library (or many, if you want).  Write a workflow that updates the field.

Specific Steps:

1. Create a document library.  This will hold your InfoPath template.
2. Create a forms library. 
3. Create the InfoPath form.  Include a text field, "Audit Message". 
4. Publish the form as a content type (NOT a document).
5. While filling out the publishing dialogs:
   a) Save the .xsn file to the document library (step #1).
   b) Publish the "Audit Message" field and mark true: "Allow users to edit data in this field by using a datasheet or properties page".
   c) Create a new content type and give it an appropriate name.
6. Access the forms library.
   a) Go to its advanced settings and enable the forms library to manage content types.
   b) Select the newly created content type (5c above).  It will be grouped under "Microsoft InfoPath" (or similar).
   c) Remove the default "Form" content type from the library.
   d) Mark the library to "show as web page" so that the form will launch from SharePoint and not the InfoPath workstation client.
7. Go back to the forms library proper and click "New" to simply verify that the form is posted correctly and acting as you want.
8. Fire up SharePoint Designer and navigate to the site that hosts your form library (from step 2).
9. Create a new workflow attached to the forms library.
10. Add a single action "Set Field in Current Item".  You should expect SharePoint Designer to list your your field, "Audit Message".  Assign it a value.
11. Click Finish and go back to the form library.
12. Create a new form and put some test value into the "Audit Message" field.
13. Save it and go back to the form library.
14. Right-click, select "Workflow" and start up your workflow.
15. It should run almost immediately.  Pull up the form (from step 12) and if all has gone to plan, "Audit Message" has been assigned whatever value you provided in step 10.

Notes:

Not all controls may configured for this bi-directional communication.  For example, it does not seem to implement an SPD workflow that modifies text fields wrapped inside repeating sections. 

One of the key take-away’s here is that we’ve really created a content type with an associated template.  This also enables us to store multiple InfoPath form templates in the same form library.

This requires forms server.  It’s most certainly not going to work in a WSS 3.0 environment and probably even requires an Enterprise SharePoint environment.

UPDATE: This has been released to CodePlex here: http://www.codeplex.com/spdwfextensions

UPDATE: See here for latest release notes: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!381.entry

UPDATE: See here for my thoughts on commercializing this project: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!569.entry

This project provides a custom activity in SharePoint Designer.  Use this custom activity to invoke (dispatch) any C# function that you incorporated into the linked assembly.

As of late October, 2007, this is just an initial version of the project.  I plan to expand it with a number of additional functions, including substring, index, replace, invoking web services and anything that seems useful or interesting.  I also plan to post this to codeplex once I have my act together on that front.  This will also be deployable as a solution at some point.

If you have any comments, questions or suggestions, please leave them in comments or email me.

Disclaimer:

I make absolutely no claims as to the suitability of this for any purpose.  Use at your own risk.

Installation steps (to be followed for each WFE in the farm):

1. Download the .zip and extract.

2. Install the .dll into the GAC.  I usually open c:\windows\assembly using windows explorer and copy it there.

3. Modify web.config to add the assembly to the safe controls:

<System.Workflow.ComponentModel.WorkflowCompiler>
  <authorizedTypes>

<authorizedType Assembly="SpdGenericInterface, Version=1.0.0.0, Culture=neutral, PublicKeyToken=abe076fd8125f3c4" Namespace="Nivlag" TypeName="*" Authorized="True" />

4. Copy "SpdGenericInterface.actions" to C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\1033\Workflow

Note that the above location is specific to english language installations.

5. Close SharePoint Designer (if it’s already open).

6. iisreset

7. Open SPD and create a new workflow.

If all goes well, you should be rewarded with a new category of action:

Notes:

See here (http://blogs.msdn.com/sharepointdesigner/archive/2007/03/15/adding-activities-to-spd.aspx) for a terrific overview of the process for creating, installing and configuring a solution like this.

The .zip is designed to extract directly to you c:\ drive.  If you do this, you can open the project and all the paths will be consistent.

To use this in visual studio, you probably need to install "Extensions for Windows WF".

The initial upload contains just one "dispatcher function", "ToLower()".  To add more functionality, add it to the Execute method as shown:

 protected override ActivityExecutionStatus
          Execute(ActivityExecutionContext executionContext)
        {

            string functionToDispatch;
            functionToDispatch = this.DispatchFunction.ToLower();

            switch (functionToDispatch)
            {
                case "tolower()":
                    {
                        this.OutResult1 = this.InParam1.ToLower();
                        break;
                    }

                default:
                    {
                        this.OutResult1 = "Unknown function: [" + this.DispatchFunction + "].";
                        break;
                    }
            }

            return ActivityExecutionStatus.Closed;
        } // ActivityExecutionStatus

    }

Then, re-build the project and copy the assembly to the GAC.  I expect an iisreset would be required.

Part of the process for creating a custom action for SharePoint Designer involves create a ".actions" file.

I’ve found and tried to use a sample template which starts off as:

<?xml version="1.0" encoding="utf-8" ?>
  <WorkflowInfo xmlns="http://schemas.microsoft.com/sharepoint/">
  <Actions Sequential="then" Parallel="and">

However, that xmlns attribute prevents my environment from working.  My actions don’t show up in SPD. 

The solution is to strip out the xmlns attribute, do an iisreset and close/re-open SPD. 

Use the "Collect Data from User" action to create and assign a task to a user that prompts them for data.  Among other things, I’ve used it to prompt a user to approve or reject a request and enter some comments.

This action takes the form of:

Collect data from this user (Output to Variable: collect1)

Clicking on data pulls up a series of dialog boxes where you specify what data the user should provide when completing the task and this user is obvious.

The output part (Variable: collect1) saves the ID of the task.  You use this in your workflow to extract the user’s actual response via the "Compare any data source" condition. 

That condition shows as

If field equals value

Click on field and then the f(x) icon and it pulls up another dialog box.  Use this generalized dialog box to to tell SPD two things;

1. What is the list and column whose value you want to compare.

2. How should the workflow engine locate the specific row in that list?

To do this:

1. Change the "Source" dropdown to point at the correct task list.  Note that the dialog box expands to show a "Find the List Item" section.
2. In the Lookup Details field dropdown, select the name of the field whose value you want (this maps to what you called in the Collect data dialog box from above).
3. In the "Find the List Item" section, select "Tasks:ID" in the Field dropdown.
4. In the value field, click on the f(x).  This opens yet another dialog box.
5. Change the source "Workflow Data"
6. Select the workflow variable that matches to the "Output to Variable" from the Collect data action.
7. Click OK/OK and you’re done.

It looks like this for me:

At this point, you can now use that value in your workflow as required.

Additional Notes:

As a brief aside, I always create an appropriately named workflow variable of type "List Item ID" and use that instead of the auto-generated "collect1". 

This "compare any data source" dialog set is used in several different places in SPD and is well worth mastering.

==end