Author a new rule function

Compose a transform the deployed catalog does not have, see what it does, and open it for review

Back to the rule builder

Compose the transform as an ordered list of operations, see it run on your own sample values, then open it for review.

What you are composing

An ordered list of operations, applied left to right to one value. Operation 1 takes the piped value — for a rule, the source column it binds; each operation after that takes the result of the one before it.

There is no SQL field here

You are not writing a function body. This surface accepts no SQL, and the file it produces carries none — the statement is rendered from these operations by the rules-engine pipeline after a merge.

A transform this list cannot express is hand-written by an engineer in rules-engine, under that repository's review.

What the function is

Upper case letters, digits and underscores, at least three characters. Bare name only — the service adds the catalog's qualifier.

At least eight characters. It is the only prose a reviewer gets about intent, and it lands in Git permanently, so no patient data.

Whether the catalog should have this function, rather than whether the logic is right. Permanent and org-visible.

By name, so a reviewer can find it. Advisory — the dependency that blocks a deploy is declared on the rule.

What it takes

Position 1 is the value piped in — every function has one and no rule ever supplies it. Positions 2 and after are configuration each rule supplies when it calls this function.

Parameter 1 — value

The key a rule's parameter binding looks up. A key, never a value.

A date-typed parameter rejects an unreadable value with an error rather than resolving it to nothing.

Follows from the position, not chosen: position 1 is the piped value, everything after it is configuration.

The piped value

Position 1 cannot be removed: a function with no input has nothing to transform.

What it does, step by step

Each stage is one operation. The fields under it are the operands that operation takes, so they change with the operation.

Stage 1

Chosen from the closed list. There is no free-text operation and no way to name one that is not here.

An ordered list of operations, applied left to right to one value. Operation 1 takes the piped value — for a rule, the source column it binds; each operation after that takes the result of the one before it.

The value piped into the function — parameter 1

A pipeline needs at least one stage.

This pipeline, in order

Choose an operation for each stage and it appears here.

Sample values to try it on

Your own values, or made-up ones. No column is read — this function has nothing bound to it yet.

Up to 20 values.

Values for this function's own parameters

This function declares no configuration parameters, so there is nothing to supply for the preview.

What it gives back

Determined by the last operation, not chosen. It decides the datatype of the _XFR column every rule bound to this function writes.

Choose the operations above and the return type follows from the last one.

Derived from the operations. A pipeline that compares against today's date depends on when it runs, and the deployed function has to say so.

Same input, same result, always
More about the datatype

There is no datatype picker here or in the rule builder. Where a function returns text no numeric target is offered — a fax number's leading zero, extension or + prefix is a real value a numeric column would destroy.

The catalog's FUNCTION_OUTPUT_TYPE says SCALAR for every registered function. That is scalar-versus-table, not a datatype; the datatype lives in the deployed function's return clause.

The result can always be nothing: every operation in the list can resolve a value to nothing.

What a rule will have to supply

The three numbers that must agree.

Arguments the catalog will record
1
Parameters the deployed function will declare
1
Arguments each rule step must bind
0

One fewer than the total: position 1 is the piped column value and no rule supplies it.

Reported by the service when the definition is checked.

This pipeline, in order

3 fields must be resolved before this definition can be checked.

Check it and see what it does

Checks the definition and shows what it does to your sample values. It runs inside the service — no warehouse statement, no function created. Asking twice is free.

The definition is not complete yet, so there is nothing to check. The field messages above say what is missing.

The definition has not been checked yet.

Submit it for review

Records this definition as a proposal awaiting approval. It creates no function anywhere.

Submitting is blocked: the definition is not complete yet.

Approval

This commits one file — the function's definition, with no SQL text in it — on a new branch and opens one pull request against the rules-engine repository.

It creates no function, in any environment. It executes no statement against any warehouse, applies nothing, promotes nothing and deploys nothing. The studio holds no privilege to do any of those things, in any account.

A different person still has to merge it. That merge is the human gate, enforced by the rules-engine repository's own branch protection, and the studio cannot perform it or bypass it. The function comes into existence when that repository's pipeline applies the merged file — separately in each environment.

There is no merge, promote, deploy or apply action on this screen, and none is shown greyed out. The studio holds no permission to merge and must not imply that it does.

There is nothing to approve yet. A definition can be approved only after it has been submitted.