Skip to main content
2023-R2Workflow

Workflow API: Support of Workflow-Identifying Fields of the Second Level

Last updated: 31 October 2025

Workflow API: Support of Workflow-Identifying Fields of the Second Level

Workflow API: Support of Workflow-Identifying Fields of the Second Level

The following topic describes how Workflow API can be used to implement workflows based on the values of workflow-identifying fields of the second level (subtype fields).

By using Workflow API, a developer can define workflow selection to be based on the value of a type identifier and then further based on the value of the subtype identifier. A workflow defined for the subtype identifier value inherits its configuration from the workflow defined for the type identifier value. The following diagram shows the types and subtypes of workflows based on their workflow-identifier field values.

Figure 1. Types and subtypes of workflows

To create a workflow for a value of the subtype identifier, a developer needs to do the following at the screen configuration level:

  1. Define the type identifier by calling the FlowTypeIdentifierIs<>() method
  2. Define the subtype identifier by calling FlowSubTypeIdentifierIs<>() method
  3. For each value of the type identifier field, define the set of workflows in the WithFlows() method
  4. For each value of the subtype identifier field, define the set of workflows in the WithSubFlows() method

Sales Order Example

Suppose that the system has sales orders whose workflows depend on the value of the Behavior field. Further suppose that for each value of the Behavior field, a developer may need to define workflows that are selected based on the Order Type field. This means that the developer needs to specify the Behavior field as the workflow-identifier field of the first level, and the Order Type field as the workflow-identifying field of the second level.

The following code shows how to define the list of workflows for values of the subtype identifier.

context.AddScreenConfigurationFor(screen =>
{
    return screen
        .StateIdentifierIs<status>()
        .FlowTypeIdentifierIs<behavior>()
        .FlowSubTypeIdentifierIs<orderType>()
        .WithFlows(flows =>
        {
            flows.Add<SOBehavior.sO>(flow => flow
                // define states and transitions here
                .WithSubFlows(subFlows =>
                {
                    subFlows.Add("S1", subFlow => 
                      // define states and transitions here
                    );
                    subFlows.Add("S2", subFlow => => 
                      // define states and transitions here
                    );
                }));
            flows.Add<SOBehavior.rM>(flow => flow
                // define states and transitions here
                .WithSubFlows(subFlows =>
                {
                    subFlows.Add("R1", subFlow => => 
                      // define states and transitions here
                    );
                    subFlows.Add("R2", subFlow => => 
                      // define states and transitions here
                    );
                }));
        });
});

The code above does the following:

  • Specifies the state identifier field: Status
  • Specified the type identifier field: Behavior
  • Specifies the subtype identifier field: OrderType
  • Defines two workflows for the values of the Behavior field: SOBehavior.sO and SOBehavior.rM
  • In the workflow for the SOBehavior.sO value, adds two workflows, which are selected based on the value of the subtype identifier
  • In the workflow for the SOBehavior.rM value, adds two workflows, which are selected based on the value of the subtype identifier