Form Control Names and Schemas 

When you create a flow,  creates an XSD schema of the flow that combines all the fields in all the forms in the flow. For example, if you go to the Flows home page and click  to download or open a flow's schema, you'll see that it contains elements for all the controls in each form in the flow.

When designing the forms you want to use in a flow, be aware that if controls in the different forms have the same name, their data will merge in the XML document that  generates when the flow runs and is submitted. While the Form Designer automatically prevents you from giving two controls the same name within the same form, it doesn't prevent you from giving controls in different forms the same name.

For example, suppose one or more forms in a flow have a text control named FirstName. On one form, this might be an employee's first name; on another, it might be a manager's or customer's first name. When the flow runs and is submitted, the two first names will merge in the resulting XML file. To avoid this, you should give the fields unique names — such as EMPFirstName' or MGRFirstName' — so they'll be separate elements in the flow's XSD schema and separate pieces of data in the submitted flow's XML file.

Another way to avoid data merging is to "nest" controls with the same name within Section controls (which control nesting) that have different names in different forms. For example, suppose you have one form with a Section Control named Employee' that contains a text field named FirstName. A second form has a Section control named Manager that also contains a text field named FirstName. If you use both of these forms in a flow, the FirstName data does not merge because the two controls are nested — at the same level — within Sections that have different names.

See Section Controls in Designing Forms for more information on using these controls. Be aware that Section controls can themselves contain Section controls, and that this affects the nesting level of the controls they contain.

The same data merge consideration is true for form data generated by schemas. For example, suppose you're designing an employee performance review flow that includes two forms. Form 1 contains past performance review data (perhaps read-only) from a database; Form 2 is the same but blank for the current review.

If both forms update the same database table, they may be generated from the same XSD created by a database connector. The issue is that data in Form 2 (current review) will merge with the Form 1 values (past review) if their schemas are the same.

One solution for this problem would be to write two different queries in the database connector so that the past review and current review schemas have different namespaces, which would prevent them from merging.

Flow Processing Modes

The Navigation toolbar provides the ability for a user to navigate back and forth between the steps of a workflow. This is helpful if the user needs to return to a previously competed step to make a correction or review the entered data. Editing of previously completed activities in a workflow is no longer possible if the previous step was completed by a different user than the current user. Previously completed steps are now rendered as read only unless it is a prior activity for the same user, with no intervening activities belonging to another user. This feature is referred to as View mode.

Navigating through completed activities rendered in View mode using the the Continue button, skips completed activities such as HTTP Wait Notify  and anonymous Email. Configured document actions are not re-executed in View mode.

Let's consider the example of a new Employee On Boarding workflow, configured with the navigation toolbar. The first 4 steps in this workflow are referred to as a screenflow since they are all completed by the new employee. The screenflow in this example, consists of an Employee Information, W -4 Allowances, Education, Summary and Confirmation forms. New employee, Tom, realizes when he gets to the Confirmation step(4) that he needs to make a correction on the Allowances step (2).

Tom clicks the Allowance step in the navigation toolbar or the details button on the Summary step and is able to edit the data to make his correction. Tom clicks the Continue button to return to the confirmation step, signs the confirmation form then sends the workflow to his manager.

Before manager Jerry approves the workflow, he wants to review the previously completed steps to ensure all is in order. Jerry clicks on the Employee step of the navigation toolbar and is able to review the information but he will not be able to edit it. 

Clicking the Continue button displays the subsequent tasks in View mode and eventually brings him back to the Manager Approval step where he can approve or reject the task.