How Sharepoint Stores And Serves Infopath Forms For Workflows
What Are InfoPath Forms?
InfoPath forms are forms that are designed and published through Microsoft’s InfoPath designer tool. They provide advanced form design capabilities such as data validation, conditional formatting, rules and calculations, and integration with databases and web services.
When published to SharePoint, InfoPath forms enable robust forms scenarios that harness SharePoint workflows on the backend. Key capabilities provided by InfoPath forms in SharePoint include:
- Advanced forms design with validation, formatting, and logic
- Initiation of workflow processes upon form submission
- Extraction of submitted form data into workflow variables and logic
- Mapping of columns at submission time from the InfoPath form to SharePoint
By leveraging these capabilities carefully, businesses can optimize complex business processes powered by SharePoint workflows of approvals, reviews, risk assessments, document handling, and more.
InfoPath Forms Architecture in SharePoint
When an InfoPath form is published to SharePoint, the actual form template (.xsn) files are stored in SharePoint document libraries. However, upon submission, the data entered by users is stored in SharePoint content databases rather than documents.
Specifically, the user-submitted form data gets stored in XML format across multiple tables in the SQL Server database backing SharePoint. This includes the core form data, attachments, form metadata, comments, workflow state, and more.
Storing the dynamic user data separately from form templates enables better performance. Form templates can be cached site-wide upon first access since they rarely change. Meanwhile, separating user data facilitates managing each form submission as a unit with associated metadata.
Submitting and Processing Forms
When users fill and submit InfoPath forms in SharePoint, they interact with a webpage representation of the underlying form template. The InfoPath Filler browser plug-in renders the form, applying any formatting, themes, and client-side logic included.
Upon clicking submit, in the background SharePoint receives an HTTP POST request containing an XML representation of the user-entered data. SharePoint disassembles this submission into multiple tables and columns in its SQL Server content database.
Simultaneously, submission triggers activate any workflows associated with the form library or item. Workflows can reference data from the submitted form dynamically and apply business logic around it.
Accessing Form Data in Workflows
Within SharePoint workflows, submitted InfoPath data is accessible in a straightforward way for use in business logic.
For example, referring to a field named “RequestAmount” text box control from the form would look like:
workflowProperties.InitiationData.FormData.RequestAmount
Full XML contents submitted get passed into the .FormData property. Individual controls are accessible through dot notation specifying their names.
Here is some additional example code for common operations within workflows:
- Get single field value: workflowProperties.InitiationData.FormData.RequestAmount
- Get attachment: workflowProperties.InitiationData.FormData.Attachments
- Loop through repeating table: workflowProperties.InitiationData.FormData.GroupMembers
- Calculate total value: ParseFloat(workflowProperties.InitiationData.FormData.LineItems.[Amount])
The submitted XML gets parsed and translated into constructs usable by the platform workflows engine.
Managing InfoPath Form Lifecycle
A key aspect of InfoPath forms is the ability to update and republish templates while retaining user data submitted into previous versions. This facilitates iteration on forms without disrupting business processes dependent on them.
After editing a form template and incrementing the version number, uploading the .xsn package enables mapping old and new fields. Any data gets carried over and matched up with the updated template based on those mappings.
Behind the scenes, the platform handles translating the submitted XML data between the old and new underlying form schemas to maintain a complete end user form data history.
InfoPath Form Considerations
While InfoPath provides compelling and user-friendly forms, the complexity can cause issues at larger form publishing scale. Each form template gets compiled into managed code behind the scenes, which can strain server resources.
InfoPath also lacks native mobile support. Form code and data ultimately still reside within SharePoint, requiring customized solutions for surface areas beyond desktop browser access.
Given these constraints, InfoPath form use cases depend greatly on the specific business needs. They excel for modular departmental processes with dozens of active forms. But for org-wide systems of record or mobile accessibility, alternative options built purely on SharePoint lists workflows may suit better.
