Process module standards checklist

Folder structure

  • Each folder contains all nodes for a single independent component.
  • The folder local reference is in lower_snake_case and matches the component reference (if applicable).
  • If multiple logically related components are in one folder, they each have distinct component names and references.

Component structure

  • Each component uses the Process Specification node type.
  • The component name is in Title Case (e.g., "Calculate Results").
  • The component local reference is in UpperCamelCase with the suffix Component (e.g., CalculateResultsComponent).
  • If the component is externally referenced (such as a process type or module-level service component), its local reference should use lower_snake_case. For a process type, this should match the process type reference.
  • Sub-components use qualified names like "Component Name Qualifier" and references like ComponentNameQualifierComponent.
  • Subcomponents or included nodes (e.g., processes) are named "Component Name Qualifier Role" if applicable.
  • The process role appears at the end of the name if fixed (e.g., "Respond Partner").
  • Each component contains only the minimum number of subcomponents and processes required, respecting modularity.

Processes

  • Each process uses the Process node type.
  • Every step has an explicit name and script. Do not rely on default script resolution based on step name.
  • The script is always referenced via a binding of the form "stepTypeXXXX".
  • Only step type bindings are used in the process itself — no other bindings or options.
  • All other values (forms, config, etc.) are included via ${} placeholders, referencing options defined in the surrounding component.
  • Status rules are embedded directly in the process definition if required.
  • The next step is always explicitly set. Do not use true or omit it.
  • Any process values that might vary are configured as option placeholders using ${}.

Options and bindings

  • Bindings are string references to persistent nodes (e.g., forms, scripts).
  • Form bindings begin with form, e.g., formEnquiry.
  • Script bindings begin with script, e.g., scriptValidate.
  • Options are defined as blocks of JSON per component, like:
{
  "myComponent": {
    "myProperty": "value"
  }
}
  • Accessed with placeholders like ${myComponent.myProperty}.
  • Both the component object name (e.g. myComponent) and property name (myProperty) use lowerCamelCase.
  • Only step type bindings (e.g., stepTypeSend) are placed directly in the process.
  • All other references (e.g., forms, scripts) are placed in the component as options.
  • Use "private" options or bindings (e.g., private.formEnquiry) to prevent overrides.
  • Placeholders do not need the private. prefix — the resolution logic will detect the correct scope.
  • A component may reference or override the configuration of another component as needed.

Documentation

  • All variable options are documented in the lowest-level component.
  • All significant options are also documented in higher-level components, unless responsibility is delegated.