Examples

Context. A finance team's orders container carries an order_total column ingested as a string ("1234.56", "25.00", "1,899.99"). Aggregation quality checks (sum, mean, standard deviation) fail against a string column, and comparing string values sorts them lexicographically.

What happens. A Computed Field named order_total_numeric uses the Cast transformation with order_total as the source field and decimal(10,2) as the target type. The derived field is now a real numeric column, and aggregation checks target it directly.

Why it works. Cast is the specialized path for data-type conversion, so validation catches an invalid target type up front and the runtime is faster than a Custom Expression. Because the derived value is a real numeric field, quality checks like expectedValues, predictedRange, and aggregationComparison all work as expected.

Context. A CRM team ingests customer records with first_name and last_name as separate columns. Reports and quality checks read full_name, but the source system does not maintain that field.

What happens. A Computed Field named full_name with a Custom Expression transformation concatenates the two source fields into a single derived column. The Computed Field appears alongside the container's native fields and is available to quality checks (for example, a completeness check that flags empty full names) and downstream reporting.

concat_ws(' ', first_name, last_name)

Why it works. Custom Expression handles the multi-field combination in a single declaration, and concat_ws skips null components so a missing first name still produces a non-empty result. Because the field is computed on demand, it always reflects the current values of first_name and last_name without needing a downstream ETL step.

Context. A revenue-operations team maintains an accounts table where company names arrive with inconsistent business signifiers: Acme Inc., Acme, LLC, Acme Corp. Deduplication and matching against reference lists depend on a canonical form.

What happens. A Computed Field named company_name_clean uses the Cleaned Entity Name transformation. Term Settings drop the common suffixes (Inc., LLC, Corp, Ltd.) and additional interior tokens as needed. The Computed Field carries the clean value; downstream quality checks (uniqueness on the clean form, existsIn checks against a reference table) target it.

Why it works. Cleaned Entity Name is declarative: reviewers can read the drop lists and understand what is happening without decoding a regular expression. When a new signifier appears in the source data, editing the term list is a one-line change that revalidates the field on the next profile.

Context. A finance team categorizes each customer's monthly revenue into low, mid, and high buckets for segmentation and quality checks. The bucket boundaries change with business seasonality, so hard-coding them in downstream reports has caused drift.

What happens. A Computed Field named revenue_bucket uses a Custom Expression with a CASE statement that reads the container's monthly_revenue field and produces the label. Quality checks confirm the field is never null and that the distribution across buckets matches expectations.

CASE
    WHEN monthly_revenue < 1000 THEN 'low'
    WHEN monthly_revenue < 10000 THEN 'mid'
    ELSE 'high'
END

Why it works. Encoding the segmentation as a Computed Field centralizes the boundary definitions in one place. When boundaries shift, editing the transformation re-registers the definition and the next profile applies the new rules to every row. Reports and quality checks that read revenue_bucket stay in sync automatically.