# Decision Flow vs. Integration Flow ### **Introduction** In DecisionRules, there are two main ways to execute a flow of rules: **Decision Flow** and **Integration Flow**.\ Both are used to link and evaluate multiple rules together, but they differ in execution, time limits, and how results are returned. The **Decision Flow** is intended for quick, real-time decisions, while the **Integration Flow** was created for cases where the evaluation might take longer than the standard execution time limit.\ This article provides a comparison of the two, explains why Integration Flow was introduced, and shows when to use each. ### **Why Integration Flow Was Created** The Decision Flow can handle most use cases where decisions need to be made quickly, within the allowed execution time (typically 1–8 seconds depending on your plan or environment settings for on-premise).\ However, for example **long-running processes retrieving a large number of database rows**, or **very large bulk input processing** can exceed this limit and cause timeouts. Integration Flow was created to solve this problem. It uses a background job infrastructure that has **24 hours for process**, allowing the evaluation to run until completion or until it is cancelled. ### **Key Differences**

	Decision Flow	Integration Flow
Evaluation	Uses `api.decisionrules.io/rule/solve/` endpoint and any Decision Table, Decision Tree, or Scripting rule.	Uses `api.decisionrules.io/job/start/` endpoint to trigger a background job.
Execution	Synchronous — you wait for the evaluation to finish and receive output in the same API response.	Asynchronous — starts a job, returns a `jobId`, and the results are retrieved later.
Time Limit	1–8 seconds for Decision Flow execution, API calls, and rule solve limit.	Job execution limit of 24 hours, 1–8 seconds API call and rule solve limit, and 5 minutes inactivity limit for database node queries.
Output Data	Returned directly in the same API response; the connection must remain open until it finishes.	Returned after job completion — either automatically via Webhook or by checking the job status using API with the `jobId`.
Best for	Quick decisions, small to medium complexity, smaller datasets.	Long-running processes, large datasets, complex decisions.

### **Use Cases** #### **Decision Flow** * **Typical decision-making with one input set** – most cases where only one set of input data is evaluated. * **Linking results of multiple partial rules** such as Decision Tables and Decision Trees. * **Multiple inputs of medium complexity** – can use the Bulk input approach unless the time limit is exceeded. * **External REST API calls** – possible, but must be tested to ensure they won’t cause timeouts. * **Databases** – suitable for smaller queries or single row lookups; larger queries may exceed time limits. #### **Integration Flow** * **Long-running REST API calls** – avoids timeouts from slow responses. * **Database queries returning large numbers of rows** – can process each row without time limits. * **Large bulk inputs / highly complex flows** – handles large datasets and complex logic where Decision Flow might time out. ### **Switching Between the Two** If you design a Decision Flow and find it cannot complete within the allotted time, you can **switch it to an Integration Flow** without losing your work.\ This allows you to start simple and then adapt to more demanding workloads when necessary.

### **Combining Decision Flow and Integration Flow** Sometimes, you need **both immediate decisions and large-scale processing**. For example: * **Immediate**: A frontend application needs to validate one record instantly. * **Batch**: A backend process needs to evaluate an entire database table. **Recommended approach:** 1. **Create a Decision Flow** for real-time evaluations of single inputs. 2. **Create an Integration Flow** that: * Retrieves bulk data from the database. * Sends each record to the Decision Flow for evaluation. * Stores the results back in the database. This way, you maintain **one central logic** in the Decision Flow, while also supporting both **fast** and **long-running** execution with Integration Flow. --- # 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.decisionrules.io/doc/rules/flow/decision-flow-vs.-integration-flow.md?ask= ``` 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.