Click here for the first post in this series, and visit us for SharePoint 2010 Training.
The first question you will need to answer before creating your form is whether it will be stored in a list or library. This question is sometimes hard to answer, so we’ll do it by analyzing some extreme cases. Your situation will likely fall somewhere in the middle, so it will be up to you to decide where your case lies on that spectrum.
For our first scenario let’s pretend that we’re working for the IRS. Someone in charge made a deal with Microsoft and our taxes will now be done by saving them in SharePoint lists. For some reason we want to put tax software companies out of business. Our architects already handled the hardware issues that would come from a hundred million people storing their taxes in SharePoint, so we don’t have to worry about that aspect of it at all. All we need to do is decide if we want to use a form library, or just a standard list form.
You may have guessed that we’ll be using a form library, but why? What reasoning drove us to make that decision?
First off, this is an enormously complicated form. Had we chosen a list form, each piece of information would be stored as column data. We’d need thousands of columns to handle every scenario, and many of those requisite columns wouldn’t be used by the majority of people filling it out. We’d be hiding most columns in every single view, and would need to have customized conditional view forms for individual items.
This alone would steer us toward a form library where we get the views for free and only extract the columns that we care about for list views, but what about alternate means of submission? With a form library, we could e-mail enable the list to allow people to fill out their taxes and e-mail them directly to the library. To do the same thing with a list would require custom code on both the form side as well as the “make a new list item” side.
This hints at another reason this scenario dictates that we use a form library: custom code. When you’re filling out your taxes, there are a lot of little things that your tax software is doing for you. It’s checking rate schedules behind the scenes to determine how much you owe. It’s determining if you’re trying to deduct health care expenses that don’t meet the minimum required amounts for deductibility. While some of these examples could be handled with basic validation in a list form, some of the information could be coming from other data sources that aren’t easily reachable from InfoPath.
We could go on for a while with even more analysis pointing to a form library for this extreme case – we didn’t even mention digital signatures, but let’s leave it at that. To boil it down to something more easily remembered and catchy:
Use a library if you’re collecting a lot of data, want alternate submission methods, or need to have custom code running in the background.
Let’s look at another scenario: We want to let people request vacation time through a web form.
What information are we collecting? The employee name, which could just be a lookup to the user information list.We want to know what days they would like to have off, so a start and end date for their vacation. We want to know their department, but we get that from their User Profile information. Maybe we want to know how much vacation time they have accrued? For our example, this is stored in another system and we’ll be looking that up manually when it comes time for approval, as there are currently no software hooks to grab that information via.
So we need three pieces of information: a name and two dates. After we get this information, we might want to have a Gantt view of it to see whose vacations are overlapping. Maybe this only matters by department (so we don’t leave a skeleton crew at an important time), so we pull that column in from the user lookup and have filtered views for each.
Why are we doing an InfoPath form at all? We want the information to be formatted in a nonstandard way, with the two dates next to each other instead of above and below. We also want to ensure that the dates selected are in the future and that the last day is after the first day.
Since the form is fairly basic and we’re using all (or most) of the columns in our list views, we’re doing a custom list form.
Despite what we’ve just outlined, there may be cases where you need to pick the “wrong” sort of form for other reasons, some of which will be outlined in part 3 of this series where we explore the different controls available in the two types of InfoPath SharePoint forms.
In the mean time, feel free to contact us for any of your SharePoint 2010 Training needs.