Workflow definitions

Workflow Definitions describe the stages an application passes through, the paths between those stages, the requirements that must be satisfied, and the actions remoteEaze performs.

Open Business Configuration → Workflow Configurations → Workflow Definitions.

Access and lifecycle

The Workflow Definition permission controls the definition and all five child tabs: Stages, Transitions, Requirements, Actions, and Action Rules. Child entity permissions are not assigned separately in the role editor.

• Read Workflow Definition shows definitions and their configured parts.
• Create Workflow Definition permits new definitions and child records. It also lets the original maker correct their own Captured or Rejected draft.
• Update Workflow Definition permits changes to another maker's draft and supported amendments to Authorized records.
• Delete Workflow Definition controls supported deletion and restoration.
• L1, L2, and L3 authority controls decisions at the matching pending level.

The definition and each child record have their own maker-checker status. They must be submitted and authorized individually. The approval sequence is L3 → L2 → L1 → Authorized, according to the required approval count.

Authorized definitions and child records support amendments. Current values remain live until an amendment is authorized. Read Maker-checker and Amendments for the shared lifecycle.

At L0, select the target company when creating the definition. Its child records inherit that company from the definition.

Create the definition

Select Create Workflow Definition and enter:

Owner Type determines which requirements and actions are valid. Code and Owner Type cannot be changed through an amendment; an Authorized definition can amend its Name and Description.

Open the created definition. Its builder contains Info, Stages, Transitions, Requirements, Actions, and Action Rules.

Configure stages

A stage represents one point in the workflow.

The Stage Review setting controls whether the application needs a recorded human decision before it can leave this stage:

• No Stage Review does not require a stage review. Blocking requirements must still be resolved.
• Optional Review permits a review but does not make it a condition for advancement.
• Required Review requires a current review and a transition whose Review Outcome matches that decision. A valid waiver is the exception.
• Independent Actor Required adds separation of duties. The user advancing the application must be different from the reviewer, except when the L0 platform override applies.

Stage assignment is separate from stage review. A workflow instance may be assigned to a user, Role, Department or Unit, or Branch. The assigned user, or a qualifying user who claims a routed assignment, must accept it before doing work that requires assignment ownership.

Configure transitions

A transition connects two different stages in the same definition. Enter its source and target stages, code, name, and optional description. Then configure:

• Allow Return when the target has a lower Sort Order and the path sends the application back for correction;
• Review Outcome when the path is available only after an Approved, Returned, or Rejected stage review;
• Business Outcome when the path represents Approval, Rejection, Return For Correction, Closure, or ordinary workflow movement.

A transition to a lower Sort Order is a backward path. It must have Allow Return enabled. Runtime history records that movement as Returned. A return retains the work already captured unless another validation rule makes it stale. Configure an explicit forward transition from the earlier stage so the corrected application can continue again.

Do not use a return path as a substitute for rejection. Rejection should use a terminal stage and the Reject Business Outcome. Approval and Closure also require a terminal destination. No Business Outcome is for ordinary movement where the application remains in progress.

Stage review settings and transition outcomes work together. Runtime assignment and review decisions belong to each application. The reusable definition only describes what the journey permits.

Configure requirements

A requirement can apply to one stage or across the workflow. Enter a stable code and name, sort order, severity, verification mode, and whether it is waivable or repeatable.

Blocking prevents progress until satisfied or validly waived. Manual Review routes attention to a user. Advisory records guidance without blocking by itself. Verification can be None, allow the same actor, or require an independent actor. A requirement marked Repeatable can be captured more than once when the process needs successive results.

For Customer Onboarding, configure KYC-owned fields and evidence in the KYC Policy. The workflow validates Customer Onboarding data-field and computed-rule requirements against that division of responsibility.

Configure actions and action rules

An Action runs at a selected stage or transition. Available Action Types depend on the definition's Owner Type. Configure its execution order and any action-specific settings shown for the selected Action Type.

Customer Onboarding actions are bound to a stage or a transition, not both. Other owner types enforce their own compatible action set.

Use Action Rules to decide whether an Action runs. Select the Action, fact field, comparison operator, and value. Sort multiple conditions and join them with AND or OR. Rules control execution of the selected Action; they do not replace requirements that block a stage transition.

Build common workflow shapes

Straight-through processing

Create one Initial Stage, the necessary work stages, and a terminal approved stage. Connect them with forward transitions. Use No Stage Review where blocking requirements and action rules provide enough control.

Required review

Set the work stage to Required Review, then create separate transitions whose Review Outcomes match Approved, Returned, or Rejected. Point the Approved path forward, the Returned path to an earlier correction stage, and the Rejected path to a terminal rejected stage.

Return for correction

Create a transition from the review stage to an earlier stage, enable Allow Return, and select Return For Correction when the owner record should remain in review. Also create the forward path that resubmits corrected work.

Terminal approval or rejection

Mark the destination as Terminal Stage. Use Approve or Reject as the Business Outcome. Configure the Actions that must run at the stage or on the transition, then authorize those child records before using the workflow.

Authorize and make the workflow usable

Build in dependency order: stages, transitions, requirements, actions, and action rules. Submit and authorize every part intended for runtime use, then submit and authorize the definition.

Operational consumers use active Authorized records. A Customer Onboarding Policy, for example, can link only an active Authorized Customer Onboarding definition.

The parent definition may be Authorized before its full journey is complete. Stages, transitions, requirements, actions, and action rules can be added later; each new child follows its own maker-checker lifecycle and is not available to operations until it is Authorized.

Before linking or using the definition, verify that its currently Authorized children provide an initial stage and every required path and control. Runtime workflows resolve the active Authorized children of the shared definition, so later additions can also affect applications already using it. Create a separate definition when a change must apply only to future applications.