Sub-Process Data Fields and Unmapped Formal Parameters

Sub-process data fields and unmapped formal parameters are moved up to the calling process after refactoring. In order to preserve the original semantics of the sub-process, any data fields or unmapped formal parameters in the sub-process that also exist in the calling-process are renamed (each new instance of the same named data is suffixed with a sequence number). Any references to the renamed sub-process data are updated when the sub-process activities and flows are moved up to the calling process.

Note: Package-level data fields are not included in this behavior unless the sub-process is in a different package to the calling process.

For example: A sub-process has a data field called CustomerField which its activities use internally. The calling process also has a field called CustomerField which it uses internally.

When the sub-process is in-lined, the sub-process CustomerField is copied into the calling-process as CustomerField2. All references to CustomerField in sub-process activities and flows are replaced with references to CustomerField2.

Multiple Calls to a Sub-Process

This rule also applies when several sub-processes are called from a single process. If the sub-processes have the same data fields names, then each invocation will cause separate, sequence-numbered instances of data fields in the calling process when they are made inline.

For example: There are two calls to the same inline sub-process from a single calling process. The sub-process has a field called CustomerField.

The copy of sub-process activities and flows ‘moved up’ in place of one call sub-process activity will operate on CustomerField and the other will operate on CustomerField2.

Field Name Conflicts

This rule also applies when inline sub-processes are nested, and have conflicting field names.

For example: The calling-process (MainProcess) calls an inline sub-process (SubProcess) which in turn calls a nested inline sub-process (SubSubProcess).

Each process has a field called CustomerField.

  • SubSubProcess is in-lined into SubProcess so that its instance of CustomerField becomes CustomerField2 in SubProcess.
  • SubProcess now has 2 fields, CustomerField and CustomerField2. When this is in-lined into MainProcess CustomerField in SubProcess is dealt with first (alphabetically) and is therefore renamed as CustomerField2 in MainProcess.
  • Now when the SubProcess field CustomerField2 is subsequently copied into MainProcess, a CustomerField2 already exists so it is renamed as CustomerField3.