From 1b19affcbb426472363d8a7e1e072b364e29c2d7 Mon Sep 17 00:00:00 2001 From: abdoruzaqi <245876665+abdoruzaqi@users.noreply.github.com> Date: Fri, 26 Jun 2026 01:37:06 +0000 Subject: [PATCH] docs: comprehensive user-first documentation overhaul - Reorganized documentation structure into Getting Started, Using the Builder, Core Actions, and Advanced Reference. - Renamed technical action names to business-friendly terminology (e.g., Condition -> Check, Assignment -> Set Value). - Isolated technical implementation details to the Advanced Reference section. - Updated all internal links and added aliases to maintain SEO and link stability. - Simplified language across all guides to focus on end-user workflows. - Verified site integrity with Hugo build. --- .../architecture/actions/_index.md | 29 ++++---- .../architecture/actions/advanced-process.md | 13 ++++ .../architecture/actions/condition.md | 2 +- .../architecture/actions/document-action.md | 66 ++++--------------- .../architecture/actions/entry.md | 2 +- .../architecture/actions/multi-path.md | 16 +++++ .../architecture/actions/query-records.md | 5 ++ .../architecture/actions/repeat.md | 13 ++++ .../architecture/actions/set-value.md | 21 ++++++ .../architecture/actions/sub-rule.md | 13 ++++ .../architecture/actions/wait.md | 13 ++++ .../architecture/engine/condition-system.md | 2 +- .../concepts/ai-features.md | 4 +- .../normalization-value-resolver.md | 4 +- ...ule-entry-condition-vs-condition-action.md | 4 +- .../action-documentation-standard.md | 2 +- .../reference/execution/condition.md | 4 +- .../reference/execution/stop.md | 2 +- content/en/core-actions/advanced-process.md | 23 +++++++ content/en/core-actions/assignment.md | 28 -------- content/en/core-actions/check.md | 30 +++++++++ content/en/core-actions/condition.md | 30 --------- content/en/core-actions/entry-action.md | 10 +-- content/en/core-actions/loop.md | 27 -------- content/en/core-actions/multi-path.md | 26 ++++++++ content/en/core-actions/notify-action.md | 16 ++--- content/en/core-actions/process.md | 21 ------ content/en/core-actions/query-records.md | 40 ++++------- content/en/core-actions/repeat.md | 27 ++++++++ content/en/core-actions/set-value.md | 28 ++++++++ content/en/core-actions/stop-error.md | 16 ++--- content/en/core-actions/sub-rule.md | 14 ++-- content/en/core-actions/switch.md | 26 -------- content/en/core-actions/update-record.md | 28 ++++---- content/en/core-actions/wait.md | 15 ++--- content/en/getting-started/introduction.md | 4 +- content/en/getting-started/quick-start.md | 6 +- .../adding-managing-actions.md | 14 ++-- .../en/using-the-builder/canvas-navigation.md | 14 ++-- 39 files changed, 351 insertions(+), 307 deletions(-) create mode 100644 content/en/advanced-reference/architecture/actions/advanced-process.md create mode 100644 content/en/advanced-reference/architecture/actions/multi-path.md create mode 100644 content/en/advanced-reference/architecture/actions/repeat.md create mode 100644 content/en/advanced-reference/architecture/actions/set-value.md create mode 100644 content/en/advanced-reference/architecture/actions/sub-rule.md create mode 100644 content/en/advanced-reference/architecture/actions/wait.md create mode 100644 content/en/core-actions/advanced-process.md delete mode 100644 content/en/core-actions/assignment.md create mode 100644 content/en/core-actions/check.md delete mode 100644 content/en/core-actions/condition.md delete mode 100644 content/en/core-actions/loop.md create mode 100644 content/en/core-actions/multi-path.md delete mode 100644 content/en/core-actions/process.md create mode 100644 content/en/core-actions/repeat.md create mode 100644 content/en/core-actions/set-value.md delete mode 100644 content/en/core-actions/switch.md diff --git a/content/en/advanced-reference/architecture/actions/_index.md b/content/en/advanced-reference/architecture/actions/_index.md index 9322473..44bb602 100644 --- a/content/en/advanced-reference/architecture/actions/_index.md +++ b/content/en/advanced-reference/architecture/actions/_index.md @@ -1,19 +1,24 @@ --- -title: "Actions" -description: "Overview and detailed documentation for the Actions section of FlexiRule." +title: "Action Architecture" +description: "Internal implementation details and class structures for every logic node." weight: 10 --- -# Actions +# Action Architecture -Welcome to the Actions section. This section contains detailed information about actions components and their usage in FlexiRule. +Detailed technical references for the underlying action handlers and execution logic. -## Sub-pages +## Logic Nodes -- **[Condition](condition.md)** -- **[Document Action](document-action.md)** -- **[Entry](entry.md)** -- **[Loop](loop.md)** -- **[Notify](notify.md)** -- **[Query Records](query-records.md)** -- **[Stop](stop.md)** +- **[Check]({{< relref "check.md" >}})** +- **[Set Value]({{< relref "set-value.md" >}})** +- **[Repeat]({{< relref "repeat.md" >}})** +- **[Multi-Path]({{< relref "multi-path.md" >}})** +- **[Advanced Process]({{< relref "advanced-process.md" >}})** +- **[Query Records]({{< relref "query-records.md" >}})** +- **[Update Record]({{< relref "document-action.md" >}})** +- **[Notify]({{< relref "notify.md" >}})** +- **[Wait]({{< relref "wait.md" >}})** +- **[Sub-rule]({{< relref "sub-rule.md" >}})** +- **[Entry]({{< relref "entry.md" >}})** +- **[Stop]({{< relref "stop.md" >}})** diff --git a/content/en/advanced-reference/architecture/actions/advanced-process.md b/content/en/advanced-reference/architecture/actions/advanced-process.md new file mode 100644 index 0000000..d673c40 --- /dev/null +++ b/content/en/advanced-reference/architecture/actions/advanced-process.md @@ -0,0 +1,13 @@ +--- +title: 'Advanced Process: Architecture Reference' +description: Internal implementation details for the Process/Advanced Process action. +weight: 110 +--- + +# Advanced Process: Architecture Reference + +## Implementation +The **Advanced Process** action (internally `Process`) is handled by `ProcessHandler` in `flexirule/ruleflow/core/action_handlers/process.py`. + +## Process Runtime +Processes are registered in the `ProcessRegistry` and executed within a `ProcessRuntime`. They support custom input parameters and can return values to the rule context. diff --git a/content/en/advanced-reference/architecture/actions/condition.md b/content/en/advanced-reference/architecture/actions/condition.md index 8ab185e..e2f11e3 100644 --- a/content/en/advanced-reference/architecture/actions/condition.md +++ b/content/en/advanced-reference/architecture/actions/condition.md @@ -70,5 +70,5 @@ New operators can be added to the frontend `SimpleCondition.vue` component. Sinc - **Field Resolver**: `flexirule/ruleflow/utils/field_resolver.py` (Handles nested dot-notation) ## Related Topics -- [Action Documentation]({{< relref "core-actions/condition.md" >}}) +- [Action Documentation]({{< relref "core-actions/check.md" >}}) - [Execution Semantics]({{< relref "advanced-reference/reference/execution/condition.md" >}}) diff --git a/content/en/advanced-reference/architecture/actions/document-action.md b/content/en/advanced-reference/architecture/actions/document-action.md index 2b68cd9..f3e0a20 100644 --- a/content/en/advanced-reference/architecture/actions/document-action.md +++ b/content/en/advanced-reference/architecture/actions/document-action.md @@ -1,64 +1,20 @@ --- -title: 'Document Action: Architecture Reference' -description: Class structure, Resource Mapper internals, and mode dispatch logic for - the Document Action. +title: 'Update Record: Architecture Reference' +description: Internal implementation details for the Document Action. weight: 30 --- -# Document Action: Architecture Reference +# Update Record: Architecture Reference ## Purpose -The **Document Action** implementation abstracts Frappe's CRUD operations into a declarative mapping-based engine. It centralizes document manipulation logic to ensure consistent application of permissions, background enqueuing, and context-aware value resolution. +The **Update Record** block (internally Document Action) implementation abstracts Frappe's CRUD operations into a declarative mapping-based engine. It centralizes document manipulation logic to ensure consistent application of permissions, background enqueuing, and context-aware value resolution. -## Class Structure - -### `DocumentActionHandler(ActionHandler)` -- **Responsibility**: The primary singleton handler registered in the `HandlerRegistry`. -- **Key Methods**: - - `execute()`: Orchestrates the overall lifecycle, applies input mappings, and dispatches to mode handlers. - - `_create_new()`: Constructs document payloads and handles `is_async` enqueuing. - - `_update_existing()`: Handles targeted record modification. - - `_apply_table_mappings()`: Implements the recursive row-mapping engine. - - `_get_same_field_mappings()`: Implements field-matching logic between source and target. - -## Execution Pipeline - -1. **Registry Lookup**: `RuleEngine` identifies the action type and fetches the `DocumentActionHandler` instance. -2. **Mapping Layer**: - - **Scalar Mappings**: Resolved via `_resolve_field_mappings` or `compiled_scalars` (pre-compiled Python dict). - - **Static Values**: Merged last to ensure explicit configuration overrides dynamic discovery. -3. **Table Engine**: - - Iterates over `table_mappings`. - - Resolves the source collection (usually a list of dicts from `doc` or `vars`). - - For each row: - - Creates a `row_context` with `item` (current row) and `loop` metadata. - - Evaluates `condition` (inclusion check) and `filter` (exclusion check). - - Applies field-level assignments to the row payload. - - Appends the result to the parent document via `doc.append()`. -4. **Dispatch**: - - Sync: `frappe.get_doc(data).insert()` / `save()`. - - Async: `frappe.enqueue("..._async_create_doc", doc_data=data)`. +## Field Mapping +Field mapping logic is implemented in `flexirule/ruleflow/utils/mapping.py`. It provides the binding between rule context (doc, vars) and the target document fields. -## Context Mutation Model -- **Direct Memory Mutation**: For `Update Existing`, the handler performs `doc.set(field, value)` on a loaded object. -- **Persistence Strategy**: Mutations are not committed to the database until the explicit `.insert()` or `.save()` call at the end of the mode handler. -- **Context Injection**: The resulting document (post-save) is returned to the engine and injected into the `execution_context` (e.g., `vars.my_result`) using `apply_output_mapping`. +## Asynchronous Execution +When `is_async` is enabled, the action is enqueued using `frappe.enqueue`. The engine logs the background job ID and continues execution if there are no immediate dependencies on the result. -## Dependencies -- **Rule Engine Core**: Relies on `HandlerRegistry` for registration. -- **Value Resolver**: Uses `_safe_eval` (inheriting from `ActionHandler`) for Python expression evaluation. -- **Permissions**: Depends on `flexirule.ruleflow.core.permissions.can_skip_permissions` for role-based security bypassing. -- **Utils**: Uses `flexirule.ruleflow.utils.mapping.apply_input_mapping` for pre-execution config hydration. - -## Extension Points -- **Action Policies**: Developers can override operation-level policies (like `required_config_keys`) in `flexirule/ruleflow/core/contracts.py`. -- **Custom Resolvers**: Custom Jinja filters or Python locals can be added to `_build_template_context` in the base `ActionHandler` to make them available to Document Action mappings. - -## Internal Events -- **Background Task**: Triggers a `frappe.enqueue` event for asynchronous creation. -- **Standard Hooks**: Indirectly triggers all Frappe document lifecycle hooks (`before_insert`, `after_save`, etc.) for the target DocType. - -## Source Files -- **Backend**: `flexirule/ruleflow/core/action_handlers/create_doc.py` -- **Frontend**: `flexirule/public/js/flexirule/rule_builder/components/rule_config/types/DocumentActionConfig.vue` -- **Contract**: `flexirule/ruleflow/core/contracts.py` +## Class Structure +- **Handler Class**: `DocumentActionHandler` +- **Source File**: `flexirule/ruleflow/core/action_handlers/create_doc.py` diff --git a/content/en/advanced-reference/architecture/actions/entry.md b/content/en/advanced-reference/architecture/actions/entry.md index 935ebe1..a80219a 100644 --- a/content/en/advanced-reference/architecture/actions/entry.md +++ b/content/en/advanced-reference/architecture/actions/entry.md @@ -47,7 +47,7 @@ The Entry Action uses **Implicit Initialization**. It does not perform explicit ## Extension Points The Entry Action is considered a "Closed Core" component. Developers should not override the `EntryActionHandler` as it would break the fundamental graph-traversal guarantees of the engine. -If customization is needed for "initialization" logic, it is recommended to use an [Assignment]({{< relref "core-actions/assignment" >}}) node immediately following the Entry Action. +If customization is needed for "initialization" logic, it is recommended to use an [Assignment]({{< relref "core-actions/set-value" >}}) node immediately following the Entry Action. ## Internal Events - **`rule_execution_start`**: Fired by the `RuleEngine` immediately before the Entry Action is processed. diff --git a/content/en/advanced-reference/architecture/actions/multi-path.md b/content/en/advanced-reference/architecture/actions/multi-path.md new file mode 100644 index 0000000..bef4dda --- /dev/null +++ b/content/en/advanced-reference/architecture/actions/multi-path.md @@ -0,0 +1,16 @@ +--- +title: 'Multi-Path: Architecture Reference' +description: Internal implementation details for the Switch/Multi-Path action. +weight: 70 +--- + +# Multi-Path: Architecture Reference + +## Implementation +The **Multi-Path** action (internally `Switch`) is handled by `SwitchHandler` in `flexirule/ruleflow/core/action_handlers/switch.py`. + +## Execution Logic +1. Resolves the value of the target field or expression. +2. Iterates through the defined cases to find a match. +3. If a match is found, returns the corresponding `next_step_id`. +4. If no match is found, returns the `default_next_step_id`. diff --git a/content/en/advanced-reference/architecture/actions/query-records.md b/content/en/advanced-reference/architecture/actions/query-records.md index 406bd78..dd1df1f 100644 --- a/content/en/advanced-reference/architecture/actions/query-records.md +++ b/content/en/advanced-reference/architecture/actions/query-records.md @@ -11,6 +11,11 @@ The **Query Records** action is implemented as a core Action Handler within the --- +## Dynamic Date Formulas +The Query Records action includes a specialized evaluator for temporal logic. It supports rolling time windows (e.g., "Last 7 Days") by translating user-friendly formulas into standard SQL/Frappe database queries. This is handled by the `DateFormulaResolver` in the backend. + +--- + ## 1. Class Structure - **Handler Class**: `QueryRecordsHandler` diff --git a/content/en/advanced-reference/architecture/actions/repeat.md b/content/en/advanced-reference/architecture/actions/repeat.md new file mode 100644 index 0000000..f752c7a --- /dev/null +++ b/content/en/advanced-reference/architecture/actions/repeat.md @@ -0,0 +1,13 @@ +--- +title: 'Repeat: Architecture Reference' +description: Internal implementation details for the Loop/Repeat action. +weight: 60 +--- + +# Repeat: Architecture Reference + +## Implementation +The **Repeat** action (internally `Loop`) is handled by `LoopHandler` in `flexirule/ruleflow/core/action_handlers/loop.py`. + +## Iteration Logic +It manages an internal pointer to the current list item and re-executes the connected sub-graph for each item. diff --git a/content/en/advanced-reference/architecture/actions/set-value.md b/content/en/advanced-reference/architecture/actions/set-value.md new file mode 100644 index 0000000..0e45317 --- /dev/null +++ b/content/en/advanced-reference/architecture/actions/set-value.md @@ -0,0 +1,21 @@ +--- +title: 'Set Value: Architecture Reference' +description: Internal implementation details for the Assignment/Set Value action. +weight: 50 +--- + +# Set Value: Architecture Reference + +## Implementation +The **Set Value** action (internally `Assignment`) is handled by `AssignmentHandler` in `flexirule/ruleflow/core/action_handlers/assignment.py`. + +## Features + +### Batch Assignments +Allows multiple mutations in a single node execution. Assignments are processed sequentially. + +### Normalization Value Resolver +A core feature for cleaning and transforming data. It uses pipelines and profiles to apply transformations (like `trim`, `upper`, `lower`) before setting the value. + +### Context Variables +Assignments can target the global `vars` dictionary in the `ContextManager`, allowing state to be shared across nodes without persisting to the database. diff --git a/content/en/advanced-reference/architecture/actions/sub-rule.md b/content/en/advanced-reference/architecture/actions/sub-rule.md new file mode 100644 index 0000000..d81205d --- /dev/null +++ b/content/en/advanced-reference/architecture/actions/sub-rule.md @@ -0,0 +1,13 @@ +--- +title: 'Sub-rule: Architecture Reference' +description: Internal implementation details for the Sub-rule action. +weight: 90 +--- + +# Sub-rule: Architecture Reference + +## Implementation +The **Sub-rule** action is handled by `SubRuleHandler` in `flexirule/ruleflow/core/action_handlers/sub_rule.py`. + +## Recursion and Context +It invokes the `RuleEngine` recursively. It manages context isolation, ensuring that the sub-rule has access to the necessary data while preventing unintended side effects in the parent rule. diff --git a/content/en/advanced-reference/architecture/actions/wait.md b/content/en/advanced-reference/architecture/actions/wait.md new file mode 100644 index 0000000..87e4dd5 --- /dev/null +++ b/content/en/advanced-reference/architecture/actions/wait.md @@ -0,0 +1,13 @@ +--- +title: 'Wait: Architecture Reference' +description: Internal implementation details for the Wait action. +weight: 80 +--- + +# Wait: Architecture Reference + +## Implementation +The **Wait** action is handled by `WaitHandler` in `flexirule/ruleflow/core/action_handlers/simple_actions.py`. + +## Mechanism +It uses Python's `time.sleep()` for short durations or schedules a background task for longer waits, depending on the rule's execution mode. diff --git a/content/en/advanced-reference/architecture/engine/condition-system.md b/content/en/advanced-reference/architecture/engine/condition-system.md index a8d2dc2..05e693f 100644 --- a/content/en/advanced-reference/architecture/engine/condition-system.md +++ b/content/en/advanced-reference/architecture/engine/condition-system.md @@ -32,7 +32,7 @@ The **Condition Builder** is a recursive Vue 3 interface that allows users to co - **Input**: User interactions (drag-and-drop, field selection, operator picking). - **Output**: A standardized **JSON AST (Abstract Syntax Tree)**. - **Key Files**: `ConditionBuilder.vue`, `ConditionNode.vue`, `SimpleCondition.vue`. -- **Detailed Guide**: [Condition Builder Frontend]({{< relref "core-actions/condition.md" >}}) +- **Detailed Guide**: [Condition Builder Frontend]({{< relref "core-actions/check.md" >}}) ### 2. The Condition Compiler (Backend - Save-Time) diff --git a/content/en/advanced-reference/concepts/ai-features.md b/content/en/advanced-reference/concepts/ai-features.md index 8688c9a..c951914 100644 --- a/content/en/advanced-reference/concepts/ai-features.md +++ b/content/en/advanced-reference/concepts/ai-features.md @@ -94,5 +94,5 @@ sequenceDiagram ## Related Topics - [Execution Engine]({{< relref "advanced-reference/architecture/engine/execution-engine.md" >}}) -- [Variables]({{< relref "core-actions/assignment#context-variables-vars" >}}) -- [Condition Builder]({{< relref "core-actions/condition.md" >}}) +- [Variables]({{< relref "core-actions/set-value.md#context-variables-vars" >}}) +- [Condition Builder]({{< relref "core-actions/check.md" >}}) diff --git a/content/en/advanced-reference/concepts/data-manipulation/normalization-value-resolver.md b/content/en/advanced-reference/concepts/data-manipulation/normalization-value-resolver.md index e3ecbb1..7096b70 100644 --- a/content/en/advanced-reference/concepts/data-manipulation/normalization-value-resolver.md +++ b/content/en/advanced-reference/concepts/data-manipulation/normalization-value-resolver.md @@ -83,6 +83,6 @@ By using the Normalization Value Resolver, business users can: ## Where to find it? The Normalization Value Resolver is integrated into: -- [Assignment Action]({{< relref "core-actions/assignment/" >}}) -- [Condition Nodes]({{< relref "core-actions/condition/" >}}) +- [Assignment Action]({{< relref "core-actions/set-value/" >}}) +- [Condition Nodes]({{< relref "core-actions/check/" >}}) - Any configuration panel requiring data mapping. diff --git a/content/en/advanced-reference/concepts/rule-entry-condition-vs-condition-action.md b/content/en/advanced-reference/concepts/rule-entry-condition-vs-condition-action.md index 20d4d66..7a03961 100644 --- a/content/en/advanced-reference/concepts/rule-entry-condition-vs-condition-action.md +++ b/content/en/advanced-reference/concepts/rule-entry-condition-vs-condition-action.md @@ -21,7 +21,7 @@ However, they serve very different purposes. ## Quick Summary -| Use Case | Rule Entry Condition | [Condition Action]({{< relref "core-actions/condition.md" >}}) | +| Use Case | Rule Entry Condition | [Condition Action]({{< relref "core-actions/check.md" >}}) | | :--- | :---: | :---: | | Decide whether the rule should run at all | ✅ Yes | ❌ No | | Create branching logic inside a rule | ❌ No | ✅ Yes | @@ -108,7 +108,7 @@ Condition: Customer is VIP? ### Recommended Uses -Use a [Condition Action]({{< relref "core-actions/condition.md" >}}) when you need: +Use a [Condition Action]({{< relref "core-actions/check.md" >}}) when you need: - **If / Else logic**: Branching into different paths. - **Guarded Sequences**: Executing specific actions only under certain conditions within a larger flow. - **Decision Trees**: Handling complex business logic after the rule has been triggered. diff --git a/content/en/advanced-reference/contributing/action-documentation-standard.md b/content/en/advanced-reference/contributing/action-documentation-standard.md index 7ff6a4a..464e5c1 100644 --- a/content/en/advanced-reference/contributing/action-documentation-standard.md +++ b/content/en/advanced-reference/contributing/action-documentation-standard.md @@ -70,7 +70,7 @@ FlexiRule uses a 3-layer architecture for action documentation: ### Cross-Linking Convention - **Hugo `relref`**: All internal links must use the `relref` shortcode pointing to the `.md` file path. -- **Format**: `{{}}` +- **Format**: `{{}}` - **Why**: This ensures link stability across refactors and URL changes. --- diff --git a/content/en/advanced-reference/reference/execution/condition.md b/content/en/advanced-reference/reference/execution/condition.md index 2eecf70..9244f0c 100644 --- a/content/en/advanced-reference/reference/execution/condition.md +++ b/content/en/advanced-reference/reference/execution/condition.md @@ -61,6 +61,6 @@ Since the action is read-only and operates on the local execution context, it is - **Memory**: The action has a negligible memory footprint as it does not store large datasets. ## Related Topics -- [Action Documentation]({{< relref "core-actions/condition.md" >}}) +- [Action Documentation]({{< relref "core-actions/check.md" >}}) - [Architecture Reference]({{< relref "advanced-reference/architecture/actions/condition.md" >}}) -- [Condition Builder Guide]({{< relref "core-actions/condition.md" >}}) +- [Condition Builder Guide]({{< relref "core-actions/check.md" >}}) diff --git a/content/en/advanced-reference/reference/execution/stop.md b/content/en/advanced-reference/reference/execution/stop.md index 06fb435..e35d63c 100644 --- a/content/en/advanced-reference/reference/execution/stop.md +++ b/content/en/advanced-reference/reference/execution/stop.md @@ -31,7 +31,7 @@ The Stop action has read-only access to: The transaction behavior of the Stop action depends entirely on its mode: - **Success**: The action has no impact on the current database transaction. The transaction continues as normal and will commit when the overall rule execution (and any other triggered rules) finishes successfully. -- **Error**: Raising a `frappe.ValidationError` triggers a standard database **Rollback**. Any changes made by previous nodes in the same rule flow (e.g., [Assignment]({{< relref "core-actions/assignment" >}}) updates to `doc`) will be reverted. +- **Error**: Raising a `frappe.ValidationError` triggers a standard database **Rollback**. Any changes made by previous nodes in the same rule flow (e.g., [Assignment]({{< relref "core-actions/set-value" >}}) updates to `doc`) will be reverted. ## Failure Behavior If the Jinja template in the error message fails to render, the engine will raise a secondary rendering error. However, since the intent was already to stop with an error, the result is still a termination of the flow and a rollback of the transaction. diff --git a/content/en/core-actions/advanced-process.md b/content/en/core-actions/advanced-process.md new file mode 100644 index 0000000..a0341a9 --- /dev/null +++ b/content/en/core-actions/advanced-process.md @@ -0,0 +1,23 @@ +--- +title: Advanced Process +description: Execute complex custom logic or background tasks. +weight: 110 +aliases: + - /docs/actions/process/ +--- + +# Advanced Process + +The **Advanced Process** block is used for special logic that goes beyond standard record updates or notifications. These processes are usually predefined by a developer. + +## When to Use +- **Custom Logic**: Run a specific Python or JavaScript process. +- **Calculations**: Perform heavy math or data processing. +- **Integrations**: Send data to or receive data from other systems via an API. + +## How to Configure +1. **Select Process**: Pick the predefined process you want to run. +2. **Provide Inputs**: Fill in any required information the process needs. +3. **Use Results**: Use any values the process returns in your following logic blocks. + +> **Note**: If you need a new process created, contact your system administrator or developer. diff --git a/content/en/core-actions/assignment.md b/content/en/core-actions/assignment.md deleted file mode 100644 index 47f2397..0000000 --- a/content/en/core-actions/assignment.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: Assignment -description: Set variables and modify document fields within the rule flow. -weight: 50 -aliases: - - /docs/actions/assignment/ ---- - -# Assignment Action - -The **Assignment** action is used to change values in your rule. This can include updating fields on the document currently being processed or setting temporary variables for use in later steps. - -## Types of Assignments - -### 1. Document Field Assignment -Directly change a field on the current document (the one that triggered the rule). -- **Example**: Set `status` to "Pending Review". - -### 2. Context Variable Assignment {#context-variables-vars} -Create or update a "Variable" that exists only while the rule is running. This is useful for temporary calculations. -- **Example**: Calculate a total `tax_amount = doc.amount * 0.15`. - -## Batch Assignments -You can define multiple assignments within a single node. They are executed sequentially from top to bottom. - -## Normalization and Cleaning -Assignments support "Pipelines" to clean or transform data as it's being set. -- **Example**: Trimming whitespace from a string or converting a name to uppercase. diff --git a/content/en/core-actions/check.md b/content/en/core-actions/check.md new file mode 100644 index 0000000..d2ccd6d --- /dev/null +++ b/content/en/core-actions/check.md @@ -0,0 +1,30 @@ +--- +title: Check +description: Branch your rule logic based on true/false evaluations. +weight: 40 +aliases: + - /docs/actions/condition/ +--- + +# Check + +The **Check** block (internally called Condition) allows you to create branches in your logic. It evaluates a set of rules and directs the flow down either a **True** or **False** path. + +## How to Configure + +### 1. Build Your Logic +Use the guided builder to define what you want to check. +- **Field**: Select a field or variable (e.g., "Grand Total"). +- **Operator**: Choose how to compare (e.g., "is greater than", "contains"). +- **Value**: The value you are checking against. + +### 2. Combine Rules (And/Or) +- **AND**: Every rule in the group must be true for the flow to take the True path. +- **OR**: If at least one rule is true, the flow takes the True path. + +## Example +**Scenario**: Send a notification only for large orders. +1. Add a **Check** block. +2. Rule: `grand_total` is greater than `5000`. +3. Connect the **True** path to a [Notify]({{< relref "notify-action" >}}) block. +4. Leave the **False** path empty to do nothing for smaller orders. diff --git a/content/en/core-actions/condition.md b/content/en/core-actions/condition.md deleted file mode 100644 index 3de2916..0000000 --- a/content/en/core-actions/condition.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: Condition -description: Branch your rule logic based on true/false evaluations. -weight: 40 -aliases: - - /docs/actions/condition/ ---- - -# Condition Action - -The **Condition** action allows you to create branching logic in your rules. It evaluates a set of rules and directs the execution flow down either a **True** or **False** path. - -## How to Configure - -### 1. The Rule Builder -Use the integrated condition builder to define your logic. -- **Field**: Select a field from the document or a variable. -- **Operator**: Choose how to compare (e.g., "is", "is not", "contains", "is greater than"). -- **Value**: The value to compare against. - -### 2. Grouping Logic (And/Or) -- **AND**: All conditions in the group must be true. -- **OR**: At least one condition in the group must be true. - -## Simple Example -**Scenario**: Only notify a manager if an order is over $5,000. -1. Add a **Condition** node. -2. Set rule: `grand_total` is greater than `5000`. -3. Connect the **True** path to a **Notify** action. -4. Leave the **False** path empty or connect it to a different step. diff --git a/content/en/core-actions/entry-action.md b/content/en/core-actions/entry-action.md index 6a78668..8c7bfa7 100644 --- a/content/en/core-actions/entry-action.md +++ b/content/en/core-actions/entry-action.md @@ -8,12 +8,12 @@ aliases: # Entry Action -Every business rule starts with an **Entry Action**. This node represents the document and data that triggered the rule. +Every business rule begins with an **Entry Action**. This block represents the data that triggered the rule. ## What is the Entry Action? -Think of the Entry Action as the "input" for your logic. It contains the `doc` (the record that triggered the rule) and makes it available to all following steps. +Think of the Entry Action as the "Start" of your logic. It contains the record (the `doc`) that triggered the rule and makes all of its fields available to every other block in your flow. -## Rule Entry Conditions -You can configure "Entry Conditions" directly on the Rule header. These act as a gatekeeper: if the condition isn't met, the rule won't even start. +## Gatekeepers (Entry Conditions) +You can set "Entry Conditions" on the rule itself. These act like a gatekeeper—if the conditions aren't met, the rule won't even start. -**Note**: For branching logic *after* the rule has already started, use the [Condition Action]({{< relref "condition" >}}). +For making decisions *after* the rule has started, use a [Check]({{< relref "check" >}}) block. diff --git a/content/en/core-actions/loop.md b/content/en/core-actions/loop.md deleted file mode 100644 index e71cbff..0000000 --- a/content/en/core-actions/loop.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Loop -description: Repeat a sequence of actions for each item in a list. -weight: 60 -aliases: - - /docs/actions/loop/ ---- - -# Loop Action - -The **Loop** action allows you to repeat a series of steps for multiple items. This is essential when you have a list of records (like those from a **Query Records** action) and need to perform the same task for each one. - -## How it Works - -1. **Input List**: Select the list of items you want to process. -2. **Loop Flow**: Any actions connected to the loop's output will be executed once for every item in the list. -3. **Current Item**: Inside the loop, you can access the specific item currently being processed. - -## Example -**Scenario**: Send a notification for every overdue invoice found. -1. **Query Records**: Find all "Invoices" where `status` is "Overdue". -2. **Loop**: Connect the results to a Loop node. -3. **Notify**: Inside the loop, use the **Notify** action. It will run for each individual invoice. - -## Best Practices -- **Efficiency**: Only loop over the items you need. Use filters in your query to keep the list small. -- **Complexity**: If your loop logic gets too complex, consider using a **Sub-rule**. diff --git a/content/en/core-actions/multi-path.md b/content/en/core-actions/multi-path.md new file mode 100644 index 0000000..479ac1c --- /dev/null +++ b/content/en/core-actions/multi-path.md @@ -0,0 +1,26 @@ +--- +title: Multi-Path +description: Route execution down different paths based on a specific value. +weight: 70 +aliases: + - /docs/actions/switch/ +--- + +# Multi-Path + +The **Multi-Path** block (internally called Switch) works like a multi-way junction. It allows you to choose from many different paths based on the value of a specific field. + +## How to Configure + +1. **Pick a Field**: Choose the field or variable you want to check (e.g., "Priority"). +2. **Create Paths**: Define a "Path" for each value you want to handle. + - **Path: High**: Steps for high-priority items. + - **Path: Medium**: Steps for medium-priority items. +3. **Default Path**: Define what happens if the value doesn't match any of your specific paths. + +## Example +**Scenario**: Route a support ticket based on its category. +- **Multi-Path** on the "Category" field. +- **Path "Billing"**: Connect to a block that notifies the finance team. +- **Path "Technical"**: Connect to a block that notifies engineering. +- **Default Path**: Connect to a general support notification. diff --git a/content/en/core-actions/notify-action.md b/content/en/core-actions/notify-action.md index 099f731..8d01acb 100644 --- a/content/en/core-actions/notify-action.md +++ b/content/en/core-actions/notify-action.md @@ -14,19 +14,19 @@ The **Notify** action is used to communicate information to users or external sy ### 1. Email Send a formatted email to one or more recipients. -- **Recipients**: Use static email addresses or dynamic ones (e.g., `doc.owner`). -- **Templates**: Select from existing Frappe Email Templates or write custom content. -- **Attachments**: Attach the current document as a PDF. +- **Recipients**: Use specific email addresses or dynamic ones like the document owner (`doc.owner`). +- **Templates**: Select from your existing system Email Templates or write custom content. +- **Attachments**: You can automatically attach the current document as a PDF. ### 2. System Notification -Create a notification within the Frappe Desk for a specific user or role. These appear in the notification bell icon. +Create a notification within the Desk for a specific user. These appear in the notification bell icon. ### 3. UI Toast Display a temporary popup message (Toast) to the user who triggered the rule. - **Types**: Success, Info, Warning, or Error. -- **Note**: This only works for rules triggered by manual UI actions (e.g., clicking Save). +- **Best For**: Providing immediate feedback during manual actions. ## Configuration Steps -1. **Select Type**: Choose how you want to notify. -2. **Define Content**: Write your message. You can use `{{ doc.name }}` to include data from the document. -3. **Set Recipients**: Choose who should receive the notification. +1. **Choose Type**: Select how you want to send the notification. +2. **Write Message**: Compose your message. Use `{{ doc.name }}` to include data from the record. +3. **Set Recipients**: Choose who should receive the alert. diff --git a/content/en/core-actions/process.md b/content/en/core-actions/process.md deleted file mode 100644 index 406a443..0000000 --- a/content/en/core-actions/process.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Process -description: Execute complex custom logic or background tasks. -weight: 110 -aliases: - - /docs/actions/process/ ---- - -# Process Action - -The **Process** action is used for advanced logic that goes beyond standard record updates or notifications. - -## When to Use -- **Custom Scripts**: Run a predefined Python or JavaScript process. -- **Heavy Calculations**: Offload complex math to a dedicated process to keep the UI responsive. -- **External Integrations**: Call third-party APIs or services. - -## Configuration -1. Select the **Process** you want to run. -2. Provide any required **Input Parameters**. -3. Use the **Return Value** in subsequent nodes of your rule. diff --git a/content/en/core-actions/query-records.md b/content/en/core-actions/query-records.md index b3b7e5a..5dec2f5 100644 --- a/content/en/core-actions/query-records.md +++ b/content/en/core-actions/query-records.md @@ -8,49 +8,37 @@ aliases: # Query Records -The **Query Records** action allows your rule flows to fetch information from the database. It is the primary way to make decisions based on data that isn't already present in your current document. +The **Query Records** action allows your rules to fetch information from the database. It is the primary way to make decisions based on data that isn't already present in your current document. ## When to Use -- **Data Enrichment**: Fetching related fields (e.g., getting a Customer's "Territory"). +- **Data Enrichment**: Fetching related information (e.g., getting a Customer's "Region"). - **Validation**: Checking for duplicates or conflicting records. -- **Aggregations**: Calculating totals across multiple documents (e.g., "Sum of all unpaid invoices"). +- **Calculations**: Finding totals across multiple documents (e.g., "Sum of all unpaid invoices"). ## Query Modes | Mode | Returns | Best For | | :--- | :--- | :--- | -| **Query List** | List of Records | Finding multiple records to loop over. | +| **Query List** | List of Records | Finding multiple records to [Repeat]({{< relref "repeat" >}}) over. | | **Query Doc** | Single Record | Fetching detailed info from a specific record. | | **Exist Record** | Yes/No | Simple validation and existence checks. | | **Aggregations** | Number | Totals, counts, and averages (Sum, Min, Max). | -| **Group By** | List of Totals | Summary data grouped by a category (e.g., Sales by Territory). | - -## Advanced Querying - -### Aggregations -Use this mode when you only need a single number. -- **Count**: How many records match the filter. -- **Sum**: The total of a specific numeric field. -- **Average/Min/Max**: Standard statistical calculations. - -### Group By -Use this to summarize data into "buckets". -- **Example**: Get the total sales amount for each individual salesperson in the last month. +| **Group By** | List of Totals | Summary data grouped by a category (e.g., Sales by Region). | ## How to Configure -### 1. Select the DocType -Choose the type of record you want to find (e.g., "Sales Invoice"). +### 1. Select the Type of Record +Choose the DocType you want to find (e.g., "Sales Invoice"). ### 2. Define Filters Filters tell FlexiRule exactly which records to find. -- **Static Filters**: `status = "Draft"` -- **Dynamic Filters**: `customer = doc.customer` (matches the customer from the current document). -- **Date Formulas**: Use the formula builder for rolling windows like "Last 7 Days". +- **Simple Filters**: Find records where `status` is "Draft". +- **Matching Filters**: Match fields from the current document, like `customer` is `doc.customer`. +- **Date Filters**: Use the guided UI to set time windows like "Last 30 Days". -### 3. Refresh Schema (Important) -After setting your query, click the **Refresh Schema** button. This performs a live test and makes the resulting fields available to use in later steps of your rule. +### 3. Use the Results +After setting your query, click **Refresh Schema**. This makes the resulting fields available to use in later steps of your rule (e.g., in a [Check]({{< relref "check" >}}) or [Set Value]({{< relref "set-value" >}}) block). ## Common Tips -- **Always Filter**: Avoid searching the entire database without filters to keep your rules fast. -- **Check the Result**: Remember that **Query List** always returns a list of items, even if it only finds one. Use **Query Doc** if you only need one specific record. +- **Be Specific**: Always use filters to keep your rules fast and accurate. +- **List vs. Single**: If you only need one record, use **Query Doc**. If you might find many, use **Query List**. diff --git a/content/en/core-actions/repeat.md b/content/en/core-actions/repeat.md new file mode 100644 index 0000000..111b1ee --- /dev/null +++ b/content/en/core-actions/repeat.md @@ -0,0 +1,27 @@ +--- +title: Repeat +description: Repeat a sequence of actions for each item in a list. +weight: 60 +aliases: + - /docs/actions/loop/ +--- + +# Repeat + +The **Repeat** block (internally called Loop) allows you to perform the same set of actions for every item in a list. This is essential when working with multiple records, such as those found using a [Query Records]({{< relref "query-records" >}}) block. + +## How it Works + +1. **Select the List**: Choose the list of items you want to process. +2. **Define the Flow**: Any blocks connected to the repeat output will run once for every item in that list. +3. **Access Current Item**: Inside the loop, you can work with the specific item being processed at that moment. + +## Example +**Scenario**: Send an alert for every overdue invoice. +1. **Query Records**: Find all "Invoices" that are "Overdue". +2. **Repeat**: Connect the results to a **Repeat** block. +3. **Notify**: Add a notification block inside the flow. It will run for each overdue invoice found. + +## Best Practices +- **Stay Efficient**: Use filters in your query to only find the items you actually need to repeat over. +- **Keep it Simple**: If your logic inside the repeat block becomes too complex, consider moving it to a [Sub-rule]({{< relref "sub-rule" >}}). diff --git a/content/en/core-actions/set-value.md b/content/en/core-actions/set-value.md new file mode 100644 index 0000000..ca61961 --- /dev/null +++ b/content/en/core-actions/set-value.md @@ -0,0 +1,28 @@ +--- +title: Set Value +description: Set variables and modify document fields within the rule flow. +weight: 50 +aliases: + - /docs/actions/assignment/ +--- + +# Set Value + +The **Set Value** block (internally called Assignment) is used to change data within your rule. You can use it to update fields on the current record or create temporary variables for calculations. + +## Types of Changes + +### 1. Update Current Record +Directly change a field on the record that started the rule. +- **Example**: Set the `status` to "Pending Review". + +### 2. Save Temporary Variables +Create a "Variable" that exists only while the rule is running. This is perfect for complex calculations. +- **Example**: Calculate a total `tax_amount` based on the order total. + +## Batch Updates +You can perform multiple changes within a single **Set Value** block. They are processed one by one from top to bottom. + +## Data Cleaning +This block also supports "Pipelines" to automatically clean or format your data. +- **Example**: Automatically capitalize a name or remove extra spaces from a text field. diff --git a/content/en/core-actions/stop-error.md b/content/en/core-actions/stop-error.md index c9ff13f..f211b6c 100644 --- a/content/en/core-actions/stop-error.md +++ b/content/en/core-actions/stop-error.md @@ -9,13 +9,13 @@ aliases: # Stop and Error Handling -These nodes allow you to explicitly control the end of a rule or handle situations where something goes wrong. +These blocks allow you to explicitly finish a rule or show a message when something isn't right. -## Stop Action -The **Stop** action immediately ends the execution of the rule. -- **Use Case**: Use this inside a **Condition** to exit a rule early if certain criteria aren't met, preventing subsequent actions from running. +## Stop +The **Stop** block immediately ends the rule's execution. +- **When to Use**: Use this inside a [Check]({{< relref "check" >}}) to exit a rule early if certain criteria are met, preventing any further actions from running. -## Raise Error Action -The **Raise Error** action stops the rule and displays an error message to the user. -- **Use Case**: Use this for strict validation. For example, if a Sales Order is missing a required attachment, you can "Raise Error" with a custom message like "Please upload the signed contract before submitting." -- **Visual Feedback**: In the Frappe UI, this will appear as a standard error popup. +## Show Error +The **Show Error** block (internally Raise Error) stops the rule and displays a custom error message to the user. +- **When to Use**: Use this for strict validation. For example, if a document is missing a required attachment, show an error: "Please upload the contract before continuing." +- **Feedback**: The message will appear as a standard popup in the system interface. diff --git a/content/en/core-actions/sub-rule.md b/content/en/core-actions/sub-rule.md index 70ce002..db2cc5d 100644 --- a/content/en/core-actions/sub-rule.md +++ b/content/en/core-actions/sub-rule.md @@ -8,13 +8,13 @@ aliases: # Sub-rule Action -The **Sub-rule** action allows you to execute one rule from inside another. This helps keep your rules organized and allows you to reuse common logic. +The **Sub-rule** action allows you to run one rule from inside another. This is the best way to keep your logic organized and reuse common steps. ## Why Use Sub-rules? -- **Organization**: Break down very large, complex rules into smaller, manageable pieces. -- **Reusability**: Create a "standard approval" logic once and call it from many different rules. +- **Stay Organized**: Break down very large, complex rules into smaller, easy-to-read pieces. +- **Reuse Logic**: Create a "Standard Approval" or "Address Validation" rule once and call it from many different places. -## How to Use -1. Select the **Sub-rule** node. -2. Pick the existing rule you want to run. -3. **Pass Data**: Optionally pass specific variables or documents into the sub-rule. +## How to Configure +1. **Select Rule**: Pick the existing rule you want to execute. +2. **Pass Data**: Choose which documents or variables the sub-rule should work with. +3. **Handle Results**: Use any values returned by the sub-rule in your next steps. diff --git a/content/en/core-actions/switch.md b/content/en/core-actions/switch.md deleted file mode 100644 index a49791f..0000000 --- a/content/en/core-actions/switch.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: Switch -description: Route execution down different paths based on a specific value. -weight: 70 -aliases: - - /docs/actions/switch/ ---- - -# Switch Action - -The **Switch** action is like a multi-way branch. Instead of a simple "True/False" condition, it allows you to choose from many different paths based on the value of a field. - -## How to Configure - -1. **Select Field**: Choose the field or variable you want to check (e.g., `doc.priority`). -2. **Define Cases**: Create a "Case" for each possible value you want to handle. - - **Case: High**: Path for high-priority items. - - **Case: Medium**: Path for medium-priority items. -3. **Default Path**: Define what happens if the value doesn't match any of your cases. - -## Example -**Scenario**: Route a support ticket based on its category. -- **Switch** on `category`. -- **Path "Billing"**: Connect to a node that notifies the finance team. -- **Path "Technical"**: Connect to a node that notifies the support engineering team. -- **Path "General"**: Connect to the default path. diff --git a/content/en/core-actions/update-record.md b/content/en/core-actions/update-record.md index f44da2f..9a36586 100644 --- a/content/en/core-actions/update-record.md +++ b/content/en/core-actions/update-record.md @@ -1,31 +1,31 @@ --- title: Update Record -description: Create, update, or delete documents in the system. +description: Create, update, or delete records in the system. weight: 30 aliases: - /docs/actions/document-action/ --- -# Update Record (Document Action) +# Update Record -The **Document Action** (often labeled as **Update Record** in the UI) allows you to manipulate documents in the system. +The **Update Record** block (internally called Document Action) allows you to create or modify records anywhere in the system. ## Operations ### 1. Create New -Create a brand new document in any DocType. -- **Set Fields**: Define the initial values for the new record. -- **Asynchronous**: For heavy operations, you can enable "Run in Background". +Create a brand new record (e.g., create a "Task" when a "Project" is saved). +- **Set Fields**: Define the starting values for the new record. +- **Background Task**: For complex operations, you can choose to run this in the background to keep the interface fast. ### 2. Update Existing -Modify fields on an existing document. -- **Find the Record**: You must provide the "Name" (ID) of the document to update. Usually, this comes from a previous **Query Records** step. -- **Field Mapping**: Map values from your current rule context to the target document. +Modify fields on an existing record. +- **Target Record**: You must specify which record to update. This usually comes from a previous [Query Records]({{< relref "query-records" >}}) step. +- **Field Mapping**: Choose which fields to change and what their new values should be. ### 3. Delete Record -Remove a document from the system. -- **Caution**: This action is permanent. Ensure you have proper filters set to target the correct record. +Remove a record from the system. +- **Note**: Use this with caution. Ensure your filters correctly target only the intended record. -## Best Practices -- **Use Validation**: Before updating a record, consider using a **Condition** to ensure the update is valid. -- **Chain Actions**: Frequently used with **Query Records** (to find the document) followed by **Update Record** (to modify it). +## Common Workflows +- **Validation**: Check a condition first, then update a status field. +- **Data Sync**: Use a [Query Records]({{< relref "query-records" >}}) block to find a related document, then use **Update Record** to keep it in sync. diff --git a/content/en/core-actions/wait.md b/content/en/core-actions/wait.md index 2ba8fae..be1dbc8 100644 --- a/content/en/core-actions/wait.md +++ b/content/en/core-actions/wait.md @@ -8,15 +8,14 @@ aliases: # Wait Action -The **Wait** action pauses the execution of your rule. This is useful for follow-up automations or time-delayed tasks. +The **Wait** action pauses the execution of your rule. This is useful for building time-delayed automations or follow-up tasks. ## Wait Options -- **Duration**: Wait for a specific amount of time (e.g., "2 days", "4 hours"). -- **Until Date**: Wait until a specific date and time reached. You can use fields from the document (e.g., `doc.due_date`). +- **For a Duration**: Pause for a specific amount of time (e.g., "2 days" or "4 hours"). +- **Until a Date**: Pause until a specific date and time is reached. You can use fields from your record, like "Due Date". -## Example -**Scenario**: Send a reminder email 24 hours after a quote is sent. -1. Rule triggers when Quote is saved. -2. **Wait** action set for "1 day". -3. **Notify** action sends the reminder email. +## Example Use Cases +- **Reminders**: Send a follow-up email 3 days after a quote is sent. +- **Delayed Updates**: Wait until a specific date to change a record's status. +- **Scheduled Checks**: Pause execution to allow for external processes to complete before proceeding. diff --git a/content/en/getting-started/introduction.md b/content/en/getting-started/introduction.md index 94709e6..5a43208 100644 --- a/content/en/getting-started/introduction.md +++ b/content/en/getting-started/introduction.md @@ -13,7 +13,7 @@ FlexiRule is a high-performance, visual automation engine for the Frappe Framewo ## Why FlexiRule? - **Visual First**: Design logic flows using an intuitive node-based interface. -- **No-Code Experience**: Empower business users to participate in logic design. +- **User-Friendly**: Empower business users to participate in logic design. - **Native Frappe Integration**: Deeply integrated with DocTypes, Hooks, and the Frappe security model. - **Enterprise-Grade**: Built for performance, auditability, and scale. @@ -25,4 +25,4 @@ FlexiRule simplifies business automation into three main stages: 1. **The Trigger**: Defining *when* a rule should run (e.g., when a Sales Order is saved or on a schedule). 2. **The Logic**: Using the **Rule Builder** to map out the decision path and actions. -3. **The Result**: Executing actions like updating records, sending notifications, or calling external APIs. +3. **The Result**: Executing actions like updating records, sending notifications, or calling other rules. diff --git a/content/en/getting-started/quick-start.md b/content/en/getting-started/quick-start.md index 4fe6de8..bc4f3e9 100644 --- a/content/en/getting-started/quick-start.md +++ b/content/en/getting-started/quick-start.md @@ -23,9 +23,9 @@ In the **Triggers** section, decide when this rule should run: ## 3. Build the Logic Click on the **Rule Builder** tab to open the visual canvas. -1. **Add a Condition**: Click the `+` icon on the **Entry Action** to add a **Condition** node. -2. **Configure**: Set the condition to check if `doc.grand_total < 1000`. -3. **Add an Action**: On the `True` path, add a **Document Action** to update the `status` to "Approved". +1. **Add a Check**: Click the `+` icon on the **Entry Action** to add a **Check** node. +2. **Configure**: Set the check to see if `grand_total < 1000`. +3. **Add an Action**: On the `True` path, add a **Set Value** to update the `status` to "Approved". ## 4. Activate and Test 1. Save the Rule document. diff --git a/content/en/using-the-builder/adding-managing-actions.md b/content/en/using-the-builder/adding-managing-actions.md index 428a1a6..c229088 100644 --- a/content/en/using-the-builder/adding-managing-actions.md +++ b/content/en/using-the-builder/adding-managing-actions.md @@ -6,7 +6,7 @@ weight: 20 # Adding and Managing Actions -Building logic in FlexiRule is centered around adding and connecting "Action" nodes. +Building logic in FlexiRule is centered around adding and connecting logic blocks. ## The Action Zone @@ -17,22 +17,22 @@ The **Action Zone** is the primary way to add new logic. It provides a searchabl ### How to Add an Action 1. **Hover**: Hover your mouse over any connection line or empty space on the canvas. 2. **Trigger**: Click the `+` icon that appears. -3. **Search & Select**: Browse categories or type to find the action you need (e.g., "Email" or "Update Record"). -4. **Insert**: The new node is automatically inserted and connected into your flow. +3. **Search & Select**: Browse categories or type to find the block you need (e.g., "Email" or "Update Record"). +4. **Insert**: The new block is automatically inserted and connected into your flow. ## Managing Connections -### Reconnecting Nodes -If you delete a node between two others, FlexiRule intelligently heals the connection to maintain your logic flow. +### Reconnecting Blocks +If you delete a block between two others, FlexiRule intelligently heals the connection to maintain your logic flow. {{< video src="/images/remove-a-node-will-dynamically-reconnet-nodes.webm" >}} ### Manual Connections -You can also manually connect nodes by dragging from the output handle of one node to the input handle of another. +You can also manually connect blocks by dragging from the output handle of one block to the input handle of another. ## Intelligent Configuration -When you select an action, a configuration panel opens on the right. +When you select a block, a configuration panel opens on the right. - **Smart Pickers**: Field pickers only show variables that are actually available at that point in the rule. - **Validation**: The builder alerts you if required fields are missing before you save. diff --git a/content/en/using-the-builder/canvas-navigation.md b/content/en/using-the-builder/canvas-navigation.md index bb87973..35a1acb 100644 --- a/content/en/using-the-builder/canvas-navigation.md +++ b/content/en/using-the-builder/canvas-navigation.md @@ -18,13 +18,13 @@ The Rule Builder is your visual workspace for designing business logic. It provi - **Pan**: Click and drag any empty space on the canvas to move around. - **Zoom**: Use your mouse wheel or the zoom controls in the corner to adjust the view. -### Working with Nodes -- **Select**: Click a node to select it and open its configuration panel. -- **Move**: Drag a node to reposition it. -- **Delete**: Select a node and press `Backspace` or `Delete`. The builder will automatically attempt to reconnect the remaining nodes. +### Working with Blocks +- **Select**: Click a block to select it and open its configuration panel. +- **Move**: Drag a block to reposition it. +- **Delete**: Select a block and press `Backspace` or `Delete`. The builder will automatically attempt to reconnect the remaining blocks. ### Bulk Actions -You can select multiple nodes by holding `Shift` and dragging a selection box. This allows you to move or copy groups of logic at once. +You can select multiple blocks by holding `Shift` and dragging a selection box. This allows you to move or copy groups of logic at once. {{< video src="/images/shift-click-nodes-to-copy.webm" >}} @@ -33,12 +33,12 @@ You can select multiple nodes by holding `Shift` and dragging a selection box. T The Rule Builder includes built-in tools to test your rules in real-time. ### Visual Execution Path -When you run a test, the builder highlights the exact path taken during execution, showing you exactly which nodes were triggered. +When you run a test, the builder highlights the exact path taken during execution, showing you exactly which blocks were triggered. {{< video src="/images/debug-rule-view-execution-path.webm" >}} ### Inspecting Results -You can click on any node after a test run to see its specific results, including modified variables and return values. +You can click on any block after a test run to see its specific results, including modified variables and return values. ![Debug View Return Result](/images/debug-view-return-result.png)