Process Overview

A process defines a workflow in Lowgile. It controls how data moves through a series of steps, how tasks are assigned, and how decisions are made.

Processes are implemented using BPMN-based workflow diagrams that define workflow steps, routing, task assignment, and process behaviour.

Processes are central to building process-driven applications in Lowgile.

Why a visual process model matters

Using a visual process model allows workflows to be designed as diagrams rather than implemented directly in code.

Instead of writing complex conditional logic, routing rules, and task assignment behaviour in application code, Lowgile uses connected workflow elements to visually represent the process.

For example, an approval workflow could be represented in pseudocode as follows:

if (data.isApproved) {
  completeTask("Approve Task");
  assignTask("Next Step", "Procurement");
  return "approve";
}

completeTask("Approve Task");
assignTask("Reject Step", "Requester");
return "reject";

The visual process model provides a simpler and more maintainable way to represent the same workflow.

This makes it easier to:

• Understand the workflow at a glance
• Collaborate with non-technical stakeholders
• Maintain and update workflows over time
• Visualize routing and task assignment behaviour

🧩

Principle

A process model replaces complex control flow in code with a visual representation of routing, decisions, and task assignment.

In Lowgile, the process model is the source of truth for workflow execution.

BPMN process diagrams

Processes in Lowgile are defined using BPMN (Business Process Model and Notation) diagrams.

The BPMN diagram represents the executable workflow, including:

• Workflow stages
• Task assignment
• Routing behaviour
• User interaction points
• Process transitions

Processes are designed using a visual BPMN editor.

Key design elements include:

• Swim lanes: Define responsibility and ownership
• Task assignment: Determines who performs each step
• Routing logic: Determines how decisions are evaluated and which route is selected

🧩

Principle

Processes define how work flows, while screens define how users interact with this work.

What a process does

A process represents a sequence of activities that:

• Capture user input
• Execute business logic
• Route tasks between users
• Update workflow data
• Control how work moves through the application

A process typically includes:

• Start events: Where the process begins
• User tasks: Steps requiring user interaction
• System actions: Automated logic or updates
• Routes: Define workflow transitions
• End events: Where the process completes

Working with multiple Processes

A Lowgile application can contain more than one Process. Each Process has its own definition and configuration, so first confirm which Process you are configuring and which Process the application is running.

Configure the intended Process

Process Access Control applies to the Process selected under Covered business objects on the Process tab. Before configuring a restriction such as start, select the intended Process. Configuring the restriction for one Process does not configure another Process in the same application.

Start the intended Process from a screen

A screen action must reference the Process it should start explicitly. The Process name in the $Process expression identifies the Process that the screen starts:

await This.$Process.PurchaseRequestProcessing.start({
  request: screen.request
})

If the screen should start a different Process, update the Process name in the action and save the screen.

Confirm which Process is running

Runtime task details identify the Process that created the task through processBoId. For example:

processBoId: PurchaseRequestProcessing

When runtime behavior does not match the Process you intended to test, use processBoId to confirm which Process is running before changing its task or route configuration.

Test and troubleshoot

When testing an application that contains multiple Processes:

1. Confirm that the starting screen calls This.$Process.<ProcessName>.start(...) for the intended Process.
2. Confirm that the same Process is selected under Covered business objects and that its start restriction is configured.
3. Start a new Process instance.
4. If the resulting tasks or routes are unexpected, check processBoId in the runtime task details.
5. Troubleshoot the Process definition only after confirming that the intended Process is running.

Process instances

Each time a process starts, a new process instance is created.

A process defines the reusable workflow model, while a process instance represents a single execution of that workflow.

A process instance:

• Tracks the current workflow step
• Stores process data
• Creates and manages tasks
• Maintains workflow state during execution

🧠

Key Lesson

A process defines the workflow. A process instance represents a single run of that workflow.

How Process instances, tokens, and User Tasks relate

• A Process definition is the reusable BPMN model that defines the workflow.
• A Process instance is one execution of that definition, including its data and history.
• A token is runtime execution state that identifies the active path and position within a specific Process instance.
• A User Task is an activity in the BPMN model. When execution reaches it, Lowgile creates the corresponding runtime task for eligible users.

The lifecycle is: start a Process instance → reach a User Task → create its runtime task → complete the task to select a route and advance execution.

Existing tasks and execution state belong to a particular running Process instance. After changing Process task configuration, start a new Process instance and test the newly created tasks.

State transitions

Each stage in the workflow represents a process state.

A state transition occurs when the process moves from one stage to another.

Transitions can be triggered by:

• User actions
• Decision logic
• Process routes
• Automated system actions

These transitions are defined visually in the process model.

Runtime process behaviour

At runtime, a process behaves as follows:

• Executes a sequence of workflow steps
• Creates and assigns tasks to users or roles
• Evaluates process routes
• Determines the next workflow step
• Updates workflow data and state

All workflow behaviour is defined in the process model using BPMN, rather than being implemented directly in the user interface.

How processes connect to other objects

A process coordinates several object types during workflow execution.

Object	Role
Screen	Displays task screens where users review, enter, or update workflow data.
Entity	Provides the data the process reads, updates, or passes between workflow steps.
User roles	Determine who can receive and act on tasks in the process.

What this section covers

The process reference documentation includes:

• Process routes: How workflows move between steps based on returned values
• Task assignment: How responsibility is defined and applied at runtime
• Process instances: How workflow executions are created and managed
• Lifecycle behaviour: How a process is started, executed, and completed

Relationship to other documentation

• For screen event handlers that call Processes, see Screen Concepts
• For Process operation permissions, see Access Control Fundamentals
• For Process runtime details, see How Process instances, tokens, and User Tasks relate
• For conceptual understanding, see Understanding BPMN Process Flows
• For workflow routing concepts, see Process Routes
• For task assignment concepts, see Task Assignment & Process Responsibility
• For route configuration and behaviour, see Process Routes Reference