Low code and no code: understand configuration, extensions and testing
By Ai Flowi · Published
Low code is a development approach that uses visual configuration and reusable components to reduce the amount of handwritten code needed for an application or workflow. No code describes an approach intended to complete the supported task through configuration without writing code. Both still require decisions about inputs, permissions, failure handling and what counts as a correct result.
The boundary depends on the task. Selecting existing components can be a configuration task, while writing a transformation expression or a custom component adds code that someone must maintain. A visual canvas does not remove that responsibility.
What is low code and no code?
A graphical builder offers predefined operations, configuration fields and connections. It can make an existing operation accessible without rewriting its implementation. Low-code work may combine these operations with expressions or extensions. No-code work stays within the configured features available for the particular task, rather than extending the platform’s behaviour.
These labels are not a quality measure. A short manual procedure can be sufficient for an occasional review, and a configured workflow can be appropriate for repeated work with a stable contract. Decide what needs to happen first. Building a workflow around an unsettled rule merely makes an unsettled rule run repeatedly.
Related: RPA and AI.
A supplied CSV check makes the boundary visible
Consider a fictional CSV containing request_id, category and requested_units. The supplied rule requires a nonblank text identifier, category equal to standard or exception, and a whole-number unit count from one to five. A repeated identifier must be held for review. These limits are invented for the teaching example and are not product limits.
The desired output is an accepted-record list plus an exception list carrying the source row reference and rejection reason. No external write is needed. A valid-looking count of output rows is insufficient if the accepted list lost an identifier, merged two records or converted an empty value into zero.
Three ways to perform the same illustrative CSV check: on narrow screens, focus the table region and scroll sideways.
| Approach | Work performed | Responsibility that remains |
|---|---|---|
| Manual processing | Reviewer checks each supplied record against the written rule and records exceptions. | Apply the same rule consistently and preserve source identity. |
| Graphical configuration | Load records and use available configured operations for checks the builder actually exposes. | Verify parsing, accepted types, rejection paths and unsupported rules. |
| Coded expression or extension | Implement the missing validation or duplicate rule when existing settings cannot express it. | Maintain logic, error behaviour, runtime compatibility and regression checks. |
The table compares methods for one task, not products or claimed speed. If a native feature already covers the rule, reuse it. If the task happens once and inspection is manageable, a manual check may require less maintenance than an automated pipeline. An extension is justified by an unmet requirement, not by the presence of a code editor.
Configuration still needs a data contract
Define how the parser presents blank cells, numeric-looking identifiers and unexpected columns. The identifier “001A” should remain distinct from “1A” unless the written identity rule says otherwise. A whole-number requirement needs an explicit interpretation; accepting arbitrary numeric text can admit a value the downstream operation was not designed to handle.
Keep input validation before any consequential action. Inspect the actual parsed rows rather than assuming the input file’s appearance determines the runtime type. If required headers disappear, stop and record the schema mismatch. Silently continuing with empty fields can make an apparently successful run produce unusable output.
The workflow basics reference owns typed connections and configuration detail. A connected port indicates declared type compatibility, not successful execution of the CSV rule. That distinction applies whether the workflow uses only configuration or includes an expression.
Documented components for the example
The Load CSV, JSON Operations and Verification Router references own their interfaces; this CSV-check proposal is documented in the catalogue; not production-tested by Ai Flowi.
example configuration, not a recorded test: supply the authorised synthetic file through Load CSV’s csv_file, then use JSON Operations with operations set to the exact option JQ Expression
and query containing the reviewed validation expression. Inspect the returned decision before supplying Verification Router’s verification_result. You need a workspace and permission to read the file; this sketch uses no model or external provider. The intended accepted and exception lists remain unexecuted.
Decide what can stay in configuration
For the supplied category check, first inspect whether a documented operation can compare the two allowed values without extra code. For the repeated-identifier rule, inspect whether the available configuration can compare records across the entire file, rather than only checking one row. A row-level blank check and a file-level uniqueness check have different scopes. Passing the former does not establish the latter.
If a reviewed expression supplies the missing file-level comparison, this implementation belongs on the low-code side of the task: somebody now maintains executable logic. Record the expression revision beside the rule revision. If the permitted unit range later changes, update that logic and rerun the boundary cases before accepting new files. A visual connection can remain identical while its validation meaning changes.
Keep an exceptional one-off correction out of the reusable checker unless it becomes an approved rule. For example, a reviewer might manually repair one authorised row’s missing identifier using its source reference. Baking that repair into every future run would silently turn missing identity into an inferred value. Return the exception for review instead of adding a special case that changes the contract.
An extension changes who maintains behaviour
The custom-components reference documents Python behaviour for requirements existing components do not cover. Status: documented for that extension mechanism, with no executed CSV-extension test asserted here. A custom component is an implementation you maintain, even when it sits beside built-in nodes on the canvas.
Before extending, identify the exact missing rule. A duplicate-identifier check may need a small expression rather than a new component. If an extension is necessary, name who maintains it and retain a small runnable check that fails when the rule breaks. Decide how errors are represented and what the next component accepts; an exception hidden as an empty accepted list can conceal lost work.
Testing follows the rule, not the canvas
For the supplied contract, inspect a valid row, blank identifier, repeated identifier, unknown category, fractional units and an out-of-range count. Include a quoted CSV field containing a separator to check parsing. Verify the accepted identities and exception reasons, rather than only checking that the flow produced something.
Keep source records unchanged during this trial so a failed check is reversible. If a later version writes to a provider, it needs its own authorised account or API credential and provider billing arrangements; third-party API and model usage is not included. That added boundary needs a separate write and failure check.
Common mistakes and related terms
Less code does not mean fewer acceptance requirements. Avoid adding extensions before reading the catalogue, treating typed edges as tests, or assigning maintenance to nobody. The evaluation checklist owns broader task-fit evidence. Workflow orchestration addresses stage dependencies and recovery, while reverse ETL explains the additional decisions introduced by an operational write.