# Examples

Source: https://userguide.qualytics.io/fields/computed-fields/deep-dive/examples/

Four production patterns for Computed Fields across type coercion, identity, standardization, and categorization. Each uses the transformation type that fits the shape of the derived value.

**Tab: Numeric Cast for Aggregation**

**Context.** A finance team's `orders` container carries an `order_total` column ingested as a string (`"1234.56"`, `"25.00"`, `"1899.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.

> **Note**
>
> Cast only accepts values that are already plain numbers. A value with a thousands separator or currency symbol (for example `"1,899.99"`) makes the cast fail. Saving the field checks only a sample of records, so such a value can be caught when you save or only later, when a scan reads it. Use the [Convert Formatted Numeric](https://userguide.qualytics.io/fields/computed-fields/deep-dive/transformation-types/#convert-formatted-numeric) transformation for that data instead.

| Field | Value |
| --- | --- |
| Transformation Type | Cast |
| Source Field | `order_total` |
| Target Type | `decimal(10,2)` |

**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.

**Tab: Derived Full Name**

**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.

```sql
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.

**Tab: Cleaned Company Names**

**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.

**Tab: Revenue Buckets**

**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.

```sql
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.

*Last updated: October 6, 2026.*