The Low-Code expression language is a provider-safe scalar profile used by virtual calculated properties and by the one-time **Formula** option for existing-data backfill. Its syntax is intentionally familiar to Power Fx users, but it is a smaller language designed for server validation and database-provider translation.
The Low-Code expression language is a provider-safe scalar language used by virtual calculated properties and by the one-time **Formula** option for existing-data backfill. It is designed for server validation and database-provider translation.
Expressions are not JavaScript. They cannot contain arbitrary code, SQL, network calls, browser APIs, side effects, or unsupported Power Fx table and record operations.
Expressions are not JavaScript. They cannot contain arbitrary code, SQL, network calls, browser APIs, side effects, or table and record operations.
An expression can contain up to 4096 characters.
@ -65,11 +65,12 @@ The current scalar profile supports these functions:
| Date and time | `Year(value)`, `Month(value)`, `Day(value)`, `Hour(value)`, `Minute(value)`, `Second(value)`, `Date(year, month, day)`, `DateTime(year, month, day, hour, minute, second)`, `DateAdd(value, days[, "day"])`, `DateDiff(startValue, endValue[, "day"])` |
Examples:
@ -79,11 +80,18 @@ Coalesce(Discount, 0)
Round(UnitPrice * Quantity, 2)
FirstName & " " & LastName
Mid(ProductCode, 2, 3)
Contains(Name, "pro")
Value(UnitPriceText) * Quantity
DateDiff(StartDate, EndDate)
```
`Round` uses midpoint-away-from-zero semantics. `Mid` uses a one-based start position. `Date` and `DateTime` require literal numeric components in the provider-neutral profile. Numeric and date literals use invariant syntax; browser and database locale settings do not change their meaning.
`Round` uses midpoint-away-from-zero semantics. `RoundDown` rounds toward zero and `RoundUp` rounds away from zero; their decimal-place argument must be a literal from -6 through 6. `Mid` and `Replace` use a one-based start position. `StartsWith`, `EndsWith`, and `Contains` ignore case.
Functions from the full Power Fx language that are not listed here are rejected. For example, `Floor`, `Ceiling`, `Concat`, and `Substring` are not aliases for the supported scalar functions.
`Text` accepts numeric or text values. `Value`, `Boolean`, `DateValue`, and `DateTimeValue` parse invariant text; `DateValue` expects `yyyy-MM-dd`, while `DateTimeValue` accepts invariant ISO date-time text. `Int` rounds down to the nearest integer.
`Date` and `DateTime` require literal numeric components in the provider-neutral profile. `DateAdd` and `DateDiff` currently support calendar days only; omit the unit or use the literal `"day"`. Calendar calculations follow the Gregorian calendar, including leap years. Numeric and date literals use invariant syntax; browser and database locale settings do not change their meaning.
Functions that are not listed here are rejected. For example, `Floor`, `Ceiling`, `Concat`, and `Substring` are not aliases for the supported scalar functions.
## Local values with `With`
@ -118,7 +126,9 @@ Related-record aggregates are not written inside a formula expression. Create a
## Validation errors
The Designer validates syntax, field and related-field references, function arity and argument types, inferred result type, dependency cycles, server-only exposure, and translation by the active database provider. Validation covers transitive calculated dependencies, not only the expression currently being edited.
Select **Validate** before saving a calculated property. The Designer validates syntax, field and related-field references, function arity and argument types, inferred result type, dependency cycles, server-only exposure, and translation by the active database provider. Validation covers transitive calculated dependencies, not only the expression currently being edited.
When validation succeeds, the action changes to **Save**. Changing the expression or any property setting returns the action to **Validate**, so the saved metadata always matches the validated values.
2. Open **Add Property** and select **Calculated Property**.
3. Enter the property name and an optional display name.
4. Enter an expression such as `Round(UnitPrice * Quantity, 2)`.
5. Review the inferred result type and validation result, then select **Create Calculated Property**.
5. Select **Validate** to infer the result type and verify the formula with the active database provider.
6. Configure any settings exposed for the inferred type, such as decimal places or currency symbol, then validate again.
7. When the action changes to **Save**, select it to create the property.
The result type is inferred from the expression. Supported property types are String, Int, Long, Decimal, Money, Boolean, Date, and DateTime. Decimal and Money results can also define display precision, and Money results can define a currency symbol.
@ -82,7 +84,7 @@ This is different from the one-time **Formula** option used to backfill an ordin
## Validation and dependency safety
Before a calculated property is saved, the Designer validates:
Before a calculated property is saved, select**Validate**. The Designer validates:
* syntax, field paths, functions, and argument types
* inferred result type and display metadata
@ -91,12 +93,14 @@ Before a calculated property is saved, the Designer validates:
* server-only dependency exposure
* translation by the active database provider
Successful validation changes the action to **Save**. Editing the name, display name, expression, server-only setting, or inferred-type settings such as decimal places and currency symbol invalidates the validation result and changes the action back to **Validate**.
Saving publishes the calculated metadata only after the complete affected dependency closure passes provider validation. Renaming or deleting fields that are still referenced is guarded so an existing calculation is not silently broken.
Provider-specific translation remains authoritative. An expression that is syntactically valid but cannot be translated by the active provider is rejected instead of falling back to full-table client-side evaluation.
## Current limitations
Formula expressions are scalar. They do not contain arbitrary aggregate subqueries; use a Rollup Property for a supported related-record aggregate. Arbitrary SQL, JavaScript, network calls, browser APIs, side effects, and unsupported Power Fx table or record operations are not allowed.
Formula expressions are scalar. They do not contain arbitrary aggregate subqueries; use a Rollup Property for a supported related-record aggregate. Arbitrary SQL, JavaScript, network calls, browser APIs, side effects, and table or record operations are not allowed.
Related-field access must follow configured foreign keys and stay within the query capability exposed by the backend. Rollups require a source-side Guid foreign key that points to the entity receiving the rollup.