Stump the Panel » Site Managers and Site Collection Managers

Why publish infopath as Forms vs Documents Vs content types

(7 posts)

  1. GeorgeW
    Member

    OK We have a MOSS 2007 site, and from a design point of view it's a confusing embarrassment of riches. This site is a great source for the 'why' of things, so here goes my long-winded question:

    IF I am trying to integrate an existing paper form into a Sharepoint site with Infopath 2007 -- and there are various ways of 'publishing.'

    In one case, I want to call a web service to fetch Manager's name, so I'll need an administrator-approved form to do that. BUT

    Do I create a forms library or a document library? Which do I choose? and Why?

    And when would I create a content type instead of either of the above?

    And what kind of library would best be suited for a content-typed infopath form?
    Why?

    I'd appreciate some advice on the different cases under which one is better (or worse) than the others.

    -----------------
    And if the form need not be administrator-approved, does that change the decision?

    Posted 3 days ago #

  2. dwinter
    Member

    I'm a little confused by the way you have laid out your questions. It would perhaps be more helpful if you noted what your requirements were for each of the things you are trying to figure out. Then we could provide some more directed guidance.

    None-the-less, document libraries are useful for holding any sort of file. You can think of them as being a bit more of a generic dumping ground for files.

    Forms libraries are specifically catering to utilizing the InfoPath shared service. While it is true that you can wire up a specific form template for a specific purpose, the reality is that a Forms library simply is a place where you would ideally want to organize InfoPath forms.

    In an effort to not confuse you shorter, I'll note that each library can have a default template for the content type the library is created with. You can enable advanced content type management though, and associate multiple content types (existing or custom) to your list. In other words, you could have a Pages library, and add the Form content type, and be able to create both pages and forms in that single list from the New action menu. I guess my point here is that it is all quite flexible, and in the larger scheme of things, you need to think about how you want to organize your data. Most folks don't want to just dump everything in one folder on their hard drive--and this is no different. Governance of data can be a very complicated topic, but the best first step is simply to start thinking about it. Hopefully my ramblings haven't further confused you, but rather given you some additional curiousity.

    Posted 3 days ago #

  3. GeorgeW
    Member

    DW:

    Thanks for the reply. Yes, the confused layout of the question reflects the confusion of the asker.

    But I think you cleared one thing up, when you state: [a] "Forms library simply is a place where you would ideally want to organize InfoPath forms." Meaning that several forms 'live' there as templates, empty -- or forms with their data?

    Posted 1 day ago #

  4. bhorner
    Member

    I believe he was referencing that as a place for filled out forms but it also holds a single content type of an infopath form so that you can have a form library for a specific form where users will click the "new" button as well as submit to this library. Publishing as a content type will allow you to use multiple forms in a single library (for the "new" button) or in document libraries. Basically, it comes down to where you want to break up your different forms...either you can place them into larger chunks with several forms per library or a different form library per form.

    Posted 23 hours ago #

  5. pagalvin
    Moderator

    You would normally publish infopath forms as content types, even if you intend to save all of those forms in one and only one library. I don't think there's any drawback to it. On the other hand, if you do want to re-use the form somewhere else, it will be easier as a CT.

    I personally always create forms as CTs.

    Posted 22 hours ago #

  6. GeorgeW
    Member

    Paul:

    Creating forms as content types sounds like good practice. And I like the idea of having a 'forms library' for these structures to live in.

    But this time-off form reads from a web service, so it must be administrator-approved. That uploading step ITSELF seems to make the form available as a content type--. Meaning that I can create a doc library and when I enable management of content types to it, I can make it an available content type for my new library.

    Does that mean I don't need the step(s) of saving it as a content type or as a doc library? Or is it less work to do it those two steps first ?!?! -- publish as content type first, to get the promoted fields registered as site columns in the content type, then doc library, to get the columns created in an actual library, and the form set as its default, and then upload to the Form Templates Library to permit the web service calls?

    And what happens to my 'Submit to'.. data connection? In the original form, I have a data connection that submits the form to a library. It's hardcoded to go to 'Time Off Forms Library'. Suppose Jupiter Branch and Mars Branch want their time-off records separated? How's that easily done? Since it appears to require a change to the form itself, will I need 40 forms for 40 branches?

    G

    Posted 21 hours ago #

  7. pagalvin
    Moderator

    I'm a little outside my comfort zone, so take what I write with a grain of salt.

    As for administrator approved forms - yes, I believe that those are reusable throughout the site collection because they are, in fact a CT in the end, with their own template (the form itself).

    You made a comment that since the form makes use of a web service, it must be administrator approved. That's not true. A form can make use of a web service, through a data connection, without being administrator approved. There may be very good reasons to require it from a business process perspective, but it's not technicallyo required.

    As for multiple submit-to destinations -- you definitely don't need 40 different forms. Worst case, you need 40 different data connections and painful rule that specifies where to submit the form. I believe I saw a series of blog posts (or at least one) by Sahil Malik (SharePoint MVP) who explained how to dynamically change the details of a submit-to destination at run-time.

    Alternatively, you can have the form submit to a single library and then use views, audience target, security, etc. to help the 40 different groups find only the forms that they need to find.

    If you're going to get heavily into infopath forms dev, I suggest you pick up a book (there's at least one on this topic) and consider posting to the MSDN forum for InfoPath, in addition to here. That link is: http://social.msdn.microsoft.com/Forums/en-US/sharepointinfopath/threads

    Posted 1 hour ago #

RSS feed for this topic

Reply

You must log in to post.