So in the tools post, I talked a bit about what’s inpidually possible with a InfoPath form and workflows within Sharepoint. In this post, I’d like to look at the combination of using both.
A couple weeks ago, I spent about an hour creating a form and workflow and publishing them on a personal site to get a sense for the experience.
For this demo, I tried to recreate C&C’s Petty Cash reimbursement form and approval process. This form currently is a PDF form which you fill out online, print out, and mail to C&C’s Business office, along with a printout of an approval email from one of eight people within C&C. In other words, the existing process is a mix of high-tech and low-tech. I was aiming for a completely high-tech electronic-based process. I’m sure there are additional pieces of the C&C process for this kind of thing that I neglected–I was simply trying for a concrete proof-of-concept. So as I write about this topic, I’ll add concrete details based on that experience, and I’ve taken a few screenshots to give you an idea of what things look like.
As noted in that prior post, Infopath is both a forms creation tool and a tool for filling out forms, but you can browser-enable infopath forms so clients can use their browser to render and fill out the form. This feature requires Infopath 2007 and the Forms Server component which comes as part of the MOSS enterprise version (you can also get Forms Server as a standalone component).
Infopath has some sample forms you can use as templates. And so I initially tried starting with the ‘expense report’ sample and customizing it. However, I found that there were assumptions nested within the sample that broke as I customized the form. And initially I didn’t know enough to be able to remove all the assumptions to fix the things I was breaking. So I ended up starting with a blank form, however, that didn’t seem to increase the difficulty level. Designing the form was rather simple, with a design task bar that holds all the basic options you’ll likely want. I inserted a table layout, added text box controls, date pickers, a repeating table (for adding an infinite number of itemized expenses), and a button control. I formatted the various text boxes appropriately (some needed to be a decimal data type with a currency formatting), and for some text boxes I put in a default value. On the C&C form, the requestor can be someone other than the claimant, so I made the default value for the requestor’s info be the values from the claimant text boxes. So for the general case where the claimant and requestor are the same, the end user only needs to supply that information within the form once. For the phone textbox, I added a data validation to ensure that input looked like a valid phone number. I did something similar for data validation with the email textbox. For the data textbox, I created a rule. This rule always fires, and has a function which sets today’s date. So that field gets auto-filled out. The experience for creating the rules was similar to that within excel using functions and formulas, i.e. very simple. I could have set the default value as today’s date instead, but I decided I wanted to see how rules worked. Within the repeating table of itemized expenses, I created an total expenses textbox which didn’t accept any user input. Instead it sums all the inpidual expenses. Again this was done using an excel-like formula experience. I also had a textbox for the amount to be reimbursed which defaults to that total expenses value. But the user can override that default value, because they might not be entitled to claim reimbursement for the full cost of some of the items. Finally, I titled the button “submit”. Prior to publishing the form to Sharepoint, I was unable to actually configure the sharepoint-specific actions associated with the button.
Here’s what the form looked like within InfoPath after I was done:
Once you’ve got a form created, Infopath allows you to save and/or publish your form. You can save it to a file location or to a sharepoint document library. However, the best option is to publish the form to a sharepoint site collection as a new content type. You specify the site collection as the destination for publishing, then choose to create a new content type for your form. The reason this is preferred is three-fold:
- the form doesn’t show up as an editable item within a document library, and
- the form can be used on any list logically under that site collection–so it’s more widely usable
- the end-user experience for starting to fill out a new form makes more sense via this method–from the new menu of the list the user chooses to create a new item of that form content type, instead of opening the saved infopath document and saving it as a new file within the document library
One of the important pieces in the publishing step is to enable the form to be browser-enabled.
So once you’ve published the form as a new content type, you now enable the content type for the sharepoint list within that site collection where you want the forms to be filled out from. That includes the following two steps:
- From the list > Settings Menu > List Settings > General Settings column > Advanced Settings > Allow management of content types=Yes
- From the list > Settings Menu > List Settings > Content Types section > Add from existing site content types > select and add new content type
So at this time, the new form content type you’ve added should have resulted in an item on the new menu, like so:
Once the form has been published to Sharepoint, back in Infopath you can now configure the button action to be submit, and to submit to the sharepoint server. And of course, you need to republish the form again, overwriting the prior version (i.e. the prior content type).
There are a couple gotchas here on the sharepoint list which are probably worth mentioning before moving on to workflow. First, each list needs to be configured to allow browser-enabled documents–this isn’t the default setting. This is the server-side piece of enabling that infopath form to be rendered within a browser. That’s at:
From the list > Settings Menu > List Settings > General Settings column > Advanced Settings > Opening browser-enabled documents=display as web page
And now that we’ve done that, you’ll be happy to see below my form rendered in a browser–and not in IE even, in Firefox:
Another gotcha is ensuring that your end users have permissions to see and create new items in the list. This may or may not be an issue depending on where the list is in the overall sharepoint site hierarchy.
Moving on to Workflow …
So WSS comes out of the box with a single workflow, Three-State, while MOSS comes with:
- Collect Signatures
- Disposition Approval
- Translation Management
You may not see all of these workflow options depending on what features have been enabled in the sharepoint farm, and parent site collection.
I chose the Approval workflow, although I suspect a custom workflow might more closely mimic the existing process. Basically, any given C&C person would want to target their director as the initial approver before sending the form along to the C&C Business office. The default Approval workflow only allows you to target a static list of approvers, so that’s not an exact match, but it’s what I went with. I’ll probably investigate custom workflows in the near future.
Anyhow, adding the basic workflows is rather simple (we’ll get to the steps shortly), but you do have a choice of where to configure the workflows. Assuming you’ve added your form as a content type, then you can choose to associate the workflow with the content type. This means that all instances of the form across your site collection will follow that workflow. Alternatively, you can choose to associate a workflow at the list level. I’m going to talk about the latter here, but the former is probably preferred. And you can do both (or have multiple workflows at either level), if there’s reason to have multiple workflows.
For list-based workflows, all the relevant steps are at:
From the list > Settings Menu > List Settings > Permissions and Management column > Workflow Settings > Add a workflow
One of the key pieces here is specifying the task list. Workflows usually generate tasks. These tasks are assigned to the appropriate parties, and usually the workflow does not progress until those parties change the status of their assigned task. So you need to be cognizant of what task list you target your workflow at, and communicate that information to the expected approvers. This is a common gotcha–in the context of this form-based workflow, the approvers will get an email with a link to the form, but the form itself has no approve or reject button. There may be some way to actually add approve/reject buttons that perform that task action, but it’s not a default option. In any event, I’d suggest you include the URL for the task list in the email notification message for the workflow.
Out-of-the-box Workflows can be manually started or automatically started based on item creation/modification. You can configure parallel tasks or serially dependent tasks. You can configure due dates for the tasks, permit the approver to be changed by the initially assigned person, and add a cc for notifying other interested parties.
All in all, the out of the box workflows are very easy to setup. I don’t have a sense yet for whether they have a really wide usefulness, or if custom workflows are going to be much more commonly needed.
I’m still learning about what can be done, but the possibilities are very tantalizing, and I figured this post would be widely useful at exposing the kinds of things that are possible.