This post is part of a series of InfoPath tips and tricks that use InfoPath and SharePoint 2010 ‘out of the box’, no custom coding required. All the articles can be found on the Forms & InfoPath page under SharePoint 2010 Resources. As with all other posts, this is not a complete tutorial and assumes prior knowledge of InfoPath.
InfoPath 2010 has much better support for browser forms and that means you don’t need InfoPath to be installed everywhere to fill out the forms. The downside is the browser. It’s not always the most reliable puppy and it doesn’t come with the built-in ‘autosave’ that peope have become used to with Office applications. It doesn’t come with spell checking either if you’re using IE but that’s a separate IE related gripe.
By default, InfoPath forms being filled out using just the browser will include three options for the user whilst they are filling out the form: Save (saves the form), Close (closes the form, will prompt the user if the form hasn’t been saved), and Submit (saves and closes the form).
Whilst you can leave these buttons showing on the form and let the person filling in the form do manual saves, the alternative approach is make the process part of the form instead. This can have a number of different benefits, such as including automatic saves periodically to avoid losing data.
Data Connections
To be able to submit a form, you need at least one data connection configured to submit data. If you haven’t already created one, it will be part of the process when you go to publish your form design. This post assumes you already have sufficient knowledge of InfoPath to have figured out how to create data connections and publish your form design.
Form Options
The form options control what buttons are visible by default when a user opens the form. You can configure the settings for the web browser and for the InfoPath Form Filler (client application alternative to the web browser). They are accessed by going to the File menu and clicking on the Form Options button.
The options should be self-explanatory. For simple forms, I remove the commit options and often the Views section too, controlling the form through its design.
Submit Options
Also in the File menu of InfoPath, you can configure the Submit Options for the form, i.e. what happens when a user clicks the standard Submit button.
Your default submit data connection should be selected and in many forms, there will be only one. Click the Advanced button and make sure that ‘After submit:’ is set to close the form. You can also choose to configure the message after the Submit button is clicked. An alternative is to control where the user ends up after clicking the submit button, for example landing on a page that confirms the form was submitted and provides next steps. That is all done within SharePoint and not for this post…
One important note about your default data connection. If the form will be edited more than once, the data connection used for Submit Options must be configured to overwrite when it is saved, otherwise the form will error and not be saved more than once. It is also important that you have an automatic file name convention in use, to ensure all forms have a unique name and do not overwrite each other.
So with a data connection or two, the form options and submit options configured, we’ll look at three different scenarios for building automatic saves in to your form.
Scenario 1: Submit button in the form.
This is the simplest scenario. Add a button to the end of the form and configure it as a Submit button, i.e. it will behave exactly the same as the Submit button we just removed from the Form Options. You would typically add this button to the end of your form as the final step - to submit and close the form.
In the image above, I have added a button to the form and set its properties. Note that the button Action is Submit. This action will follow the Submit Options configured in the File menu. And this is one of the areas where InfoPath can get confusing. You can see the Submit Options button on this button dialogue box. It would be easy to assume that you are configuring the options just for this button. But you aren’t. It takes you straight to the same Submit Options you can access via the File menu. Making a change here will affect all buttons configured to use the Submit action (e.g. if you are still displaying Submit on the toolbar configured under File Options).
Also, to add to the confusion, you can change the button label. A button using the Submit action may not be called Submit. A button called Submit may not be using the Submit action…
Scenario 2: Save button in the form.
In this scenario, the initial steps are the same – add a button to the form. However, instead of configuring the button to use the ‘Submit’ action, we will configure the action to be ‘Rules and Custom Code’ instead. This allows us to build up a set of rules to control what actions occur. The easiest of which is to just save the form but not close it – this enables you to create periodic automatic saves whilst the form is still being edited. Recommended for long forms or forms with sections containing large paragraphs of text.
To demonstrate, we will use a sample from a previous blog post: One form, multiple views. In that post, we created a picture button and used it to switch views when clicked. This is a good way of breaking down a large form into multiple pages (views).
A simple addition, to build in automatic saves, is to add to the rules for our ‘Next’ button:
- Click on the button or image you are using to switch views
- In the Manage Rules task pane, you should already have one rule configured – an action to switch view. We are simply going to add another action.
- Next to ‘Run these actions’ click Add and select Submit data.
- In the Rule Details dialogue box, for the Data connection, make sure you have selected the correct data connection (if you have more than one).
- Finally, you need this action to run first, before the form switches view. So move the action up above your existing ‘Switch to view’ action.
- And that’s it. The form will now be saved when the user clicks the button/image to switch to the next view.
In the image above, you can see the Rule Details for the ‘Next’ image button on my form.The rule to switch view will first submit the form (save it) and then switch to a different view.
This is another area of InfoPath that can cause confusion. Whilst the action is called ‘Submit data’, it does not behave in the same way as the ‘Submit’ action used in Scenaro 1. The default Submit Options are not applied. It simply submits – saves – the form using the selected data connection. If you also wanted to close the form using rules, there is a separate action to close the form. This approach is very useful for more advanced forms, where you can build in validation checks and status updates as part of the submit process.
Scenario 3: Save automatically to capture key data
The third scenario we will cover in this blog post is an expansion to a previous blog post: Assigning a unique reference number. In that post, we use a data connection to retrieve data and automatically calculate a reference number for the form. As one quick commenter spotted, the risk with the method is that two forms are opened at the same time, each will calculate the same reference number. Here’s how to prevent that happening.
To create a unique reference number when a new form is filled out, instead of putting the calculation straight into the refNo field as its default value, we will use a rule to calculate the field’s value and then immediately save the form. We will also use a data connection configured to not overwrite files as an additional precaution.
To do this, you need to create a second data connection to submit data to the SharePoint library. This data connection must be absolutely identical to your default submit data connection with one exception – uncheck the box to prevent files being overwritten.
In the image above, you can see the three data connections I am using for this example. Retrieve ID is a retrieve data connection, to get the ID values from the SharePoint list used to calculate the next reference number. SharePoint Library Submit is my default submit connection which is configured to allow overwrites – i.e. it can be used repeatedly throughout the form. The ‘Save after assigning reference number’ submit data connection will only be used once. It has been configured to not allow overwrites so if two files try to save at the same time, one will suceed and one will display an error message. It would be a rare occurrence but eliminates the risk of one form overwriting another or being given the same reference number.
With your second data connection ready, the next step is to create the process for calculating a reference number and saving the form.
- Click on the refNo control in your form and clear its default value or change the default value to text such as ‘TBA’. Leave the control on the form set to read only.
- Add a button next to your refNo field. In it’s properties, set the action to ‘Rules and Custom Code’ and set the label to something like ‘Click to allocate reference number’
- Click on the button and, if it’s not already displaying, open the Manage Rules taskpane
- Click New and select Action. Give the rule a name such as ‘Assign reference number’
- It is important that clicking the button will only calculate the reference number once. So we need a condition. Set the condition that the rule will run when the refNo field is equal to whatever you set the default value to.
- Next to ‘Run these actions’, click Add and select Query for data
- In the Rule Details dialogue box, select your Retrieve ID data connection. This will ensure the latest ID in use is retrieved.
- Next to ‘Run these actions:’, click Add again and select Set a field’s value
- In the Rule Details dialogue box, select the field refNo and next to the Value box, click the fx button. Enter the same calculation you used for the original post to calculate the unique reference number. Click OK to complete
- Next to ‘Run these actions:’ click Add again, this time select Submit data
- In the Rule Details dialogue box, make sure your ‘Save after assigining a reference number’ submit data connection is used. This one will ensure that the form does not overwrite another. Click OK
- And that’s it*. We now get the user to initiate the calculation for assigning the unique reference number and automatically save the form as soon as the calculation complete.
In the image above, you can see the three actions used to query the information needed for the reference number, setting the refNo field value by calculation – adding 1 to the largest ID retrieved, then immediately saving using our special data connection that will not overwrite an existing form.
*An additional tip. To make sure that the user clicks the button to assign a reference number, you could add a validation rule to the next field and pop up a message if the refNo is still set to ‘TBA’. More useful, I disable all other save options and add a note to the form (you can see an example in the image above). The Next button has been configured to save and then switch views (configured for Scenario 2). In Scenario 2, we left the condition as empty, save and switch views whenever the button is clicked. Instead, add the reverse condition to the ‘Assign a reference’ button. The Next button will only work if the refNo field is not equal to TBA.
Wrap-up
So there you have it. This is one of the most important tips to consider when using browser-based InfoPath forms. Save early. Save often. Hopefully this post has also shown the value and power in using rules to control how and when that happens within your form.
A final tip. We could build automatic save points throughout the form without requiring the user to do anything. For example, in the sample form used for this post, we could automatically save when the user selects a product. The benefit of getting the user to click something like a button is setting expectations. When buttons are clicked, we expect an action to complete immediately but don’t worry if there is a bit of a delay. However, if rules are triggered automatically in the background as we navigate through fields on a form, users may worry if one field causes a delay and may start trying to refresh the browser or other actions that won’t help them. Even if you don’t need the button, it’s a useful approach to design for web forms that may be accessed over unreliable network connections.
