Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.elementum.io/llms.txt

Use this file to discover all available pages before exploring further.

Calculations work well for single-value math, text, dates, and conditional logic against a single record or a related set of records. A handful of shapes and operations behave differently than people expect — especially folks coming from spreadsheets or SQL. This page collects the most common gotchas, the errors you’re likely to see, and the recommended path forward for each. If you’re here because of a specific error, jump to the Error reference.
This page reflects current behavior. Where a section notes that something isn’t supported, it may change in a future release — the section will say so when that’s the case.

​
Multi-value and array-shaped values

The most common source of confusion. Two related shapes:
  • Multi-picklist fields — fields whose type is MULTI_PICKLIST. A single cell holds several selected options.
  • Multi-value text columns surfaced through Data Mine — when a Data Mine trigger fires, multi-value text columns in the payload serialize as a JSON array of objects, not as plain text. The shape looks like this:
[
  { "value": "WD", "type": "TEXT" },
  { "value": "ZIP", "type": "TEXT" }
]
Both shapes are lists of values, and almost every calculation function expects a single value at a time. The two limitations below cover what that means in practice.

​
Aggregating a multi-picklist into a delimited string

Not currently supported. Aggregations over list-typed fields aren’t supported in calculations. What people try: 
STRING_AGG_UNIQUE(CLAI."Claim Edit(s)", ',')
What they get: 
Invalid Type Error at line 1, position 18: MULTI_PICKLIST
STRING_AGG and STRING_AGG_UNIQUE only accept single-value text supplied via a related-field aggregation — they cannot operate on a MULTI_PICKLIST field directly. There is no calculation function that aggregates the selections of a multi-picklist into a delimited string.

​
Flattening a Data Mine array payload into plain text

Not currently supported. Calculations cannot convert structures — the [{"value":..., "type":...}, ...] shape that Data Mine produces for multi-value text columns cannot be flattened into plain delimited text inside a calculated column or the field mapping on a Create Record action. What happens if you try: the destination text field stores the literal JSON, for example: 
[{"value":"WD","type":"TEXT"},{"value":"ZIP","type":"TEXT"}]
…rather than the friendly WD, ZIP users expect.

​
SPLIT returns an array you can’t index into

SPLIT(text, delimiter) returns an array of substrings. That’s expected — but selecting a single element from that array isn’t supported in calculations. There’s no array indexing syntax ([0], [1], etc.) and no INDEX/NTH function to pick a piece. Example of the trap: 
// Returns the array ['TPFN', '123'] — but you can't extract 'TPFN' from it.
SPLIT('TPFN-123', '-')
Recommended patterns:
  • If the position is genuinely fixed (for example, every ID is always exactly 4 characters), use LEFT, RIGHT, or MID. These return text you can use directly.
  • If the split point is variable (for example, “everything before the dash”), combine FIND or SEARCH to locate the delimiter with LEFT/MID to extract the piece you want:
// 'Everything before the first dash' in CONTRACTS."Reference"
LEFT(CONTRACTS."Reference", FIND('-', CONTRACTS."Reference") - 1)
The LEFT/RIGHT/MID pattern only stays correct while the position is truly fixed. If the value’s length can change — for example, IDs growing from 99 to 100 add a character — the calculation will silently start returning the wrong substring without raising an error. For anything length-variable, use the FIND/SEARCH + LEFT/MID pattern instead.

​
DATEVALUE only accepts year-month-day input

DATEVALUE(text_date) doesn’t auto-detect or parse arbitrary date formats. The input must be in YYYY-MM-DD form — date only, no time component. Other formats won’t parse and the function returns blank, including:
  • US-style MM/DD/YYYY or European DD/MM/YYYY
  • Written-out months like Jun 1, 2026
  • ISO 8601 strings with a time component like 2026-06-01 12:34:56 or 2026-06-01T12:34:56Z
Recommended patterns:
  • Normalize date text to YYYY-MM-DD in the source system or an ingest step before it reaches the calculation.
  • If the components are available as separate values, skip DATEVALUE entirely and build the date with DATE(year, month, day).
  • For text dates with predictable structure, use LEFT/MID/RIGHT to rearrange the pieces into year-month-day before passing to DATEVALUE.

​
Regex syntax: Java-style

REGEXEXTRACT, REGEXMATCH, and REGEXREPLACE are fully supported. Standard regex operations — character classes, quantifiers, groups, anchors, alternation, backreferences — work as expected.
REGEXEXTRACT returns the first match only, and REGEXREPLACE replaces the first match only — not a list of matches and not every match in the string. There is no built-in way to extract or replace every match in one call.
Patterns follow Java-style regex syntax because of the backend implementation. If you’re porting patterns from JavaScript, Python, or PCRE-flavored tools, most expressions work unchanged, but watch for the differences that bite:
  • Escaping inside string literals — calculation text is enclosed in single quotes, so backslashes in patterns need to be escaped: write '\\d+' (not '\d+') to match one or more digits.
  • A few advanced constructs — possessive quantifiers (*+, ++) and certain Unicode property classes behave per the Java spec, not PCRE.
The Java Pattern javadoc is the authoritative syntax reference. When in doubt, test the pattern with a small string against REGEXMATCH before building a larger calculation around it.

​
Concatenating strings

CONCAT(a, b, c, ...) is the function to join text values. The + operator is for numeric addition only — applying it to text fields does not concatenate them. This is a common surprise for people coming from JavaScript, PHP, or some spreadsheet languages where + doubles as a string-concatenation operator. 
// Correct — produces 'Jane Doe'
CONCAT(CUSTOMERS."FirstName", ' ', CUSTOMERS."LastName")

// Incorrect — '+' is numeric addition only; this does not concatenate text
CUSTOMERS."FirstName" + ' ' + CUSTOMERS."LastName"
CONCAT accepts any number of arguments and converts non-text values (numbers, dates) to text automatically before joining.

​
Changing a column’s field type

Not supported. A column’s field type cannot be changed in place after the column is created. This applies to all type conversions — single-value text ↔ multi-value text, text ↔ multi-picklist, and so on. Recommended pattern — create a new column of the desired type, then delete the old one. If the old column has data you need to preserve, backfill the new column via an automation or import before deleting the old, and update any dependencies (calculations, automations, filters, layouts) to point at the new column.

​
Error reference

Error you seeWhat it meansWhere to go
Invalid Type Error at line N, position M: MULTI_PICKLISTA calculation function received a MULTI_PICKLIST field where it expected a single value.Aggregating a multi-picklist into a delimited string
Destination field stores literal JSON like [{"value":"...","type":"TEXT"}, ...]A Data Mine multi-value text payload was passed to a plain-text destination without being flattened.Flattening a Data Mine array payload into plain text
DATEVALUE returns blank for a date that “looks valid”The input isn’t in year-month-day form.DATEVALUE only accepts year-month-day input
Expected to pull “the first piece” out of a SPLIT result and got nothing usableSPLIT returns an array, but array indexing isn’t supported.SPLIT returns an array you can’t index into