How do I trigger a request in a sub-process in Cflow?

To configure a trigger action for launching a sub-process in Cflow, follow these steps:

  • Navigate to Workflow Setup from the dashboard and choose the workflow where changes are required.
  • Click on the Automation tab.
  • Select the desired rule or create a new rule by clicking Add Rule.

  • Under Actions, click Add Actions, then select Trigger from the available action types (as shown in the below screenshot).

  • Fill in the trigger action details in the right-side panel that opens:

  • Select Workflow: Choose the target workflow you want to trigger.
  • Description & Notification Text: Provide the necessary context.
  • Submit Triggered Requests: Toggle this ON to auto-submit the triggered request immediately.
  • Allow Progress Only After Sub-process Completes: Use this toggle if the main workflow should wait until the sub-process reaches its end stage.
  • Include Attachments: If necessary, you can include files from the primary workflow.
  • Map the field values between the current workflow and the triggered one using the Source and Target fields.
  • Save the configuration by clicking the Save button at the bottom.

Understanding the Trigger Logic

A triggered request is a new request in a different or the same workflow, automatically created when certain conditions are met in the parent workflow. You can configure this to:

  • Run within the same workflow or a different one.
  • Carry forward values from the parent workflow using field mapping.
  • Assign the initiator of the triggered request as:
  • The reviewer of the current stage (default), or
  • The original initiator using the keyword @@initiator.

Example Scenario

Let’s say the Manager approves a request in the primary workflow. You want this to trigger a new request in a secondary workflow, but ensure the initiator remains the same as in the original request. In such cases:

  • Choose the desired workflow to trigger.
  • Map the field values appropriately.
  • Set the initiator using the @@initiator from the parent request.
  • This ensures continuity and accurate audit trail throughout both workflows.