Building a New Process from Scratch

Process configuration from scratch refers to the creation of a completely new business process or workflow without utilizing any existing process definitions, templates, or imported configurations. This approach provides full flexibility to design the workflow structure, define process steps, configure routing and embedding rules, establish metadata, and tailor the process to meet specific business requirements and operational procedures.

Follow the below Steps to create new process;

Click the Add Process button located on the top-right corner of the screen.
A modal box will appear on screen requesting to key-in the process_slug. Enter a unique, recognizable value for your process (e.g. type user_registration for your User registration process).
Click the confirm Add button.
The initialization modal closes, and the system instantly routes you into a robust, interactive Blank Canvas (Visual Canvas Environment). This environment acts as your design surface where custom business rules and functional blocks are orchestrated.

💡 Note: Process Slug is a unique system identifier assigned to a process. It is used internally by the platform to distinguish one process from another and may be referenced in configurations, APIs, integrations, URLs, and system-generated records. The value should be concise, descriptive, and unique across the system. It is recommended to use lowercase letters and underscore (_) instead of spaces or special characters. For example, user_registration, loan_application, or employee_onboarding clearly identify the purpose of the corresponding process while maintaining a standardized naming convention.

Understanding Parameters

Parameters represent the information that a process receives, stores, and uses during execution. Every business process requires data.

For example:

Customer identifiers
Account references
Dates
Amounts
Status values

Parameters provide a structured way to store this information.

Why are Parameters Important?

Without parameters, stages would have no information to work with. Parameters are commonly used by:

Forms
API requests
Accounting entries
Validation rules
Decision logic

A parameter defined at process level becomes available throughout the process.

Parameter Types

Parameter Type	Description	Examples	Notes
String	Stores text values.	Names, Descriptions, Identifiers, Reference Numbers	Avoid using String parameters for amounts or dates.
Account	Stores a reference to an account.	Debit Accounts, Credit Accounts, Customer Accounts	Enables account-specific validations.
Amount	Stores monetary values.	Transaction Amount, Service Fee, Interest Amount	Improves validation and prevents incorrect data types.
Date Time	Stores dates and timestamps.	Value Date, Expiry Date, Submission Date	Suitable for scheduling and time-based calculations.
Percentage	Stores percentage values.	Interest Rates, Tax Rates, Discounts	Supports percentage-specific validation and formatting.
Multi-Object	Stores multiple structured records.	List of Customers, List of Transactions, List of Repayment Schedules	Use when multiple related records must be captured.

Why Choosing the Correct Parameter Type Matters

Area	Impact
Validation	Ensures data is entered in the correct format and follows business rules.
User Input	Provides appropriate input controls and reduces data entry errors.
System Behavior	Enables type-specific processing and functionality.
Available Configuration Options	Makes relevant configuration settings available based on the selected parameter type.

Understanding Process Variables

Process Variables are dynamic values created during execution. Unlike parameters, variables are usually generated, calculated, or transformed while the process is running.

Parameters vs Variables

Aspect	Parameters	Variables
Purpose	Represent data entering the process	Represent data generated or calculated during process execution
Source	Provided as input when the process starts	Created, updated, or calculated within the process
Usage	Used as process inputs for stages and business logic	Used as temporary working data during execution
Lifecycle	Available throughout the process once provided	Can change dynamically as the process progresses
Example	Customer ID, Account Number, Transaction Amount	Calculated Fee, Eligibility Status, Total Balance

The Execution Lifecyle

[ External Trigger / API Call ]
             │
             ▼
      ┌──────────────┐
      │  Parameters  │ ──(Read-Only Configuration)──┐
      └──────────────┘                              │
             │                                      ▼
             │                              ┌───────────────┐
             └─────────────────────────────►│  Expressions  │
                                            └───────────────┘
                                                    │
                                             (Evaluates & Stores)
                                                    │
                                                    ▼
                                            ┌───────────────┐
                                            │   Variables   │ ◄──(Changes state during execution)
                                            └───────────────┘

Configuring stages in a process

The following section provides a step-by-step guide for configuring stages within a process. It explains the purpose of each stage configuration option, along with detailed descriptions of the parameters, properties, and settings associated with a stage. Understanding these configurations will help ensure that each stage is correctly defined and aligned with the intended workflow behavior and business requirements.

To configure a stage, follow the steps below:

Open the required process from the Process Configuration module.
Click on the Add Stage button available within the process designer.
Select the appropriate Stage Type based on the action that the stage is intended to perform.
Provide a unique and meaningful Stage Name to identify the stage within the process.
Configure the common stage properties:
- Initial Stage – Indicates whether the stage is the starting point of the process.
- Final Stage – Indicates whether the stage represents the end of a process execution path.
- Narration – Provides a description of the stage and its purpose.
Configure the stage-specific settings based on the selected stage type.

💡 Note: Different stage types expose different configuration options such as request configuration, account mappings, tariff rules, journal entries, variable mappings, or routing conditions.

Configure any required:
- Input Parameters
- Stage Variables
- Event Conditions
- Output Variables
- Post Processing Logic
- Webhook Configuration
Define the execution flow by connecting the stage to subsequent stages and configuring any conditional routing criteria where required.
Review the configuration to ensure all mandatory fields are completed and all dependencies have been configured correctly.
Click Save Changes to save the stage configuration.

Refer to the below section for detailed descriptions of the configuration form fields.

Journal Stage

What it does: This block is the core engine used whenever a process must record formal accounting double-entries, balance ledger states, or build immutable audit logs.
Use Case: Imagine designing a automated Fund Transfer Process. When money is moved from Account A to Account B, simple database updates are unsafe. Instead, you drop a Journal Stage block onto the canvas:
1. Configure the stage to capture the primary transaction amount.
2. Establish rules to reference the accurate Source Account ledger (Customer Account A) and flag it for a Debit action.
3. Establish balancing rules to reference the Target Account ledger (Customer Account B) and flag it for a corresponding Credit action.
4. The Journal block tracks this entry to ensure total debits precisely equal total credits, locking the ledger entries into the immutable ledger database.

Stage Configuration:

Following are the fields for configuring Journal stage in a process;

Section	Field	Description
General	Stage Name	Unique name used to identify the stage within the process workflow. Use lowercase with no whitespace in the name. Special characters such as underscore `_` can be used. For example: `fund_transfer_journal`.
General	Journal Amount Source	Selects the amount parameter that will be used when generating journal entries for this stage. Ensure an Input Parameter with parameter type `Amount` is configured before configuring the journal stage. For example, `balance` may represent the customer's available balance.
General	Value Date Source	Selects the date parameter that will be used as the transaction value date during journal posting. Only parameters configured with a date-related parameter type are available for selection.
General	Is It Initial Stage?	Indicates whether the stage is the starting point of the workflow. Only one stage should normally be marked as the initial stage within a process definition.
General	Is It Final Stage?	Indicates whether the stage is the last stage in the workflow. Once a final stage is successfully executed, no further workflow transitions are performed.
General	Narration	Transaction description or narration used during journal posting. This value is typically stored in accounting records, audit logs, and transaction history. Expressions and parameters may be used to generate dynamic narrations where supported.
Stage Parameters	Input Parameters	Displays all parameters available to the stage. These parameters can be referenced in journal entries, controls, tariff functions, stage variables, post-processing rules, and webhook configurations.
Product Configuration	Products	Selects the products for which the stage configuration is applicable. The stage will only be available for the selected products during process execution.
Product Configuration	Free Text List	Allows entry of additional product identifiers, product codes, or custom values that are not available in the product master list. Multiple values can be configured as required.
Entries	Type of Transaction	Defines whether the journal entry is a Debit (`DR`) or Credit (`CR`) transaction. This determines the accounting impact of the journal entry.
Entries	Is Balancing	When enabled, the system automatically calculates the balancing amount required to ensure that total debits and credits remain balanced. Only one entry should typically be configured as a balancing entry.
Entries	Account Parameter	Selects the account parameter that will be debited or credited during journal posting. Only parameters configured with parameter type `Account` are available for selection.
Entries	Product Slug	Associates the journal entry with a specific product configuration. This is commonly used when posting entries to product-specific GL accounts.
Entries	Amount Parameter	Selects the amount parameter used for journal posting. Only parameters configured with parameter type `Amount` are available for selection.
Entries	Posting Type (Optional)	Classifies the journal entry for accounting and reporting purposes. Examples include `Principal`, `Interest`, `Fee`, `Commission`, `Tax`, and similar posting categories.
Entries	Add New Entry	Adds a new debit or credit journal entry configuration to the stage. Multiple entries can be configured to support complex accounting scenarios.
Entries	Delete Entry	Removes the selected journal entry configuration from the stage.
Tariff	Tariff Function	Selects the tariff calculation function to be executed during stage processing. Tariff functions are commonly used for fee calculation, tax computation, commission calculation, valuation retrieval, and other pricing-related operations. For example, `get_valuation` retrieves valuation details based on the provided parameters.
Tariff	Name	Optional identifier assigned to the tariff configuration. This helps distinguish multiple tariff configurations configured within the same stage.
Tariff	Input Parameter Mapping	Defines the input values passed to the selected tariff function during execution. Each required function parameter must be mapped to an expression, input parameter, stage variable, or constant value.
Tariff	Expression	Defines the value or expression assigned to a tariff function input parameter. Expressions can reference input parameters, stage variables, constants, and previously calculated values.
Tariff	Output Parameters	Displays the output values returned by the selected tariff function. These outputs become available for use in journal entries, controls, stage variables, post-processing rules, and webhook payloads. For example, `scrip_valuation` may contain the calculated valuation amount returned by the tariff service.
Tariff	Use Current Value Date	When enabled, the system uses the current processing date as the tariff execution value date instead of the configured Value Date Source.
Tariff	Add New Stage Tariff	Adds an additional tariff configuration to the current stage. Multiple tariff functions can be executed within the same stage if required.
Tariff	Delete Tariff	Removes the selected tariff configuration from the stage.
Controls	Control Name	Defines the validation or control rule that must be satisfied before the stage can be executed. Control rules are used to enforce business constraints and prevent invalid transactions. Examples may include user validation, channel validation, process validation, balance validation, or product eligibility checks.
Controls	Transaction Type	Specifies whether the validation applies to Debit (`DR`) or Credit (`CR`) transactions.
Controls	Amount Parameter	Selects the amount parameter that will be evaluated by the control rule. Only parameters configured with parameter type `Amount` are available for selection. For example, `balance` may be validated to ensure sufficient funds are available before posting.
Controls	Add Control	Adds a new validation control configuration to the stage.
Controls	Delete Control	Removes the selected validation control from the stage configuration.
Stage Variables	Name	Unique identifier for the stage variable. The variable can be referenced throughout the stage configuration including entries, controls, tariff functions, post-processing rules, and webhook payloads. For example, `available_balance`, `valuation_amount`, or `customer_type`.
Stage Variables	Variable Type	Defines when the variable is evaluated during stage execution. For example, `Pre` variables are evaluated before journal processing begins, while `Post` variables are evaluated after stage processing is completed.
Stage Variables	Param Type	Defines the data type of the variable. Supported types may include String, Number, Amount, Date, Boolean, Account, and other configured parameter types.
Stage Variables	Expression	Defines the formula, constant value, or expression used to calculate the variable. Expressions may reference input parameters, tariff outputs, system values, and other stage variables. For example, `service_fee + tax_amount`.
Stage Variables	Move Up	Moves the variable higher in the execution order. Variables are evaluated sequentially based on their configured order.
Stage Variables	Move Down	Moves the variable lower in the execution order.
Stage Variables	Add Variable	Creates a new stage variable definition.
Stage Variables	Delete Variable	Removes the selected stage variable from the configuration.
Post Processing	Variable Name	Defines the target process variable that will be updated after successful completion of the stage. Post-processing variables are commonly used for workflow routing, status updates, and process state management. For example, `next_stage`.
Post Processing	Expression	Defines the value or expression assigned to the specified process variable after successful stage execution. Expressions may reference input parameters, stage variables, tariff outputs, and transaction results. For example, setting `next_stage = "approval-stage"` directs the workflow to the approval stage.
Webhook Config	Header Name	Defines the HTTP header key that will be included in the outbound webhook request. Examples include `Authorization`, `Content-Type`, `X-API-Key`, and custom integration headers.
Webhook Config	Header Value	Defines the value associated with the configured HTTP header. Values may be static text, expressions, environment variables, or dynamically generated tokens. For example, `Bearer <token>`.
Webhook Config	Add Header	Adds an additional HTTP header configuration to the webhook request.
Webhook Config	Delete Header	Removes the selected HTTP header configuration.
Webhook Config	Payload	Defines the request body that will be sent to the external system when the webhook is executed. Payloads are typically configured in JSON format and may include input parameters, stage variables, tariff outputs, journal results, and transaction details. Dynamic expressions can be embedded to send runtime values.
Tabs	Entries	Used to configure all debit and credit journal entries that will be generated during stage execution.
Tabs	Tariff	Used to configure tariff functions for valuation retrieval, fee calculation, commission calculation, tax calculation, and other pricing-related operations.
Tabs	Controls	Used to define business validations that must pass before stage execution can proceed.
Tabs	Stage Variables	Used to create temporary, derived, or calculated variables that can be referenced throughout stage execution.
Tabs	Post Processing	Used to update process variables and define actions that occur after successful stage completion.
Tabs	Webhook Config	Used to configure integration with external systems through HTTP-based API calls.

API Stage

What it does: This block is an integration gateway used to query external software systems, validate customer data against regulatory APIs, or trigger external message brokers.
Operational Use Case: During an active ledger process, you might need to check external constraints before committing financial records. For example, fetching real-time credit metrics or validation fields. Dropping a Third-Party API Stage allows the process to pause, establish an outbound connection, retrieve critical payload datasets, and inject those data parameters cleanly into downstream Journal or evaluation stages.

Stage Configuration:

Following are the fields for configuring API stage in a process;

Section	Field	Description
General	Stage Name	Unique name used to identify the API stage within the workflow. Use lowercase with no whitespace in the name. Special characters such as underscore `_` can be used. For example: `login`, `fetch_kyc`, or `fetch_credit_score`.
Input Variables	Name	Defines the variable name that will be available during API request construction. Input variables can be referenced within the URL, payload expression, headers, event conditions, and other stage configurations. For example, `customer_id`, `account_number`, or `access_token`.
Input Variables	Type	Defines the data type of the input variable. Supported types may include String, Number, Boolean, Date, Amount, Object, and other configured parameter types. The selected type determines validation and expression behavior.
Input Variables	Expression	Defines the value assigned to the input variable during execution. Expressions may reference process parameters, stage variables, tariff outputs, system variables, or constant values. For example, `customer.id` or `process.customer_id`.
Input Variables	Add New Variable	Creates a new input variable definition that can be used while constructing the API request.
Input Variables	Delete Variable	Removes the selected input variable from the stage configuration.
Input Variables	Move Up	Moves the variable higher in the evaluation sequence. Variables are resolved sequentially based on their configured order.
Input Variables	Move Down	Moves the variable lower in the evaluation sequence.
Request Configuration	URL	Defines the target endpoint that will receive the outbound HTTP request. The URL may be static or dynamically constructed using expressions and variables. For example: `https://api.partner.com/customer/validate`.
Request Configuration	Method	Defines the HTTP method used when invoking the API. Common methods include `GET`, `POST`, `PUT`, `PATCH`, and `DELETE`. Select the method based on the requirements of the target service.
Request Configuration	Payload Expression	Defines the request body that will be sent to the external system. Payloads are typically configured in JSON format and may include input variables, process parameters, stage variables, or static values. For example: `{ "Username": "admin", "Password": "admin" }`.
Request Configuration	Content-Type	Specifies the media type of the outbound request payload. Common values include `JSON`, `XML`, `FORM-DATA`, and `TEXT`. This value is sent through the HTTP `Content-Type` header.
Request Configuration	Omit Empty	When enabled, parameters with null, empty, or blank values are automatically excluded from the generated request payload. This helps prevent unnecessary data from being transmitted to external systems.
Request Configuration	Header Key	Defines the HTTP header name that will be included in the outbound request. Examples include `Authorization`, `Content-Type`, `Accept`, `X-API-Key`, and custom integration headers.
Request Configuration	Header Value	Defines the value associated with the configured HTTP header. Values may be static text, expressions, environment variables, or dynamically generated tokens. For example: `Bearer ${access_token}`.
Request Configuration	Add Header	Adds a new HTTP header configuration to the outbound API request.
Request Configuration	Delete Header	Removes the selected HTTP header configuration from the request.
Response Configuration	Content Type	Defines the expected content type returned by the external API. Common values include `JSON`, `XML`, and `TEXT`. The selected type determines how the response payload will be parsed and processed.
Response Configuration	Response Type	Defines the structure of the response payload. Supported types may include `OBJECT`, `ARRAY`, `STRING`, `NUMBER`, `BOOLEAN`, and other supported schema types.
Response Configuration	Schema	Defines the expected response structure returned by the external service. The schema is used to validate, parse, and expose response fields for use within the workflow.
Response Configuration	Key	Defines the field name expected in the response payload. For example, a login API may return a field named `Token`.
Response Configuration	Type	Defines the data type of the response field. Examples include `STRING`, `NUMBER`, `BOOLEAN`, `OBJECT`, and `ARRAY`.
Response Configuration	Add Field	Adds a new field definition to the response schema. Multiple fields can be configured to represent complex response structures.
Response Configuration	Delete Field	Removes the selected field definition from the response schema.
Output Variables	Name	Defines the variable that will be created from the API response and made available to subsequent stages. For example, `access_token`, `customer_status`, or `credit_score`.
Output Variables	Type	Defines the data type of the output variable. Supported types may include String, Number, Boolean, Date, Object, and Array.
Output Variables	Expression	Defines how the value is extracted from the API response. The API response body is available through the variable `response_body`. For example, `response_body.Token` extracts the value from the `Token` field in the response.
Output Variables	Add New Variable	Creates a new output variable mapping from the API response.
Output Variables	Delete Variable	Removes the selected output variable mapping.
Output Variables	Move Up	Moves the variable higher in the evaluation sequence.
Output Variables	Move Down	Moves the variable lower in the evaluation sequence.
Event Config	Condition (If)	Defines the logical expression that determines whether the configured event actions should execute. The expression must evaluate to either `true` or `false`. For example, `response_body.status == "SUCCESS"`.
Event Config	Action	Defines the action that will be executed when the condition evaluates to true. Available actions depend on the workflow engine configuration. Common actions include executing another stage, updating process variables, or terminating the workflow.
Event Config	Stage	Specifies the target stage associated with the selected action. For example, selecting `fetchkyc` will trigger execution of the KYC retrieval stage when the event condition is satisfied.
Event Config	Add Action	Adds an additional action to be executed when the event condition evaluates to true. Multiple actions can be configured under a single event condition.
Event Config	Delete Action	Removes the selected event action configuration.
Event Config	Add Event Criteria	Creates a new conditional event block. Multiple event criteria can be configured to support different execution paths based on API responses.
Event Config	Delete Event Criteria	Removes the selected event criteria configuration.
Webhook Config	Header Name	Defines the HTTP header key that will be included in the webhook request triggered by the API stage.
Webhook Config	Header Value	Defines the value associated with the configured webhook header. Values may be static text, expressions, or variables.
Webhook Config	Add Header	Adds an additional HTTP header configuration to the webhook request.
Webhook Config	Delete Header	Removes the selected webhook header configuration.
Webhook Config	Payload	Defines the request body that will be sent when the webhook is executed. The payload may contain input variables, API response values, output variables, process parameters, and stage execution results.
Actions	Save Changes	Saves all stage configurations and updates the API stage definition within the process workflow.

Tariff Stage

What it does: The Tariff Stage is used to execute configurable business functions that perform calculations, validations, pricing operations, external lookups, or business rule evaluations during workflow execution. A tariff function accepts one or more input parameters, processes them using predefined business logic, and returns output parameters that can be consumed by subsequent stages.

Unlike Journal Stages, which generate accounting entries, the Tariff Stage focuses on deriving business values and decision parameters that influence workflow behavior.
Operational Use Case: During transaction processing, business decisions often depend on calculations or validations that cannot be directly derived from the input data. The Tariff Stage allows the workflow to execute configurable business functions and capture their outputs for further processing.

For example, before a fund transfer is executed, a tariff function may verify whether the customer's balance exceeds a configured threshold. The returned result can then determine whether the workflow proceeds to a transfer stage, requests additional authorization, or terminates the process.

Stage Configuration:

Section	Field	Description
General	Stage Name	Unique name used to identify the tariff stage within the workflow. Use lowercase with no whitespace in the name. Special characters such as hyphen `-` can be used. For example: `check-balance-threshold`, `calculate-fee`, or `validate-account`.
General	Is It Initial Stage?	Indicates whether the tariff stage is the starting point of the workflow. Only one stage should normally be configured as the initial stage.
General	Is It Final Stage?	Indicates whether the tariff stage is the final stage in the workflow. If enabled, workflow execution terminates successfully after this stage completes.
General	Narration	Optional description used for documentation, audit logging, monitoring, and operational visibility purposes.
General	Completion Expression	Defines the expression that determines whether the stage execution is considered successful. The expression must evaluate to a Boolean value (`true` or `false`). If the expression evaluates to `false`, workflow execution may halt or follow alternative processing logic depending on system configuration.
Tariff Configuration	Tariff Function	Selects the business function that will be executed during stage processing. Tariff functions can perform calculations, validations, lookups, rule evaluations, or integrations. For example, `tariff_api_test` may validate whether an account balance exceeds a configured threshold.
Tariff Configuration	Name	Optional identifier assigned to the tariff configuration. This helps distinguish multiple tariff configurations configured within the same stage.
Tariff Configuration	Input Parameters	Displays all input parameters required by the selected tariff function. Each parameter must be mapped to a constant value, expression, stage variable, process parameter, or output from a previous stage.
Tariff Configuration	Input Parameter Value	Defines the value assigned to a specific tariff function input parameter. Expressions may reference process parameters, stage variables, tariff outputs, system variables, or constants. For example, `{{._balance_decimal_1}}` or `1000`.
Tariff Configuration	Output Parameters	Displays all output values produced by the selected tariff function after execution. These outputs become available for downstream stages, controls, post-processing rules, and workflow decisions.
Tariff Configuration	Output Parameter Mapping	Maps the tariff function output to a workflow parameter or variable. For example, the function output `result` may be mapped to `_result` for use in later stages.
Tariff Configuration	Param	Specifies the target workflow parameter or variable that will store the tariff function output value.
Tariff Configuration	Use Current Value Date	When enabled, the system uses the current system date and time during tariff execution instead of any configured workflow value date. This is commonly used for real-time calculations and validations.
Tariff Configuration	Add New Tariff Configuration	Adds an additional tariff function configuration to the stage. Multiple tariff functions can be executed sequentially within the same stage.
Tariff Configuration	Delete Tariff	Removes the selected tariff configuration from the stage.
Webhook Config	Header Name	Defines the HTTP header key that will be included in the webhook request executed after tariff processing. Examples include `Authorization`, `Content-Type`, `Accept`, and `X-API-Key`.
Webhook Config	Header Value	Defines the value associated with the configured HTTP header. Values may be static text, expressions, environment variables, or dynamically generated tokens.
Webhook Config	Add Header	Adds a new HTTP header configuration to the webhook request.
Webhook Config	Delete Header	Removes the selected webhook header configuration.
Webhook Config	Payload	Defines the request body sent when the webhook is triggered. The payload may include tariff outputs, process parameters, stage variables, and workflow execution details. Expressions may be used to construct dynamic payloads.
Post Variables	Variable Name	Defines the process variable that will be updated after successful tariff execution. Post variables are commonly used for workflow routing, status updates, and passing values to downstream stages. For example, `next_stage`.
Post Variables	Expression	Defines the value assigned to the specified process variable after stage execution. Expressions may reference tariff outputs, stage variables, process parameters, or system variables. For example, `{{.validate_enough_balance}}` may determine which stage should execute next.
Actions	Save Changes	Saves all stage configurations and updates the tariff stage definition within the workflow.

Account Stage

What it does: The Account Stage is responsible for creating, maintaining, and managing account records within the workflow engine. Depending on the stage configuration, it can either create a new account or update an existing account by modifying account attributes, metadata, reporting classifications, ledger policies, statuses, and other account-related information.

The stage serves as the primary mechanism for managing customer, loan, wallet, deposit, settlement, and operational accounts that are required for subsequent workflow activities. It also allows business-specific information to be stored through configurable metadata fields, ensuring that account records remain synchronized with customer, product, and transaction lifecycles.
Operational Use Case: In most financial and transactional workflows, accounts must be created before any balances, journals, fees, repayments, settlements, or ledger postings can occur. The Account Stage enables workflows to provision new accounts, associate them with products, assign reporting structures, and expose account references for downstream stages.

Once accounts exist, the same stage can be used to update account information as the workflow progresses. For example, customer onboarding may initially create a customer account, while later stages update customer identifiers, account classifications, risk ratings, reporting groups, pledge information, account statuses, or integration-specific metadata obtained from external systems.

A typical loan onboarding process may create a customer account during registration, update account attributes after KYC and credit verification, associate collateral information during pledge creation, and finally use the account for journal postings, fee collections, disbursements, repayments, and settlement activities. By centralizing account creation and maintenance within a single stage type, the workflow ensures that all downstream operations always reference the most accurate and up-to-date account information.

Stage Configuration - Add Account:

Section	Field	Description
General	Stage Name	Unique name used to identify the account stage within the workflow. Use lowercase with no whitespace in the name. Special characters such as hyphen `-` can be used. For example: `add_customer_account` or `create_wallet_account`.
General	Is It Initial Stage?	Indicates whether the account stage is the starting point of the workflow. Only one stage should normally be configured as the initial stage.
General	Is It Final Stage?	Indicates whether the account stage is the final stage in the workflow. If enabled, workflow execution terminates after successful account creation.
General	Narration	Optional description used for audit logging, monitoring, reporting, and operational visibility.
Account Configuration	Account Name	Defines the unique account identifier or account name to be created. This field commonly references a workflow parameter or generated value. For example: `{{.account_id}}`.
Account Configuration	Product ID	Specifies the product under which the account will be created. The selected product determines account behavior, configuration, validations, and applicable business rules. For example: `customer`, `loan`, `wallet`, or `deposit`.
Account Configuration	Reporting Group ID	Defines the reporting group associated with the account. Reporting groups are typically used for categorization, reporting, MIS generation, and financial analysis. For example: `default_reporting_group`.
Account Configuration	Account Ref ID	Defines an external reference identifier associated with the account. This is commonly used to link the account with external systems, customer identifiers, CRM records, or business references. For example: `{{.account_id}}`.
Account Configuration	FreeText 1	Optional custom attribute field that can store additional account information. The value may be static or dynamically populated using expressions. For example: `{{.boid}}`.
Account Configuration	FreeText 2	Optional custom attribute field available for storing supplementary account information such as mobile numbers, references, classifications, or business-specific metadata.
Account Configuration	FreeText 3	Optional custom attribute field used to store implementation-specific account metadata.
Account Configuration	FreeText 4	Optional custom attribute field used to store implementation-specific account metadata.
Account Configuration	FreeText 5	Optional custom attribute field used to store implementation-specific account metadata.
Account Configuration	FreeText 6	Optional custom attribute field used to store implementation-specific account metadata.
Account Configuration	FreeText 7	Optional custom attribute field used to store implementation-specific account metadata.
Account Configuration	FreeText 8	Optional custom attribute field used to store implementation-specific account metadata.
Account Configuration	FreeText 9	Optional custom attribute field used to store implementation-specific account metadata.
Account Configuration	FreeText 10	Optional custom attribute field used to store implementation-specific account metadata.
Account Configuration	FreeText 11	Optional custom attribute field used to store implementation-specific account metadata.
Account Configuration	FreeText 12	Optional custom attribute field used to store implementation-specific account metadata.
Account Configuration	FreeText 13	Optional custom attribute field used to store implementation-specific account metadata.
Account Configuration	FreeText 14	Optional custom attribute field used to store implementation-specific account metadata.
Account Configuration	FreeText 15	Optional custom attribute field used to store implementation-specific account metadata.
Account Configuration	FreeText 16	Optional custom attribute field used to store implementation-specific account metadata.
Account Configuration	FreeText 17	Optional custom attribute field used to store implementation-specific account metadata.
Account Configuration	FreeText 18	Optional custom attribute field used to store implementation-specific account metadata.
Account Configuration	FreeText 19	Optional custom attribute field used to store implementation-specific account metadata.
Account Configuration	FreeText 20	Optional custom attribute field used to store implementation-specific account metadata.
Account Configuration	FreeText 21	Optional custom attribute field used to store implementation-specific account metadata.
Account Configuration	FreeText 22	Optional custom attribute field used to store implementation-specific account metadata.
Account Configuration	FreeText 23	Optional custom attribute field used to store implementation-specific account metadata.
Account Configuration	FreeText 24	Optional custom attribute field used to store implementation-specific account metadata.
Account Configuration	FreeText 25	Optional custom attribute field used to store implementation-specific account metadata.
Input Parameters	Key	Defines the name of an additional parameter that should be stored against the created account. This allows account records to contain dynamic business-specific attributes.
Input Parameters	Value	Defines the value assigned to the corresponding input parameter. Expressions, constants, workflow parameters, stage variables, and outputs from previous stages can be used.
Input Parameters	Add Parameter	Adds a new account parameter configuration.
Input Parameters	Delete Parameter	Removes the selected account parameter configuration.
Account Mapping	Account ID	Displays the account identifier generated or created by the stage.
Account Mapping	Target Parameter	Defines the workflow parameter that will receive the created account reference. For example, mapping the generated account to `customer_account` allows downstream stages to use the account.
Webhook Config	Header Name	Defines the HTTP header key that will be included in the webhook request executed after account creation. Examples include `Authorization`, `Content-Type`, `Accept`, and `X-API-Key`.
Webhook Config	Header Value	Defines the value associated with the configured webhook header. Values may be static text, expressions, environment variables, or dynamically generated tokens.
Webhook Config	Add Header	Adds a new HTTP header configuration to the webhook request.
Webhook Config	Delete Header	Removes the selected webhook header configuration.
Webhook Config	Payload	Defines the request body sent when the webhook is triggered. The payload may include account details, workflow parameters, stage variables, and execution metadata. Expressions may be used to construct dynamic payloads.
Post Variables	Variable Name	Defines the process variable that will be updated after successful account creation. Post variables are commonly used for workflow routing, status updates, and passing values to downstream stages. For example: `next_stage`.
Post Variables	Expression	Defines the value assigned to the specified process variable after stage execution. Expressions may reference account identifiers, process parameters, stage variables, and system variables. For example: `book_processing_fees`.
Actions	Save Changes	Saves all stage configurations and updates the account stage definition within the workflow.

Stage Configuration - Update Account:

Section	Field	Description
General	Stage Name	Unique name used to identify the stage within the workflow. Use lowercase characters with no whitespace. Hyphens (`-`) and underscores (`_`) may be used. Example: `update_free_texts`.
General	Is It Initial Stage?	Indicates whether this stage is the starting point of the workflow execution.
General	Is It Final Stage?	Indicates whether this stage is the final stage of the workflow. Process execution completes after successful execution of a final stage.
General	Narration	Optional description associated with the account update operation. Useful for audit logs, operational tracking, and troubleshooting.
General	Update SubAccount?	Determines whether the update operation targets a sub-account instead of the primary account. When enabled, sub-account-specific fields become applicable during execution.
Stage Parameters	Input Parameters	Displays all parameters available to the stage. These parameters may be referenced using expressions such as `{{.account_id}}`, `{{.boid}}`, or `{{._mobile_number}}`.
Account Configuration	Product Account	Specifies the product account against which the update operation will be performed. The selected account must already exist within the product configuration.
Account Configuration	Account Slug	Defines the unique account identifier or account alias to be updated. Used by the system to locate the target account.
Account Configuration	Asset	Specifies the asset, instrument, currency, or account category associated with the update operation.
Account Configuration	Reporting Head	Defines the reporting classification associated with the account. Used for reporting, financial grouping, and management information systems.
Account Configuration	Sub Account Name	Specifies the name of the sub-account to be updated when the Update SubAccount option is enabled.
Account Configuration	Ledger Policy	Defines the ledger behavior or policy associated with the account. Used for accounting treatment, posting rules, and balance management.
Account Configuration	Account Status	Enables updating of the account status. Depending on implementation, this may be used to activate, suspend, block, close, freeze, or otherwise manage account operational status.
Account Configuration	FreeText 1	Optional metadata field used to update custom account information. Supports expressions and static values.
Account Configuration	FreeText 2	Optional metadata field used to update custom account information.
Account Configuration	FreeText 3	Optional metadata field used to update custom account information.
Account Configuration	FreeText 4	Optional metadata field used to update custom account information.
Account Configuration	FreeText 5	Optional metadata field used to update custom account information.
Account Configuration	FreeText 6	Optional metadata field used to update custom account information.
Account Configuration	FreeText 7	Optional metadata field used to update custom account information.
Account Configuration	FreeText 8	Optional metadata field used to update custom account information.
Account Configuration	FreeText 9	Optional metadata field used to update custom account information.
Account Configuration	FreeText 10	Optional metadata field used to update custom account information.
Account Configuration	FreeText 11	Optional metadata field used to update custom account information.
Account Configuration	FreeText 12	Optional metadata field used to update custom account information.
Account Configuration	FreeText 13–25	Additional metadata fields available for storing business-specific information such as customer attributes, regulatory identifiers, risk classifications, integration references, external system IDs, account classifications, or operational flags.
Webhook Config	Header Name	Specifies the HTTP header name to be included in webhook requests triggered by the stage. Example: `Authorization`.
Webhook Config	Header Value	Specifies the value associated with the configured HTTP header. Supports static values and expressions.
Webhook Config	Add Header	Adds an additional HTTP header to the webhook request configuration.
Webhook Config	Delete Header	Removes an existing webhook header configuration.
Webhook Config	Payload	Defines the payload body sent through the webhook. Supports expressions, variables, and process parameters.
Post Variables	Variable Name	Defines the process variable that will be updated after successful completion of the stage. Commonly used for workflow routing. Example: `next_stage`.
Post Variables	Expression	Defines the value or expression assigned to the post-processing variable. Example: `initiate_loan_pledge`.
Navigation	Save Changes	Saves the account update stage configuration and makes it available for workflow execution.

Table Stage

What it does: The Table Stage is used to create, update, or maintain structured records in a configurable database table within the ledger workflow. It allows process data, calculated values, customer attributes, risk assessment results, or external system responses to be persisted as table records for future reference, reporting, compliance checks, or downstream processing.

The stage uses a configurable table definition where each column can be dynamically populated using expressions, process variables, account information, API responses, or calculated outputs from previous stages. This enables workflows to maintain historical snapshots, audit data, credit bureau information, scoring results, customer metadata, and other business-specific records without requiring custom development.
Operational Use Case: During a loan origination or customer onboarding process, multiple external and internal validations may generate information that must be stored independently from the account ledger. For example, after receiving a credit bureau response, the workflow may need to save the customer's credit score, blacklist status, overdue amounts, risk category, and related metadata into a dedicated CIC Information Table.

By placing a Table Stage in the workflow, the process can persist these values into a structured table, making them available for reporting, audits, risk evaluation, future decision-making, and regulatory compliance checks. Subsequent workflow stages can then retrieve and use these stored records without needing to repeat external API calls or recalculations.

Stage Configuration:

Section	Field	Description
General	Stage Name	Unique name used to identify the stage within the workflow. Use lowercase characters with no whitespace. Hyphens (-) and underscores (_) may be used. Example: `cic_info_save`.
General	Is It Initial Stage?	Indicates whether this stage is the starting point of the workflow execution.
General	Is It Final Stage?	Indicates whether workflow processing should stop after this stage completes successfully.
General	Narration	Optional description or business note explaining the purpose of the stage.
Table Configuration	Select Table Type	Specifies the target table where records will be created or updated. The selected table determines which fields are available for mapping. Example: `cic_info`.
Table Configuration	Key	Unique identifier used to locate or create a table record. Typically mapped to an account ID, customer ID, or other business reference. Example: `{{.account_id}}`.
Table Configuration	Value Date	Business-effective date associated with the table record. Used for historical tracking and reporting.
Table Configuration	Table Fields	Dynamic field mappings belonging to the selected table. Each field can be populated using constants, expressions, process variables, or outputs from previous stages.
Table Field Mapping	total_active_blacklists	Stores the total number of active blacklist records returned by a bureau or validation service.
Table Field Mapping	score	Stores the customer credit score obtained from a bureau or scoring engine.
Table Field Mapping	score_category	Stores the risk category associated with the customer's credit score.
Table Field Mapping	overdue_status	Stores the customer's overdue status returned by external validation services.
Table Field Mapping	overdue_amount_upto90d	Stores the total overdue amount falling within the first 90-day overdue period.
Table Field Mapping	overdue_amount_over90d	Stores the total overdue amount exceeding 90 days.
Table Field Mapping	account_id	Stores the account identifier associated with the table record.
Webhook Configuration	Header	Defines HTTP headers that will be sent when the configured webhook is triggered after successful stage execution.
Webhook Configuration	Payload	Defines the request body transmitted to the webhook endpoint. Supports expressions and workflow variables.
Post Variables	Variable Name	Name of the workflow variable that will be created after successful execution of the stage.
Post Variables	Expression	Expression used to calculate or assign the value of the post variable. Example: `get_cicl_report`.
Actions	Save Changes	Saves the stage configuration and updates the workflow definition.

Form Stage

What it does: The Form Stage is used to present a configurable data entry form to users during workflow execution. It allows users to capture, update, validate, and submit business information that is required for subsequent workflow processing.

The stage can be linked to a predefined form configuration, enabling administrators to dynamically design data collection screens without requiring application changes. Submitted form data can be stored as process variables and made available to later stages for validation, decision-making, account processing, API integration, or reporting purposes.

The stage also supports parameter validation, expression-based checks, file response tracking, webhook integration, and post-processing variable creation, allowing both user interaction and system automation to occur within a single workflow step.
Operational Use Case: During a customer onboarding process, an organization may need to collect customer information such as personal details, account information, KYC data, employment details, or supporting documents. A Form Stage can be inserted into the workflow to display the required form and capture the necessary information from the user.

For example, during account verification, a form may collect account number, account status, and balance information. Once submitted, the workflow can validate the entered values, invoke external services through configured webhooks, store uploaded file references, and create process variables for use in subsequent stages such as account creation, approval, risk assessment, or customer onboarding.

Stage Configuration:

Section	Field	Description
General	Stage Name	Unique name used to identify the stage within the workflow. Use lowercase characters with no whitespace. Underscores (_) may be used. Example: `account_info`.
General	Is It Initial Stage?	Indicates whether this stage is the starting point of the workflow execution.
General	Is It Final Stage?	Indicates whether workflow processing should stop after this stage completes successfully.
General	Narration	Optional description or business note explaining the purpose of the stage.
Form Configuration	Select Form	Specifies the form definition that will be presented to the user during workflow execution. The selected form determines which fields are displayed and collected.
Form Configuration	Select Applicable Parameter Type	Defines the process parameters that will be associated with the form stage. Selected parameters become available for validation, mapping, and subsequent workflow processing.
Validation	Validate Expression	Expression used to validate submitted form data before allowing the workflow to proceed. The workflow will continue only if the expression evaluates successfully.
File Handling	File Response Id	Stores or references the identifier associated with uploaded files or file-processing responses generated during form submission.
Webhook Configuration	Header	Defines HTTP headers that will be included when the configured webhook is triggered after successful form submission.
Webhook Configuration	Payload	Defines the request body transmitted to the webhook endpoint. Supports expressions, form values, process variables, and outputs from previous stages.
Post Variables	Variable Name	Name of the workflow variable that will be created or updated after successful execution of the stage.
Post Variables	Expression	Expression used to calculate, transform, or assign the value of the post variable.
Actions	Save Changes	Saves the stage configuration and updates the workflow definition.

Transaction Stage

What it does: The Transaction Stage is used to initiate and record financial transactions within a workflow. It enables the process to create ledger entries, execute account-based transactions, post financial movements, and maintain transaction records against accounts or business entities.

The stage can be configured to invoke another process and execute a specific transaction stage within that process. Transaction details such as reference identifiers, transaction dates, amounts, account references, and custom transaction attributes can be dynamically populated using process variables, expressions, account data, API responses, or outputs generated by previous workflow stages.

This stage ensures that financial transactions are executed consistently while maintaining complete traceability, auditability, and integration with the ledger system.
Operational Use Case: During a loan disbursement workflow, the system may need to create accounting entries that transfer funds from a loan pool account to a customer's account. After all eligibility checks, approvals, and validations have been completed, a Transaction Stage can be used to initiate the actual financial transaction.

For example, the stage may invoke a predefined loan disbursement process, pass the approved loan amount, account identifiers, transaction date, reference number, and related transaction details, and then post the required ledger entries. The transaction record becomes available for reporting, reconciliation, auditing, customer servicing, and downstream financial operations.

Stage Configuration:

Section	Field	Description
General	Stage Name	Unique identifier for the stage within the workflow. The name must contain only lowercase letters (`a-z`), numbers (`0-9`), and underscores (`_`). Spaces and special characters are not permitted. Example: `initiate_loan_pledge`.
General	Is It Initial Stage?	Indicates whether this stage is the starting point of the workflow execution.
General	Is It Final Stage?	Indicates whether workflow processing should stop after this stage completes successfully.
General	State Type	Defines the transaction outcome state associated with the stage. Common values include Success and Failure.
General	Narration	Optional description or business note explaining the purpose of the transaction stage.
Transaction Configuration	Select Multi Object	Specifies the transaction object or transaction template that will be used during execution. Available fields depend on the selected configuration.
Transaction Configuration	Select Process	Specifies the target process that contains the transaction definition to be executed.
Transaction Configuration	Select Process Stage	Specifies the transaction stage within the selected process that will be invoked during execution.
Transaction Configuration	Value Date	Business-effective date for the transaction. Used for accounting, reporting, and reconciliation purposes.
Transaction Configuration	Ref ID	Unique business reference associated with the transaction. Commonly used for traceability, reconciliation, and audit purposes.
Transaction Configuration	Journal Amount	Monetary amount that will be posted through the transaction. Supports expressions and process variables.
Transaction Configuration	Narration	Transaction-specific description that will be stored along with the financial transaction record.
Transaction Mapping	Dynamic Fields	Additional transaction attributes exposed by the selected transaction process. Each field can be populated using constants, expressions, process variables, account information, API responses, or outputs from previous workflow stages. Examples include account IDs, customer references, transaction dates, loan identifiers, security details, and calculated amounts.
Webhook Configuration	Header	Defines HTTP headers that will be sent when the configured webhook is triggered after successful transaction execution.
Webhook Configuration	Payload	Defines the request body transmitted to the webhook endpoint. Supports expressions, transaction values, and workflow variables.
Post Variables	Variable Name	Name of the workflow variable that will be created or updated after successful execution of the stage.
Post Variables	Expression	Expression used to calculate, transform, or assign the value of the post variable.
Actions	Save Changes	Saves the stage configuration and updates the workflow definition.

Report Stage

What it does: The Report Stage is used to generate, display, or process predefined reports during workflow execution. It allows workflows to retrieve information from the system and present it using a configured report or view definition.

The stage can consume process variables, account information, customer identifiers, transaction references, API responses, and outputs from previous stages to generate report data dynamically. Reports can be used for customer inquiries, operational reviews, valuation summaries, transaction details, compliance checks, audit verification, and management reporting.

Depending on the configured action, the stage can either display report information to users, generate report outputs for further processing, or execute report-related operations within the workflow.
Operational Use Case: During a share-backed loan process, users may need to review the latest share valuation details before proceeding with pledge creation or loan approval. A Report Stage can be configured to retrieve and display the valuation report based on a customer account, BOID, or transaction reference.

For example, after receiving valuation information from an external system, the workflow can invoke a report that displays the customer's holdings, valuation amount, eligible loan amount, and related investment details. Users can review the report data before making business decisions, while subsequent workflow stages can continue processing based on the report results without requiring additional system queries.

Stage Configuration:

Section	Field	Description
General	Stage Name	Unique identifier for the stage within the workflow. The name must contain only lowercase letters (`a-z`), numbers (`0-9`), and underscores (`_`). Spaces and special characters are not permitted. Example: `view_details`.
General	Is It Initial Stage?	Indicates whether this stage is the starting point of the workflow execution.
General	Is It Final Stage?	Indicates whether workflow processing should stop after this stage completes successfully.
General	Narration	Optional description or business note explaining the purpose of the stage.
Report Configuration	Select View	Specifies the report or view definition that will be executed during workflow processing. The selected view determines the report structure and available parameters.
Report Configuration	Select Action	Specifies the operation that will be performed using the selected report. Actions may include displaying, generating, saving, exporting, or processing report data based on system configuration.
Report Parameters	Dynamic Parameters	Parameters required by the selected report or action. Each parameter can be populated using constants, expressions, process variables, account information, API responses, or outputs from previous workflow stages. Example: `boid`, `account_id`, or customer reference values.
Webhook Configuration	Header	Defines HTTP headers that will be sent when the configured webhook is triggered after successful report execution.
Webhook Configuration	Payload	Defines the request body transmitted to the webhook endpoint. Supports expressions, report values, and workflow variables.
Post Variables	Variable Name	Name of the workflow variable that will be created or updated after successful execution of the stage.
Post Variables	Expression	Expression used to calculate, transform, or assign the value of the post variable.
Actions	Save Changes	Saves the stage configuration and updates the workflow definition.

Feed Stage

What it does: The Feed Stage is used to create and maintain feed records within the ledger system. It enables workflows to capture, categorize, and store operational or financial information into configurable feed structures that can be used for reporting, reconciliation, analytics, auditing, and downstream processing.

The stage supports dynamic value mapping using process variables, expressions, account information, API responses, and outputs from previous workflow stages. Depending on the selected feed operation, the stage can either create a feed source record or post transaction information against an existing feed source.
Operational Use Case: During a loan processing workflow, the institution may need to maintain reporting and reconciliation data separately from the transactional ledger. For example, after a loan disbursement is completed, the workflow can create a feed source representing the loan record and subsequently create feed postings that capture disbursements, repayments, charges, adjustments, or other financial events.

These feed records can then be used by reporting systems, reconciliation processes, management dashboards, regulatory reporting tools, and audit functions without directly querying operational transaction tables.

Stage Configuration - Add Feed Source

Section	Field	Description
General	Stage Name	Unique identifier for the stage within the workflow. The name must contain only lowercase letters (`a-z`), numbers (`0-9`), and underscores (`_`). Spaces and special characters are not permitted. Example: `create_loan_feed_source`.
General	Is It Initial Stage?	Indicates whether this stage is the starting point of the workflow execution.
General	Is It Final Stage?	Indicates whether workflow processing should stop after this stage completes successfully.
General	Narration	Optional description or business note explaining the purpose of the stage.
Feed Source Configuration	Select Feed Type	Specifies the feed definition where the source record will be created.
Feed Source Configuration	Account Name	Account or business entity associated with the feed source record.
Feed Source Configuration	Reporting Group ID	Reporting category used to group related feed records.
Feed Source Configuration	Source Ref ID	Unique identifier associated with the feed source record.
Feed Source Configuration	Dynamic Feed Source Fields	Additional feed source attributes exposed by the selected feed type. These fields can be populated using expressions, constants, process variables, API responses, or outputs from previous stages.
Webhook Configuration	Header	Defines HTTP headers that will be sent when the configured webhook is triggered after successful stage execution.
Webhook Configuration	Payload	Defines the request body transmitted to the webhook endpoint. Supports expressions and workflow variables.
Post Variables	Variable Name	Name of the workflow variable that will be created after successful execution of the stage.
Post Variables	Expression	Expression used to calculate or assign the value of the post variable.
Actions	Save Changes	Saves the stage configuration and updates the workflow definition.

Stage Configuration - Add Feed Posting

Section	Field	Description
General	Stage Name	Unique identifier for the stage within the workflow. The name must contain only lowercase letters (`a-z`), numbers (`0-9`), and underscores (`_`). Spaces and special characters are not permitted. Example: `post_loan_feed`.
General	Is It Initial Stage?	Indicates whether this stage is the starting point of the workflow execution.
General	Is It Final Stage?	Indicates whether workflow processing should stop after this stage completes successfully.
General	Narration	Optional description or business note explaining the purpose of the stage.
Feed Posting Configuration	Source ID	Identifier of the feed source against which the posting will be recorded.
Feed Posting Configuration	Reporting Group ID	Reporting category associated with the feed posting.
Feed Posting Configuration	Value Date	Business-effective date of the feed posting.
Feed Posting Configuration	Amount	Monetary amount associated with the feed posting.
Feed Posting Configuration	Transaction Type	Business transaction category being recorded.
Feed Posting Configuration	Posting Type	Classification that determines how the posting is categorized within the feed structure.
Feed Posting Configuration	Closing Balance	Balance value associated with the posting after processing.
Feed Posting Configuration	Reference ID	Unique business reference used for reconciliation and auditing purposes.
Feed Posting Configuration	Free Text 1	Optional custom information field.
Feed Posting Configuration	Free Text 2	Optional custom information field.
Feed Posting Configuration	Free Text 3	Optional custom information field.
Feed Posting Configuration	Free Text 4	Optional custom information field.
Feed Posting Configuration	Free Text 5	Optional custom information field.
Webhook Configuration	Header	Defines HTTP headers that will be sent when the configured webhook is triggered after successful stage execution.
Webhook Configuration	Payload	Defines the request body transmitted to the webhook endpoint. Supports expressions and workflow variables.
Post Variables	Variable Name	Name of the workflow variable that will be created after successful execution of the stage.
Post Variables	Expression	Expression used to calculate or assign the value of the post variable.
Actions	Save Changes	Saves the stage configuration and updates the workflow definition.

Contract Stage

What it does: The Contract Stage is used to create, maintain, and execute contract-based records within the workflow. It enables processes to establish contractual relationships, define business agreements, track contract attributes, and perform contract-related operations based on predefined contract configurations.

The stage supports dynamic data mapping using process variables, expressions, account information, API responses, and outputs from previous workflow stages. Depending on the selected operation, the stage can either create a new contract record or execute an action against an existing contract.

Contract stages are commonly used for loan agreements, pledge agreements, service contracts, collateral contracts, investment agreements, subscription contracts, and other business arrangements that require lifecycle management within the system.
Operational Use Case: During a share-backed lending process, the institution may need to create a pledge contract linking a customer's securities to a loan facility. After all validations and approvals are completed, a Contract Stage can create the contract record containing the relevant customer information, contract type, reference identifiers, and contractual attributes.

Subsequently, another Contract Stage may execute actions against the created contract, such as activating, cancelling, renewing, settling, or updating the contract status based on workflow decisions or business events. This allows the entire contract lifecycle to be managed through workflow automation while maintaining complete traceability and auditability.

Stage Configuration - Add Contract

Section	Field	Description
General	Stage Name	Unique identifier for the stage within the workflow. The name must contain only lowercase letters (`a-z`), numbers (`0-9`), and underscores (`_`). Spaces and special characters are not permitted. Example: `create_pledge_contract`.
General	Is It Initial Stage?	Indicates whether this stage is the starting point of the workflow execution.
General	Is It Final Stage?	Indicates whether workflow processing should stop after this stage completes successfully.
General	Narration	Optional description or business note explaining the purpose of the stage.
Contract Configuration	Select Multi Object	Specifies the contract definition or contract object that will be used to create the contract record.
Contract Configuration	Select Contract Type	Defines the type of contract being created. The selected contract type determines the available contract attributes and business rules.
Contract Configuration	Select Date	Effective date associated with the contract creation.
Contract Configuration	Batch ID	Optional identifier used to group multiple contract records under a common batch operation.
Contract Configuration	Ref ID	Unique business reference associated with the contract record. Used for tracking, reconciliation, and audit purposes.
Contract Configuration	Dynamic Contract Fields	Additional contract attributes exposed by the selected contract type. These fields can be populated using constants, expressions, process variables, account information, API responses, or outputs generated from previous workflow stages.
Webhook Configuration	Header	Defines HTTP headers that will be sent when the configured webhook is triggered after successful stage execution.
Webhook Configuration	Payload	Defines the request body transmitted to the webhook endpoint. Supports expressions and workflow variables.
Post Variables	Variable Name	Name of the workflow variable that will be created after successful execution of the stage.
Post Variables	Expression	Expression used to calculate or assign the value of the post variable.
Actions	Save Changes	Saves the stage configuration and updates the workflow definition.

Stage Configuration - Execute Contract

Section	Field	Description
General	Stage Name	Unique identifier for the stage within the workflow. The name must contain only lowercase letters (`a-z`), numbers (`0-9`), and underscores (`_`). Spaces and special characters are not permitted. Example: `execute_pledge_contract`.
General	Is It Initial Stage?	Indicates whether this stage is the starting point of the workflow execution.
General	Is It Final Stage?	Indicates whether workflow processing should stop after this stage completes successfully.
General	Narration	Optional description or business note explaining the purpose of the stage.
Contract Execution Configuration	Enter Contract Type	Specifies the contract type against which the operation will be performed.
Contract Execution Configuration	Date Less Than	Defines the contract date criteria used to identify eligible contracts for execution.
Contract Execution Configuration	Batch ID	Optional batch identifier used to locate a group of contract records for processing.
Contract Execution Configuration	Ref ID	Business reference used to identify the target contract record.
Contract Execution Configuration	Cancel	Indicates whether the selected contract should be cancelled during execution.
Webhook Configuration	Header	Defines HTTP headers that will be sent when the configured webhook is triggered after successful stage execution.
Webhook Configuration	Payload	Defines the request body transmitted to the webhook endpoint. Supports expressions and workflow variables.
Post Variables	Variable Name	Name of the workflow variable that will be created after successful execution of the stage.
Post Variables	Expression	Expression used to calculate or assign the value of the post variable.
Actions	Save Changes	Saves the stage configuration and updates the workflow definition.

Reversal Stage

What it does: The Reversal Stage is used to reverse previously executed financial or operational transactions within the ledger system. It enables workflows to identify existing journal entries and generate corresponding reversal entries, ensuring that incorrect, cancelled, failed, or superseded transactions can be safely undone while maintaining a complete audit trail.

The stage supports dynamic value mapping using process variables, expressions, account information, transaction references, API responses, and outputs from previous workflow stages. Reversals are performed against existing journal records and preserve transactional traceability for reconciliation, compliance, and auditing purposes.
Operational Use Case: During a loan processing workflow, a transaction may need to be reversed due to cancellation, validation failure, duplicate processing, or business rule violations. For example, if a loan disbursement is posted successfully but later fails a downstream verification check, the workflow can trigger a Reversal Stage to reverse the previously posted journal entries.

This ensures that account balances, reporting records, and financial statements remain accurate while preserving a complete history of both the original transaction and its reversal for audit and compliance requirements.

Stage Configuration:

Section	Field	Description
General	Stage Name	Unique identifier for the stage within the workflow. The name must contain only lowercase letters (`a-z`), numbers (`0-9`), and underscores (`_`). Spaces and special characters are not permitted. Example: `reverse_disbursement`.
General	Is It Initial Stage?	Indicates whether this stage is the starting point of the workflow execution.
General	Is It Final Stage?	Indicates whether workflow processing should stop after this stage completes successfully.
General	Narration	Optional description or business note explaining the purpose of the stage.
Reversal Configuration	Ref ID	Unique business reference associated with the transaction or journal entry that needs to be reversed. Used to identify the target transaction.
Reversal Configuration	Slug	Unique reversal identifier or transaction key used to locate the reversal configuration or target transaction record.
Reversal Configuration	Journal ID	Identifier of the journal entry that will be reversed. The system uses this value to locate and generate the corresponding reversal entries.
Webhook Configuration	Header	Defines HTTP headers that will be sent when the configured webhook is triggered after successful stage execution.
Webhook Configuration	Payload	Defines the request body transmitted to the webhook endpoint. Supports expressions and workflow variables.
Post Variables	Variable Name	Name of the workflow variable that will be created after successful execution of the stage.
Post Variables	Expression	Expression used to calculate or assign the value of the post variable.
Actions	Save Changes	Saves the stage configuration and updates the workflow definition.

Wait Stage

What it does: The Wait Stage is used to pause workflow execution until a specified process and stage reach a required state or completion point. It allows workflows to synchronize with external processes, dependent workflows, asynchronous operations, approvals, or long running business activities before continuing execution.

The stage supports dynamic value mapping using workflow variables, expressions, transaction references, process identifiers, and outputs from previous stages. Once the configured process and stage conditions are satisfied, workflow execution automatically resumes and proceeds to the next configured stage.
Operational Use Case: During a loan disbursement workflow, funds may be transferred through a separate payment process. The primary workflow can use a Wait Stage to pause execution until the payment process reaches a successful completion stage. Once the transfer process is completed, the workflow automatically resumes and continues with post disbursement activities such as notifications, reporting, or reconciliation.

This mechanism ensures that dependent operations occur in the correct sequence while preventing premature execution of downstream stages.

Stage Configuration:

Section	Field	Description
General	Stage Name	Unique identifier for the stage within the workflow. The name must contain only lowercase letters (`a-z`), numbers (`0-9`), and underscores (`_`). Spaces and special characters are not permitted. Example: `wait_for_transfer`.
General	Is It Initial Stage?	Indicates whether this stage is the starting point of the workflow execution.
General	Is It Final Stage?	Indicates whether workflow processing should stop after this stage completes successfully.
General	Narration	Optional description or business note explaining the purpose of the stage.
Wait Configuration	Ref ID	Reference identifier used to correlate the workflow instance with the target process, transaction, or business record being monitored.
Wait Configuration	Process Slug	Unique identifier of the process that the workflow should wait for before resuming execution.
Wait Configuration	Stage Slug	Specific stage within the selected process that must be completed before the workflow continues.
Webhook Configuration	Header	Defines HTTP headers that will be sent when the configured webhook is triggered after successful stage execution.
Webhook Configuration	Payload	Defines the request body transmitted to the webhook endpoint. Supports expressions and workflow variables.
Post Variables	Variable Name	Name of the workflow variable that will be created after successful execution of the stage.
Post Variables	Expression	Expression used to calculate or assign the value of the post variable.
Actions	Save Changes	Saves the stage configuration and updates the workflow definition.

Policy Stage

What it does: The Policy Stage is used to create and manage transaction control policies within the ledger system. Policies define operational rules that govern how accounts can be used by enforcing transaction limits, balance restrictions, and aggregated transaction thresholds. These controls help ensure compliance with business rules, risk management requirements, and financial governance standards.

The stage supports dynamic value mapping using workflow variables, expressions, API responses, account data, and outputs from previous stages. Policies can be configured to restrict credit transactions, debit transactions, account balances, transaction frequency, and cumulative transaction amounts over predefined periods.
Operational Use Case: Financial institutions often need to enforce limits on account activity to prevent fraud, manage risk exposure, and comply with regulatory requirements. For example, a savings account may be restricted to a maximum daily debit amount, minimum balance requirement, or a maximum number of debit transactions within a specific period.

During workflow execution, the Policy Stage can create or update these restrictions automatically, ensuring that account behavior remains within approved operational boundaries while supporting auditability and compliance monitoring.

Stage Configuration - Add Policy

Section	Field	Description
General	Stage Name	Unique identifier for the stage within the workflow. The name must contain only lowercase letters (`a-z`), numbers (`0-9`), and underscores (`_`). Spaces and special characters are not permitted. Example: `add_policy`.
General	Is It Initial Stage?	Indicates whether this stage is the starting point of the workflow execution.
General	Is It Final Stage?	Indicates whether workflow processing should stop after this stage completes successfully.
General	Narration	Optional description or business note explaining the purpose of the stage.
Policy Configuration	Policy Reference	Unique identifier or reference code used to create the policy within the ledger system.
Policy Configuration	Allowed Transaction Types	Defines which transaction types are permitted under the policy. Available options include Credit, Debit, or Both.
Policy Configuration	Allowed Balance Type	Defines which balance type restrictions apply. Available options include Credit, Debit, or Both.
Transaction Limits	Minimum Credit Amount	Minimum credit transaction amount allowed under the policy.
Transaction Limits	Minimum Debit Amount	Minimum debit transaction amount allowed under the policy.
Transaction Limits	Maximum Credit Amount	Maximum credit transaction amount allowed under the policy.
Transaction Limits	Maximum Debit Amount	Maximum debit transaction amount allowed under the policy.
Balance Limits	Minimum Credit Balance	Minimum allowed credit balance that must be maintained.
Balance Limits	Minimum Debit Balance	Minimum allowed debit balance that must be maintained.
Balance Limits	Maximum Credit Balance	Maximum allowed credit balance threshold.
Balance Limits	Maximum Debit Balance	Maximum allowed debit balance threshold.
Aggregated Policies	Slug	Identifier of an aggregated policy rule to be attached to the policy configuration.
Aggregated Policies	Maximum Credit Amount	Maximum cumulative credit amount allowed within the aggregation period.
Aggregated Policies	Maximum Debit Amount	Maximum cumulative debit amount allowed within the aggregation period.
Aggregated Policies	Maximum Credit Count	Maximum number of credit transactions allowed within the aggregation period.
Aggregated Policies	Maximum Debit Count	Maximum number of debit transactions allowed within the aggregation period.
Webhook Configuration	Header	Defines HTTP headers that will be sent when the configured webhook is triggered after successful stage execution.
Webhook Configuration	Payload	Defines the request body transmitted to the webhook endpoint. Supports expressions and workflow variables.
Post Variables	Variable Name	Name of the workflow variable that will be created after successful execution of the stage.
Post Variables	Expression	Expression used to calculate or assign the value of the post variable.
Actions	Save Changes	Saves the stage configuration and updates the workflow definition.

Stage Configuration - Update Policy

Section	Field	Description
General	Stage Name	Unique identifier for the stage within the workflow. The name must contain only lowercase letters (`a-z`), numbers (`0-9`), and underscores (`_`). Spaces and special characters are not permitted. Example: `update_policy`.
General	Is It Initial Stage?	Indicates whether this stage is the starting point of the workflow execution.
General	Is It Final Stage?	Indicates whether workflow processing should stop after this stage completes successfully.
General	Narration	Optional description or business note explaining the purpose of the stage.
Policy Configuration	Policy Reference	Unique identifier of the existing policy that will be updated.
Policy Configuration	Allowed Transaction Types	Updates the transaction types permitted under the policy. Available options include Credit, Debit, or Both.
Policy Configuration	Allowed Balance Type	Updates the balance restriction type applied to the policy. Available options include Credit, Debit, or Both.
Transaction Limits	Minimum Credit Amount	Updates the minimum credit transaction amount allowed under the policy.
Transaction Limits	Minimum Debit Amount	Updates the minimum debit transaction amount allowed under the policy.
Transaction Limits	Maximum Credit Amount	Updates the maximum credit transaction amount allowed under the policy.
Transaction Limits	Maximum Debit Amount	Updates the maximum debit transaction amount allowed under the policy.
Balance Limits	Minimum Credit Balance	Updates the minimum credit balance requirement.
Balance Limits	Minimum Debit Balance	Updates the minimum debit balance requirement.
Balance Limits	Maximum Credit Balance	Updates the maximum credit balance threshold.
Balance Limits	Maximum Debit Balance	Updates the maximum debit balance threshold.
Aggregated Policies	Slug	Identifier of the aggregated policy rule that will be updated or associated with the policy.
Aggregated Policies	Maximum Credit Amount	Updates the cumulative credit amount limit for the aggregation period.
Aggregated Policies	Maximum Debit Amount	Updates the cumulative debit amount limit for the aggregation period.
Aggregated Policies	Maximum Credit Count	Updates the maximum number of allowed credit transactions within the aggregation period.
Aggregated Policies	Maximum Debit Count	Updates the maximum number of allowed debit transactions within the aggregation period.
Webhook Configuration	Header	Defines HTTP headers that will be sent when the configured webhook is triggered after successful stage execution.
Webhook Configuration	Payload	Defines the request body transmitted to the webhook endpoint. Supports expressions and workflow variables.
Post Variables	Variable Name	Name of the workflow variable that will be created after successful execution of the stage.
Post Variables	Expression	Expression used to calculate or assign the value of the post variable.
Actions	Save Changes	Saves the stage configuration and updates the workflow definition.

Reporting Group Stage

What it does: The Reporting Group Stage is used to create reporting groups within the ledger system. Reporting groups provide a logical mechanism for organizing accounts, transactions, balances, and reporting structures so that financial data can be grouped, monitored, and analyzed according to business requirements.

The stage supports dynamic value mapping using workflow variables, expressions, API responses, account information, and outputs from previous workflow stages. Reporting groups can be used to classify financial records by product, branch, department, business unit, customer segment, or any other reporting dimension required for operational monitoring and financial reporting.
Operational Use Case: Organizations often require financial information to be grouped for management reporting, regulatory reporting, and business analysis. For example, a bank may create separate reporting groups for retail banking, corporate banking, and digital lending portfolios.

During workflow execution, the Reporting Group Stage can automatically create reporting groups that are later referenced by accounts, feeds, policies, and transactions. This ensures that ledger data remains organized and can be aggregated accurately for reporting, reconciliation, and performance analysis.

Stage Configuration:

Section	Field	Description
General	Stage Name	Unique identifier for the stage within the workflow. The name must contain only lowercase letters (`a-z`), numbers (`0-9`), and underscores (`_`). Spaces and special characters are not permitted. Example: `create_reporting_group`.
General	Is It Initial Stage?	Indicates whether this stage is the starting point of the workflow execution.
General	Is It Final Stage?	Indicates whether workflow processing should stop after this stage completes successfully.
General	Narration	Optional description or business note explaining the purpose of the stage.
Reporting Group Configuration	Reporting Group ID	Unique identifier assigned to the reporting group being created. This value can be referenced by other workflow stages and ledger entities.
Reporting Group Configuration	Open Date	Effective start date from which the reporting group becomes active and available for reporting operations.
Reporting Group Configuration	Close Date	Optional end date after which the reporting group is considered inactive and no longer available for new reporting assignments.
Webhook Configuration	Header	Defines HTTP headers that will be sent when the configured webhook is triggered after successful stage execution.
Webhook Configuration	Payload	Defines the request body transmitted to the webhook endpoint. Supports expressions and workflow variables.
Post Variables	Variable Name	Name of the workflow variable that will be created after successful execution of the stage.
Post Variables	Expression	Expression used to calculate or assign the value of the post variable.
Actions	Save Changes	Saves the stage configuration and updates the workflow definition.

Understanding Parameters​

Why are Parameters Important?​

Parameter Types​

Why Choosing the Correct Parameter Type Matters​

Understanding Process Variables​

Configuring stages in a process​

Journal Stage​

API Stage​

Tariff Stage​

Account Stage​

Table Stage​

Form Stage​

Transaction Stage​

Report Stage​

Feed Stage​

Contract Stage​

Reversal Stage​

Wait Stage​

Policy Stage​

Reporting Group Stage​

Understanding Parameters

Why are Parameters Important?

Parameter Types

Why Choosing the Correct Parameter Type Matters

Understanding Process Variables

Configuring stages in a process

Journal Stage

API Stage

Tariff Stage

Account Stage

Table Stage

Form Stage

Transaction Stage

Report Stage

Feed Stage

Contract Stage

Reversal Stage

Wait Stage

Policy Stage

Reporting Group Stage