docs: add low-code expression language reference

docs/en/low-code/expression-language.md

@@ -0,0 +1,101 @@
+```json
+//[doc-seo]
+{
+    "Description": "Reference for the ABP Low-Code expression language used by calculated properties, mappings, defaults, and validations."
+}
+```
+
+# Low-Code Expression Language
+
+The Low-Code expression language is a small, provider-safe language used in more than one designer workflow. It is used by formula properties and can also be used where the designer asks for an expression-backed value, such as mapped-property initial values or existing-data backfills.
+
+The v1 syntax is intentionally familiar to Excel, Airtable, and Power Fx users while remaining translatable to a server-side expression tree. Expressions are evaluated by the server; they are not JavaScript and must not contain arbitrary code, SQL, network calls, or browser APIs.
+
+> **Preview:** The language profile is preview functionality. The supported function set is deliberately smaller than the complete Excel or Power Fx languages.
+
+## Values and field references
+
+Use numbers, quoted strings, Boolean values, and date constructors as literals. Reference a property by its name:
+
+```text
+UnitPrice * Quantity
+If(IsActive, "Enabled", "Disabled")
+Date(2026, 7, 28)
+```
+
+Property names containing spaces can be enclosed in single quotes:
+
+```text
+'Unit Price' * Quantity
+```
+
+Names and function names are case-insensitive. A field reference is resolved against the current entity, including fields backed by JSON and fields mapped to database columns.
+
+## Operators
+
+| Purpose | Operators and forms |
+| --- | --- |
+| Arithmetic | `+`, `-`, `*`, `/`, `%` |
+| Comparison | `=`, `<>`, `!=`, `<`, `<=`, `>`, `>=` |
+| Logical | `And(a, b)`, `Or(a, b)`, `Not(a)`, `&&`, `||`, `!` |
+| Text concatenation | `&` |
+| Percentage | `10%` (equivalent to `10 / 100`) |
+
+`<>` and `!=` are equivalent not-equal operators. Use parentheses when combining arithmetic, comparison, and logical operators so the intended order is clear.
+
+## Functions
+
+The v1 profile supports the following functions:
+
+```text
+If, Coalesce, IsBlank,
+Abs, Round, Floor, Ceiling, Min, Max,
+Concat, Lower, Upper, Trim, Len,
+Left, Right, Mid, Substring,
+Year, Month, Day, Date, DateTime
+```
+
+Examples:
+
+```text
+If(Len(Name) > 5, "Long", "Short")
+Coalesce(Discount, 0)
+Round(UnitPrice * Quantity, 2)
+Concat(FirstName, " ", LastName)
+```
+
+`Round(value, places)` uses midpoint-away-from-zero semantics. Numeric and date literals use invariant syntax; the browser or database locale does not change their meaning.
+
+## Local values with `With`
+
+Use `With` to name intermediate values and avoid repeating calculations:
+
+```text
+With(
+  {
+    subtotal: UnitPrice * Quantity,
+    rebate: Coalesce(Discount, 0)
+  },
+  If(subtotal > 100, Round(subtotal - rebate, 2), subtotal)
+)
+```
+
+Local variable names must not match properties on the current entity. This rule prevents an ambiguous reference during server-side translation.
+
+## Where expressions run
+
+The expression is compiled and validated on the server. For materialized values, writes are performed as provider-side operations so filtering, sorting, paging, and projections remain database operations. The server does not load the complete table into application memory to calculate a column.
+
+The language does not support cross-row lookups, arbitrary SQL, JavaScript, network calls, or aggregate queries inside a row expression. Use a relation/query endpoint or a custom server endpoint for those scenarios.
+
+## Validation errors
+
+The designer checks syntax, field references, function names, result type, dependencies, and provider translation before publishing an expression. Common errors are:
+
+* unknown property or function
+* incompatible result type
+* a `With` variable that collides with an entity property
+* an operation that the active provider cannot translate
+* a missing expression in a Formula backfill configuration
+
+See [Formula Properties](formula-properties.md) for the materialized-column workflow and storage behavior.

docs/en/low-code/formula-properties.md

@@ -0,0 +1,46 @@
+```json
+//[doc-seo]
+{
+    "Description": "Define provider-side calculated properties in the ABP Low-Code System with Power Fx-like expressions."
+}
+```
+
+# Formula Properties
+
+Formula properties are calculated properties in the Low-Code property model. Their values are materialized by the server, so filtering, sorting, paging, and projections continue to use the database provider instead of loading the whole entity set into application memory.
+
+> **Preview:** Formula properties and the expression profile are preview features. Supported functions and provider translation may change before general availability.
+
+## Create a formula property
+
+In the Low-Code Designer, open the normal **Add Property** flow, select the result type, and enable **Calculate with a formula**. The formula result uses the selected property type:
+
+* String
+* Int or Long
+* Decimal or Money
+* Boolean
+* Date or DateTime
+
+Formula values are server-authoritative. Values supplied by the client are ignored for the calculated property.
+
+## Expression syntax
+
+See the [Low-Code Expression Language](expression-language.md) reference for operators, functions, literals, `With`, and provider translation rules.
+
+## Storage and mapping
+
+Formula storage is independent of the expression language. A formula property can be JSON-backed or mapped to a physical database column. Mapped properties use the public property name as their column identity and are recalculated on create, update, and deployment backfill.
+
+Formula properties may reference both mapped and JSON-backed fields. For existing-data mapping, choose a fixed value or **Formula** backfill. Required database columns remain nullable during schema evolution unless an explicit backfill is requested.
+
+## Query and performance behavior
+
+Formula updates are set-based and provider-side. The server recalculates affected rows and refreshes only the bounded saved-key batch needed by the current operation. It does not fetch the entire table into memory.
+
+Materialized results can be used by normal database filtering, sorting, paging, count, projection, and supported aggregates. Cross-row lookups, arbitrary SQL, network calls, and aggregate queries inside a row formula are outside the v1 profile.
+
+## Validation and deployment
+
+The Designer validates syntax, referenced fields, result type, dependencies, and provider-translatable operations before deployment. A syntactically valid expression is not active until deployment/backfill succeeds. Failed deployments can be retried from the Designer.
+
+Common validation errors include unknown fields or functions, result type mismatches, a `With` variable colliding with a property name, unsupported provider operations, and a missing expression when Formula backfill is selected.

docs/en/low-code/index.md

@@ -109,7 +109,9 @@ The screens below follow that common designer flow from data to page setup to fo
 
 ![Page setup in the designer](images/designer-page-filters.png)
 
-![Form setup in the designer](images/designer-forms.png)
+![Form setup in the designer](images/designer-forms.png)
+
+For calculated fields that are materialized and remain queryable like normal properties, see [Formula Properties](formula-properties.md). For the shared syntax used by formulas, mappings, defaults, and backfills, see the [Low-Code Expression Language](expression-language.md) reference.
 
 ## React Runtime