Part 1 of the series is here.

I want to talk about some of the constrains and requirements that Groove has when using InfoPath.

There is one point of potential confusion that is worth addressing up front though, which is the use of the term "view". In Groove Forms terminology, we use the term "view" to describe a custom aggregate list view of a group of form records. InfoPath generally works with a single form, and uses the term "view" to refer to alternative presentations of a single form. I'll try to be clear about which usage I'm referring to as I talk about the two tools.

Below are the requirements on InfoPath solutions that can be used within Groove. On import, the Groove InfoPath tool scans the imported solution and issues errors and/or warnings if the solution doesn't conform to Groove's requirements. Errors are fatal and mean the solution cannot be imported. Warnings are informational and can be ignored, though they warrant further investigation since you need to understand whether the issue will actually cause problems. I've tagged the requirements below according to whether failure to comply results in an error or warning on import:

• Error: The template must be configured to use "submit to host environment". This allows the Groove InfoPath tool to intercept the submit event and store data documents in the Groove InfoPath tool for dissemination to other endpoints.
• Error: The template must use the InfoPath "restricted" security level. This is required because the Groove Forms tool(s) are sandboxed by design. It should not be possible to use the InfoPath tool to go outside this sandbox, and the InfoPath "restricted" security setting is required to ensure this. Note that this implies that InfoPath templates that use managed code cannot be used within Groove, since InfoPath 2007 requires templates that use managed code to use either domain or full trust security.
• Warning: Some InfoPath field types can not be used for promotion in Groove, and will result in a warning on import. The main reason for this limitation is that Groove uses typed fields in records to store promoted fields, and needs to be able to maintain full fidelity during both promotion and demotion (more on demotion in a future post). On import, any fields that cannot be imported within Groove will be ignored and a warning message will be displayed listing the fields that could not be promoted. This means that although the fields can be used in the InfoPath form, they will not be promoted when in Groove, and so cannot be used as a column in a (Groove) list view. The Groove online help has a table that describes which field types can be promoted.
• Warning: The template should not depend on secondary UI such as a custom task pane, or menu or toolbar integration. Groove does not provide any of this functionality when hosting InfoPath, and will issue a warning message on import if it detects that the template uses it. This is one area where you should seek to understand the warning. If the template is dependent on UI elements such as a custom task pane, you could wind up with a non functioning tool, since the task pane won't be accessible.

Now that we have some background established, next time we can get to the series punchline: how to choose between the two Groove Forms tool alternatives: Groove Forms and Groove InfoPath Forms.