Choosing a Design Pattern for your workflow

There are two design patterns to be considered when designing your workflow. Choosing one design pattern over the other really depends on the purpose of your workflow. The choices are:

• Use individual form as your steps
• Use Linked steps

For example, if you were creating a workflow from a fifty tab Excel spreadsheet, you can create forms for each tab then drag the individual forms into your workflow for your steps.

Workflows where one form gets routed to a lot of people and they all have to work on it collaboratively, typically use the Linked steps approach.

Form Control Names and Schemas 

When you create a workflow,  creates an XSD schema of the workflow that combines all the fields in all the forms in the workflow. For example, if you go to the Workflows Home Page and select  (from the Action Menu) to download or open a workflow's schema, you'll see that it contains elements for all the controls in each form in the workflow.

When designing the forms you want to use in a workflow, 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 workflow 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 workflow 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 workflow 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 workflow's XSD schema and separate pieces of data in the submitted workflow'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 workflow, 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 workflow 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.