Use the Process node types to define processes, as decribed in Process definition.
- Give each process step a name and script - do not rely on the convention that defaults the script to the name.
- For the script reference, use a reference of form "stepTypeXXXX". This ensures that the bindings do not get confused with other options or bindings.
- Include status rule definitions in the processes.
- Be explicit about the next step. Do not set "next" to true or allow it to default to true.
- Include option placeholders for any values that might reasonably change. Option placeholders are of the form "${}" and are evaluated when the process is defined. Do not confuse them with runtime placeholder of the form "%{}" which are evaluated when the process is run.
- Only include binding references for the step scripts.
- Include binding placeholders for any node references, but do not include the bindings in the process.
- Where a form is required, use an option reference in the process (e.g. "${myComponent.myForm}"), and similarly for scripts. These options can then be set in the surrounding component so that they are defaulted through a binding but can be overridden, for example:
- Set the "myForm" property of the "myComponent" to "${form:formMy}". This can be overridden later.
- Bind the reference "private.formMy" to the form node. This reads the default value from the bound form node.
- Briefly document each option (e.g. a list). They will be documented more fully in the process specification that includes them.
- Don't include options or bindings, except for bindings for step scripts.