> For the complete documentation index, see [llms.txt](https://docs.agilecase.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.agilecase.com/developer-documentation/case-scripting/on-save-scripts/examples/banding-a-number-into-a-value.md).

# Banding a Number Into a Value

Plenty of business rules amount to putting a number into a bracket: an excess from a claim value, a fee from an order size, a review level from a score. The script reads the number, works out which band it falls in, writes the answer to another field, and separately raises an alert if the number is large enough to need a person.

## The scenario

A claims handler enters the reserve on a claim. For household and motor policies the policy excess follows a published scale. Any reserve of £25,000 or more also needs the senior claims manager to know.

| Setting       | Value                                 |
| ------------- | ------------------------------------- |
| Trigger field | `5302` Claim reserve (£)              |
| Read          | `5303` Product line                   |
| Written       | `5304` Policy excess                  |
| Applies to    | Product lines `HOUSEHOLD` and `MOTOR` |
| Template      | `HighValueClaimAlert`                 |

## The script

```javascript
[Changed.CustomField(5302).Changed]

function after_save() {
    var productLine = Service.CustomField("5303").ValueAsText;
    var reserve = parseFloat(Changed.CustomField("5302").NewValueAsText);

    if (isNaN(reserve)) {
        return true;
    }

    var excess;
    if (reserve > 100000) {
        excess = "1000";
    } else if (reserve > 50000) {
        excess = "500";
    } else if (reserve > 25000) {
        excess = "350";
    } else if (reserve > 5000) {
        excess = "250";
    } else if (reserve > 0) {
        excess = "100";
    } else {
        excess = "0";
    }

    if (productLine == "HOUSEHOLD" || productLine == "MOTOR") {
        Service.UpdateCustomField("5304", excess);
    }

    if (reserve >= 25000) {
        Service.SendEmail("HighValueClaimAlert");
        Service.AddMessage("This reserve is £25,000 or more, so senior claims have been alerted.", "notify-success");
    }

    return true;
}
```

## Reading the number

The reserve is read with `parseFloat` over `NewValueAsText` rather than through `NewValueAsNumber`, and for money that is not a stylistic choice.

{% hint style="warning" %}
`ValueAsNumber` and `NewValueAsNumber` handle whole numbers only. A field holding `12500.50` reads as `0` through them, not `12500`, so a script relying on them would band a large claim as if it were worth nothing. Read `ValueAsText` and convert with `parseFloat` whenever the value can carry decimals.
{% endhint %}

Because `parseFloat` returns `NaN` for anything it cannot read, including an empty field, the script checks for that first and does nothing. Skipping the check would not throw an error but would silently fall through every comparison to the `else` and write an excess of zero.

## Ordering the bands

The bands are tested from the largest down, and each one only needs its lower bound. Once a reserve of £60,000 has failed the test for £100,000 there is no need to also confirm it is under £100,000, because the earlier branch would have caught it. Writing each band as a range instead is where this pattern usually goes wrong:

```javascript
// Always true, whatever reserve holds
if (50000 < reserve < 100000) { }
```

JavaScript evaluates that left to right, comparing `50000 < reserve` to get `true` or `false`, then comparing that to `100000`, which is always true. If you do want an explicit range, join two comparisons with `&&`.

## Separating the two decisions

Writing the excess and sending the alert are deliberately independent. The excess is only written for two product lines, but the alert goes out for any product line, because a large reserve matters whether or not there is a scale for it. Keeping the conditions apart rather than nesting them means adding a third product line later does not quietly change who gets alerted.

The email is sent from `after_save` so that a template quoting the reserve shows the figure just entered rather than the one it replaced.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.agilecase.com/developer-documentation/case-scripting/on-save-scripts/examples/banding-a-number-into-a-value.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.