> For the complete documentation index, see [llms.txt](https://academy.any2info.com/any2info-academy/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://academy.any2info.com/any2info-academy/no-code-platform/data-studio/data-hubs/data-flows/best-practices.md). # Best Practices **Category:** Data flows **Version:** 1.0 **Last updated:** May 12, 2026 **Author:** Any2Info *** ## Description This document describes the recommended best practices for building and maintaining **Any2Info DataHub Dataflows**. Applying these guidelines helps improve: * Stability * Performance * Maintainability * Monitoring * Troubleshooting The goal is to keep dataflows predictable, efficient, and easy to support. *** ## General ### Use the Note property Every dataflow contains a **Note** property. Use this property to: * Describe the purpose of the flow * Explain important business logic * Document temporary workarounds * Track important changes or decisions When filled in, the note is also shown at the top of the canvas, making it easier to understand the purpose of a flow without opening every node. *** ### Keep flows small and focused Try to keep the number of nodes in a dataflow limited. Recommended guidelines: * A flow should ideally not run longer than **10–15 minutes** * Split large flows into multiple smaller flows where possible * Avoid creating “all-in-one” flows with many responsibilities Since version **5.1**: * A hard limit of **100 nodes** exists * A warning is shown when a flow exceeds **80 nodes** Large flows are: * Harder to maintain * Harder to troubleshoot * More sensitive to failures * More difficult to analyze *** ## Triggers ### Use the correct trigger type Choose the trigger type that best matches the purpose of the flow. #### Time-based triggers When using a time-based trigger: * Configure it so the next execution does not start while the previous execution is still running * Limit execution windows when flows are only needed during business hours Example: * A synchronization flow that is only needed during office hours should not run during the night *** ### Prefer event-driven triggers where possible Flows that react to external events should preferably use: * Event Received * Webhook * Form Event instead of a scheduled trigger. Event-driven flows are usually: * Faster * More efficient * Less resource intensive *** ## Concurrency ### Prevent concurrent execution when needed Many flows should not run concurrently. Examples: * Queue processing flows * Flows using temporary ResultSets * Sequential synchronization processes The number of concurrent executions can be configured using the dataflow property: `Max instances` The default value is: `1` For many flows, this default should remain unchanged. *** ### Use controlled concurrency when required Some scenarios benefit from concurrent execution. Examples: * Webhook processing * Insert-only operations * Lightweight event handling In these cases: * Set concurrency to a controlled maximum * Avoid unlimited parallel executions Recommended settings: * `Max instances = 10` * `On max exceeded = Queue flow` This prevents overload while still allowing parallel processing. *** ## Nodes ### Use clear node names Always give nodes a meaningful and recognizable name. Node names are visible in: * Reports * Logging * Error messages * Monitoring Good naming makes troubleshooting significantly easier. *** ### Use node colors Dataflows allow nodes to be assigned colors. Use colors to: * Group related logic * Highlight important paths * Improve readability Consistent coloring makes large flows easier to understand. *** ### Use Preconditions whenever possible Several nodes support the **Precondition** property. Use Preconditions to prevent unnecessary execution paths. Example: * If a ResultSet contains no rows, there is no reason to continue processing that path Benefits: * Better performance * Lower execution time * Reduced unnecessary processing *** ## Analysis ### Regularly review flow analysis Since version **5.1**, DataHub includes an **Analysis** feature. When opening a dataflow, the platform analyzes: * Nodes * Configuration * Potential issues The analysis can detect: * Configuration mistakes * Potential runtime problems * Performance concerns Review these warnings regularly and resolve issues where possible to reduce errors and improve stability. *** ## Summary A good dataflow should be: * Small * Predictable * Easy to understand * Event-driven where possible * Protected against unnecessary concurrency * Properly documented Applying these best practices helps create reliable and maintainable Any2Info DataHub solutions. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://academy.any2info.com/any2info-academy/no-code-platform/data-studio/data-hubs/data-flows/best-practices.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.