# Execution Models

When designing backend logic or system integrations, **ONEWEB Microflow Designer** supports both **synchronous** and **asynchronous** execution models.\
Understanding the difference between these execution approaches is essential for designing **efficient, scalable, and user‑friendly** integrations.

Microflows can be configured to execute either synchronously or asynchronously depending on how results are expected to be consumed by the calling component.

***

### Synchronous Execution

A **synchronous execution model** is a **blocking operation**.\
The caller initiates the execution and waits until the Microflow finishes and returns a response before continuing.

#### Execution Behavior

* The calling component **waits for completion**
* Execution flow **pauses until a response is returned**
* The user or calling system **cannot proceed** while execution is in progress

#### Key Characteristics

* Blocking execution
* Immediate response required
* Best suited for short‑running operations

#### Typical Use Cases

* Immediate data validation
* Real‑time data retrieval
* Backend service calls that must return data before continuing

In ONEWEB, synchronous execution is commonly used when:

* A Microflow must **return data immediately**
* UI behavior depends directly on the Microflow response

***

### Asynchronous Execution

An **asynchronous execution model** is a **non‑blocking operation**.\
The caller triggers the Microflow and continues execution without waiting for the Microflow to complete.

#### Execution Behavior

* The Microflow runs **in the background**
* The caller proceeds immediately
* Results may be processed later or reflected through system updates

#### Key Characteristics

* Non‑blocking execution
* Supports background processing
* Improves responsiveness and parallelism

#### Typical Use Cases

* Long‑running business logic
* Background data processing
* Integration with slow or external systems
* Workflow initiation and orchestration

***

### Asynchronous Nature of Process Flow

A **Process Flow** in ONEWEB is **inherently asynchronous by design**.

When a process is triggered (for example, via a **Process Button**):

* The process starts execution
* The UI or calling component **does not wait** for completion

This behavior is intentional because:

* Processes may span **hours, days, or weeks**
* Waiting for completion would be impractical

#### Process Flow Is Best Suited For:

* Approval workflows
* Multi‑step business operations
* Integrations requiring human intervention
* Long‑running orchestration

> Process Designer should not be used for logic that requires immediate system feedback.

***

### Execution Control in Microflow

Unlike Process Flow, **Microflow Designer provides flexible execution control**, allowing Microflows to operate **either synchronously or asynchronously**.

#### Synchronous Microflow

* The caller waits for execution to complete
* Used when **immediate results** are required
* Common in UI‑triggered backend logic

#### Asynchronous Microflow

* Executed in the background
* The user can continue interacting with the UI
* Results may update system state later

ONEWEB also provides a **screen‑blocking configuration** when invoking Microflows:

* **Screen blocking enabled** → Synchronous behavior
* **Screen blocking disabled** → Asynchronous behavior

This gives developers **fine‑grained control** over both execution flow and user experience.

***

### Choosing the Appropriate Execution Model

Selecting the correct execution model directly impacts:

* Application responsiveness
* User experience
* System scalability

#### Choose **Synchronous Execution** when:

* Immediate results are required
* UI logic depends on the response
* Execution time is short

#### Choose **Asynchronous Execution** when:

* Logic is long‑running
* Scalability and responsiveness are important
* Execution should not block the user

***

### Summary

ONEWEB supports both **synchronous** and **asynchronous** execution models to accommodate diverse integration and processing requirements.

Key points:

* **Process Flow** is inherently asynchronous and designed for long‑running workflows
* **Microflow Designer** supports both synchronous and asynchronous execution
* Execution behavior is controlled through configuration, including screen‑blocking options
* Choosing the appropriate model ensures **better performance, scalability, and user experience**

Understanding how and when to use each execution model is a key aspect of designing **robust and enterprise‑grade Microflows** in the ONEWEB platform.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.onewebstack.com/oneweb-platform-th/designer-reference/microflow-designer/execution-models.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
