In this post I’m going to show you how to create multiple views in an Infopath form and to expose the view based off the status of a particular item in a workflow. This is part of the approval workflow I’ve discussed in earlier blog posts. By using views in forms, you can create an approval process where the approval occurs directly on the form.
This post won’t go into great detail about creating the forms and adding the fields. But I will say this:
You will want to have at least three different Infopath views:
- For when the item is first submitted
- For the approver
- After the item is approved & rejected
The way I designed the various views was backwards. That is, I designed the last view first. This made sense to me because this version of the view would have all the fields, including the fields for procurement and approval.
After I created the final view, I then add a new view (in Page Design, New View). I then simply copy and paste the fields from the third view into the new view (the one for the approver) and then delete fields not appropriate for that stage of the workflow. In this case, the approver has no need for the procurement section of the form, so I delete it.
I then repeat the process, ensuring to remove the approver section. Because the new view (the third one) is going to be the view used when an item is first submitted, therefore, no approver fields are necessary.
The only problem with doing it this way is you’ll want to make sure view three is as solid as possible because any change may need to be duplicated manually on the first and second views.
Here’s an example from the Approver view:
And here’s one from the default view (the one used when an item is submitted):
Notice the absence of the approval fields (Approved & Approved Date).
After you create all the views, you’ll need to create the form load rules. The rules determine the view that is displayed to the user. Before we do so, I guess I should mention you need a trigger field. In this case, it’s Request Status. This SharePoint field is populated by the workflow based off the stage; meaning, although it may be displayed on the form, the user cannot change its value.
For this example, we’ll need four possible values for Request Status:
- New Request
- Awaiting Approval
- Awaiting Procurement
In a real-world example you may need more, but these four will get the idea across. The default value should be the first stage, “New Request.” After the request is made, the workflow changes the value to “Awaiting Approval.”
When the item opens, InfoPath needs to know what view of the form to open. Is this a new item or is it awaiting approval?
So on the ribbon bar, click the Data tab and then Form Load (in the Rules section).
In the Rules pane, click New > Action.
In the Details for box, change the name from Rule-whatever to something that makes sense.
Click the default condition so the Condition properties pop-up appears. This is all pretty self-explanatory (if you got this far). Basically, you want the rule to read: Status field is equal to “New Request.”
Next to Run these actions, click Add and then click Switch Views.
Change the View to your default view (in this case, Edit item).
When you are finished, the rule should look similar to this:
Go ahead and create a new rule for the next status (“Awaiting Approval”) in a similar fashion.
When you’ve finished creating the rules, publish the form.
Personally, when I test a form, I leave the ability for users to change the view (in the form toolbar when viewed in SharePoint). This way I can switch views as I test the workflow. When it’s ready to go live, I remove the option to change views. This eliminates any potential confusion.
Also, depending on the number of views in relation to the number of possible status values, it may be more expedient to use Not Equal to when creating the condition. To clarify this point, consider this (non-world) example.
There are two views, but there are five stages of the workflow. One view is showed during the first stage, the second view any time thereafter. Rather than creating five different rules, create one that simply reads:
If Status NOT EQUAL to the first stage
The action would be:
Switch to view: Second View
Basically, if the item is on any stage but the first, show the second view.
You can use views to solve many solutions involving forms. Using a trigger field allows the choice of view to be determined by various stages in a workflow. Using views this way allows you to craft a solution that is efficient for all end users.