Creating the Business Card Request InfoPath Form

Business Card Request Demo Files

Back in January I spoke at SharePoint Saturday Virginia Beach about InfoPath forms and Web Part deployment.  Below is some of the information and details regarding the form I created for the session. 

There are many blogs and Microsoft articles on how to create a basic form so I won’t repeat that information here.   This blog will just explain a few of the options I chose when creating the solutions for SPS Virginia Beach.  The above link contains the zipped package files of the two InfoPath forms(no code solution and coded solution), the list template for the Location list I used, and the PowerPoint deck.  If you plan to use these templates, you will need to update the forms to work within your own environments (change data connections, code links, etc.).  Also, you must have the SharePoint Enterprise version, with InfoPath Services configured in order to use the Web Browser enabled forms.

So what are the requirements for this template?
Business Card Request Form Template Design Plan:

  • checkGather user information and requirements for card
  • checkPull in as much user information as possible.
  • checkUse data from the user profile web services as a data source
  • checkShow and hide fields as necessary for requirements
  • checkCreate multiple views – one for those submitting the form and
    checkAnother view for the executive assistants placing the orders.
  • checkBrowser based form integrated into SharePoint team site
  • checkSubmitted directly to form library

The base form was created using the blank template.  The table and rows were added using Insert tab and selecting Custom Table.  The use of tables is a great way to make sure everything lines up.  You do have to split the tables from time to time.  If you’ve ever split cells and then tried to re-align one to find that you impacted the others, you know why.  Here is what the base form looks like in InfoPath.


Show and hide fields as necessary for requirements
You will notice I also used Sections within the form.  These show or hide depending on options selected or whether or not fields are blank.  This is a great way to prevent your users from feeling overwhelmed with a large form (this one wouldn’t apply).  Although not used in this one, you can also use various views with a tab interface.  I’ll show that in another post.

  • Gather user information and requirements for card
  • Pull in as much user information as possible.
  • Use data from the user profile web services as a data source
  • Utilizing rules you can load data when the form initiates (Data tab, Form Load).  Anything you can automate is always appreciated by the user as that is data they don’t have to enter. 
    For example, loading their user id or other user information on load:


Always keep in mind though how much data you load and the method for loading that data (through rules, code, etc.).  They have an impact on form performance.  The form will take longer to load if you bring in a ton of data from external sources.  Laura Rogers has a great blog post on using the User Information List to load user information.   If the user has logged into SharePoint, then this can be used quite effectively and without a huge performance hit.   What I have found is that using the User Profile service via code behind or the Web Service “GetUserProfileByName” (as above) can take more time to load the user data.  Just food for thought.

You must add the data connection in order for the above rules to work.  You can connect to the data connection through the Data tab, Data Connections or select Manage Data Connections link which appears under the main data source.  The data connections can be SharePoint lists or libraries, SQL data tables, XML files, etc. 

Create multiple views – one for those submitting the form and
Another view for the executive assistants placing the orders.
You can also create multiple views for the users to enhance their experience.  Once they’ve entered the information and submitted their request for business cards, they don’t really need to see the main data input screen any more.  They just need to view what they entered.

From the Page Design tab, select New View and give the view a name. 

To review the existing views, click the down arrow under View:

The ReviewView shows just what the user needs and nothing more:

Once you have everything configured, the form should be tested within a Test SharePoint environment before final deployment to production.  This validates you don’t have any rules or code that could impact the server negatively.

Submitted directly to form library  
You will need to know the form library that you will be submitting to when publishing the template.  Configure the Submit data connection to connect to this library.  There is already one configured in the sample,  but it will need to be updated to your environment prior to publishing.

The Design template is different from the Published template.  While both have the .XSN extension, the published template contains all the “package” information for the form.  The published form is what is loaded into Central Admin, not the design template.

Browser based form integrated into SharePoint team site
In Central Admin, under General Settings, select Manage Form Templates.  Upload the published form template and Activate it to a site collection.
Now it is available as a content type to select in the form library. 
Some documentation on publishing form templates: 
Technet – Manage administrator approved form templates

And that’s all our base requirements.  Hope this helps to give a good start. 

InfoPath 2010 Form Design and Web Part Deployment

In January I had the pleasure to speak at SharePoint Saturday Virginia Beach.  I presented a session on InfoPath 2010 forms design which included some of the basics of Forms Design, description of some of the new options with InfoPath 2010 and SharePoint 2010, and other integration possibilities.  Included below is the information presented:

First thing you need to understand is what the difference is between an InfoPath List form and a Form Library Form? 

SharePoint List Forms:  Store data directly in a SharePoint list.  Each control (e.g. text box) in the form is bound to a column in the list. SharePoint list forms are directly connected to the list, which means that you don’t have to worry about setting up the publish and submit locations. You also do not have the option for back-end code.

Form Library Forms:  Store data in XML files in a SharePoint form library.  This means they are more flexible and you can do more with them.  For example, they can be configured to save drafts and submit to different locations. However, they are more complex to work with and require more decisions to be made during configuration.  You do have the option of back-end code with these type of forms.

Next steps:

You need to create your File Architecture Plan. 

  • Plan the location for the saved template – both Test and Production (This is pretty much a given, but just in case - Always make sure to have a test environment)
  • Plan for the location of the published template

Then you need to document your Form Template Design Plan.  Some questions to ask to gather your requirements:

  • What will the form be designed to do?
  • Will it gather user information?
  • Will it display data from a data source?
  • Do we need to show different views to different
    users? What do we base this on?
  • How will it be implemented for the users?
  • Browser or Client based form
  • Site collection content type – Published through
    Central Admin
  • Form Library – Published directly to form library

So what are the requirements for this template? 
Business Card Request Form Template Design Plan

  • Gather user information and requirements for card
  • Pull in as much user information as possible.
  • Use data from the user profile web services as a data source
  • Show and hide fields as necessary for requirements
  • Create multiple views – one for those submitting the form and
    another view for the executive assistants placing the orders.
  • Browser based form integrated into SharePoint team site
  • Published directly to form library

The form was published through Central Administration and incorporated into the site as a content type.


Utilizing the new InfoPath Web part, the form is integrated into the page and the users can complete the form directly from within that page.


For now, if you are interested in the final form XSN, contact me using the Contact link above.   I will post soon with the details on how the form was created and how it integrated the requirements detailed above.

A new day has dawned in my SharePoint world.

Until I started working with SharePoint, I never thought I would be blogging.  I am usually a pretty private individual, but this thing called the SharePoint community pulls you in and makes you feel like you should be a part of it, contributing to it and giving something back.  So here I am blogging for the first time – and so begins my tale.

I started my work life as a Systems admin, but was given a chance to start working with SharePoint 2007 back in - ironically enough - January of 2007.  It has been downhill from there or uphill depending on your perspective!  I jumped in with both feet and haven’t looked back.  Lucky for me Microsoft gave us a new version to work with.  A new job a couple years ago gave me the chance to work with that new version.  Now I spend my days weaving a tale of SharePoint for a Sales based organization.

So why this blog?  To give something back.

I spend most days toggling between administration, InfoPath, Branding and design, HTML, JQuery, and XSLT depending on the need.  The blog will detail these projects and solutions as best I can.  Hopefully they will be of use to someone who may be trying to accomplish similar things, just as many of the blogs that I have referenced over the last 5 years have been a huge help and resource for me.