Reusable Functions
User Guide — Building Reusable Business Logic for Your Pipeline
| Last updated: August 2026
Contents
- Overview
- The Big Idea: What a Function Is
- Key Terms
- Finding Your Way Around
- The Life of a Function
- Creating a Function — the Add Function Wizard
- Managing a Function — the Detail Page
- Building Statements
- Submitting for Approval
- Making Changes Later — Versions
- Comparing Versions — the Diff Tab
- A Note on Value Mappings
- Quick Reference
1. Overview
A Reusable Function is a piece of business logic you define once and reuse across your data pipeline. Instead of rewriting the same "if the value looks like this, set it to that" rules over and over in different places, you build the rule once as a Reusable Function and point your mappings at it.
Under the hood a function is a set of conditions and the values they produce — a decision table you fill in visually, without writing raw SQL by hand. OnCoor turns what you build into the actual database logic the pipeline runs when it processes your data.
What you can do here
- Create a function through a short, guided wizard.
- Decide what a function feeds — the business attribute (or attributes) it produces values for.
- Build the logic as a list of conditions, each with the value to return when it matches.
- Send it for approval so a reviewer signs off before it goes live.
- Version it safely — make changes over time without disturbing what's already approved and running.
WHERE TO FIND IT — Reusable Functions has its own screen with a navigation rail down the left side, grouped into Browse (find existing functions), Create (start a new one), and Manage (work on the one you have open).
YOU DON'T WRITE SQL — Everything is built by picking values and conditions from menus and a visual builder. OnCoor generates the database code for you when the pipeline runs.
2. The Big Idea: What a Function Is
The easiest way to picture a function is as a table of rules read from top to bottom:
- Each row is a condition — a test like "Material Group is empty" or "Country = 'US'".
- Each column to the right is a value the function returns when that condition is true — one column for every business attribute the function feeds.
- The last row is a Return Value (else) — the catch-all that applies when none of the conditions above it matched.
OnCoor reads the rows in order and uses the first one that matches, falling back to the Return Value row if nothing does. This is the same idea as a spreadsheet's nested "IF" — but built for you, kept in one place, and reusable everywhere.
That's the whole model. The rest of this guide is about how you assemble those pieces: what the function feeds (Function Mappings), what inputs it can use (Parameters), and the rows themselves (Statements).
3. Key Terms
A few words appear throughout the screens. Here's what each one means in plain terms.
| Term | What it means |
|---|---|
| Function (Rule) | The whole reusable piece of logic — its name, its mappings, its parameters, and its rows of conditions. |
| Function Mapping | A link between the function and a Business Attribute it produces values for, tied to the concrete function name the pipeline will call. Most functions have one mapping; some feed several attributes. |
| Business Attribute | A defined business field in your model (for example, Material Group). It's what the function ultimately fills in. |
| Parameter | An input the function can refer to inside its conditions and values — think of it as a named placeholder for a piece of incoming data. |
| Statement | One row of the decision table: a condition plus the value(s) it returns. |
| Return Value (else) | The special final row that applies when no other statement matches. |
| Version | A dated snapshot of the function. New changes are made on a new version so approved logic stays untouched. |
| Domain Layer | The stage of the pipeline the function belongs to (for example, Conversion, Cleansing, or Publish). |
| Type | The kind of logic a function holds, shown as a chip in the list. Complex (marked with a Σ icon) is the standard kind you build with the wizard. You may also see Simple and Value Mapping. |
"RULE" AND "FUNCTION" ARE THE SAME THING — Some labels and screens say Rule where others say Function. They refer to the same object. This guide uses function.
4. Finding Your Way Around
Open the Reusable Functions screen. The navigation rail on the left is your map, and what it shows changes with what you're doing.
Browse is always there. List of Functions opens the full list of everything that already exists; use the search box to narrow it down when the list is long.
The list's Type column tells you what kind of logic each function holds. Functions you build with the wizard are Complex — the full decision-table logic this guide describes, shown with a Σ icon. You may also see Value Mapping functions, which are managed elsewhere and are read-only here (see section 12), and occasionally Simple functions. The type is set for you when the function is created; there's nothing to choose.
Create is where you start a new function — Create Function launches the wizard. (This entry is hidden if your role doesn't allow creating functions.)
Add Function Wizard appears only while you're inside the wizard, and shows the four steps so you always know where you are. Steps light up as you complete them.
Manage appears once you have a function open, and lists the tabs for working on it — Statements, Function Mappings, Parameters, Versions, and more. Until you open one, it simply reads "Select a function…".
TWO WAYS A FUNCTION OPENS — A function you're still building (a Draft) always opens back into the wizard so you can finish it. A function that's been created opens on the Detail Page, described in section 7.
Exporting the list
Above the list, the Export button downloads what you're currently looking at. Click the arrow beside it to choose a format — Excel (.xlsx), CSV, or JSON — and OnCoor saves a file (named with the date and time so repeated exports don't overwrite each other) covering columns like Rule Name, Description, Type, and Status.
Export mirrors your current view: if you've searched or filtered the list, only those rows are included. If the current filter shows no results, OnCoor tells you there's nothing to export rather than saving an empty file.
EXPORT FOLLOWS YOUR FILTER — Export gives you the rows on screen, not the entire catalogue. Clear your search first if you want everything.
5. The Life of a Function
Every function moves through a small set of stages. Knowing where a function sits tells you what you can do with it.
| Stage | What it means | Can you edit it? |
|---|---|---|
| Draft | Being built in the wizard; not created yet. | Yes — it's yours to shape. |
| Open / Editing | Created and live in the editor, but not yet submitted. | Yes — add statements, mappings, parameters. |
| Submitted | Sent for approval; waiting on a reviewer. | No — it's locked while under review. |
| Approved | A reviewer approved it. | No — approved logic is fixed. |
| Active | In force and used by the pipeline. | No — make changes on a new version. |
| Rejected | A reviewer sent it back. | Yes — fix it and resubmit. |
The normal path is Draft → Open → Submitted → Approved → Active. A rejected function drops back to an editable state so you can address the feedback and submit again. Once a function is Approved or Active, you don't edit it in place — you create a new version (see section 10).
WHY EDITING LOCKS — Once you submit a function, reviewers and the pipeline need to trust that what they're looking at won't shift underneath them. That's why Submitted, Approved, and Active versions are read-only. The path forward is always a new version.
6. Creating a Function — the Add Function Wizard
Choose Create Function from the rail to start. The wizard has four steps, shown across the top and in the rail. You move forward with the Next button; a running Rule: chip in the header reminds you which function you're building once step 1 is saved.
Step 1 · Rule
This captures the basics.
| Field | What to enter |
|---|---|
| Rule Name | A short, unique name for the function (up to 30 characters). A live counter shows how much room is left. |
| Description | An optional note on what the function is for (up to 255 characters). |
| Effective Date | The date the function starts to apply. |
| Expiry Date | The date it stops applying. Leave the wide default range if you want it to always apply. |
| Domain Layer | The pipeline stage the function belongs to (for example, Conversion). Most functions use the default. |
When you click Next: Function Mappings, OnCoor saves a draft of the function. From that point you can move freely between the steps, and the rail unlocks the later steps.
EFFECTIVE CAN'T BE AFTER EXPIRY — If the Effective Date is later than the Expiry Date, the wizard asks you to fix it before saving. The default range (a very early start and a very late end) simply means "always applies".
WHAT'S NOT ASKED — You won't see a "type" or "scope" choice. Functions are created as standard, globally-available logic; those settings are handled for you.
Step 2 · Function Mappings
Here you say what the function feeds. A mapping links a Business Attribute to the concrete function name the pipeline will call for it.
Click Add your first Function (or Add additional Function) and pick the Business Attribute. OnCoor shows the attribute's column name and data type so you can confirm you've chosen the right one, and proposes the function name to use.
Most functions have a single mapping. If your setup allows it, one function can feed several business attributes — each becomes its own mapping row, and later gets its own value column in the Statements table.
WHAT IS A FUNCTION MAPPING? — It wires a business field (say, Material Group) to the specific function the pipeline runs to fill it in. One reusable function can produce values for more than one business attribute when your administrator has enabled that.
Step 3 · Parameters
Parameters are the named inputs your conditions and values can refer to. Add a parameter for each piece of incoming data the logic needs to look at, giving it a name and a data type. You'll use these names when you build statements later.
Parameters are optional depending on your logic — simple functions may need none, while others lean on several.
Step 4 · Review & Create
The last step shows a read-only summary of everything you entered. When it looks right, confirm to create the function. This turns your draft into a live, editable function and drops you onto its Detail Page, where you'll build the actual logic.
DISCARDING A DRAFT — If you change your mind mid-wizard, use Discard. Before step 1 is saved there's nothing to clean up. After that, OnCoor asks you to confirm, then removes the draft and everything attached to it so half-finished functions don't clutter the list.
7. Managing a Function — the Detail Page
Opening a created function brings up its Detail Page. The top of the page shows the function's name, its version number, and a status chip, along with the actions available right now — New Version, Submit for Approval, or (for reviewers) Approve and Deny. A progress strip traces the stage the function is in: Draft → Open/Editing → Submitted → Approved → Active.
Below that is a row of tabs. Each is a different view of the same function.
| Tab | What it's for |
|---|---|
| Statements | The heart of the function — the decision table of conditions and the values they return. See section 8. |
| Function Mappings | The business attributes this function feeds, same as wizard step 2. Add, edit, or remove mappings here. |
| Parameters | The function's inputs, same as wizard step 3. |
| Versions | The timeline of every version of this function. |
| Diff | What changed between this version and the one before it. Appears from the second version onward. See section 11. |
| Approvals | The approval history and, for reviewers, the approve/deny actions. |
Small number badges on the tabs tell you at a glance how many mappings, parameters, statements, or versions there are.
LOCKED TABS — If a function is Submitted, Approved, or Active, the editing controls on these tabs are hidden and a soft banner explains why, pointing you to New Version as the way to make changes.
8. Building Statements
The Statements tab is where you lay out the logic. It's a table you fill in top to bottom.
- Each row is a condition.
- Each column on the right is one of the function's mappings — the value to return for that business attribute when the row's condition is true.
- The tinted Return Value row at the bottom is the catch-all, applied when nothing above it matched.
To add a row, use Add statement (when the table is empty) or the Insert below action on an existing row to place a new one exactly where you want it. Rows are read in order, so placement matters.
To fill in a condition, click the Statement cell. A visual builder opens where you assemble the test — comparing parameters, values, and functions — without typing SQL. What you build shows back in the cell in a readable form.
To fill in a return value, click the cell under the relevant column. The same kind of builder opens. Simple cases (a fixed value like 10, or a parameter) are quick; the builder also handles richer expressions when you need them. Do the same on the Return Value row to set what the function returns when no condition matches.
To remove a row, use its Delete action. The Return Value row can't be deleted or moved — every function keeps its catch-all.
READ TOP TO BOTTOM — OnCoor uses the first row whose condition matches, then stops. Order your rows from most specific to most general, and let the Return Value row handle everything else.
9. Submitting for Approval
When the logic is ready, use Submit for Approval in the header. This sends the function to its reviewer and locks it for editing while under review.
Before it will let you submit, OnCoor checks that the function is actually complete:
- it has at least one Function Mapping, and
- it has at least one statement with a condition filled in (the Return Value row alone isn't enough).
If either is missing, the Submit button stays disabled and its tooltip tells you exactly what to add. Once submitted, the function's status becomes Submitted and it waits for a decision.
Reviewers open the function and use Approve or Deny in the header (also available on the Approvals tab). Approving moves the function forward toward Active; denying sends it back to an editable state so the author can revise and resubmit.
ONLY THE RIGHT PEOPLE SEE APPROVE / DENY — Those buttons appear only for users on the function's approver list, and only while it's in the Submitted stage. Everyone else sees the read-only view.
10. Making Changes Later — Versions
Approved and Active functions are intentionally frozen. When the logic needs to change, use New Version in the header.
A new version starts as a fresh Draft and copies the current version's statements, mappings, and parameters so you're editing a copy, not starting over. You adjust what you need, then submit the new version for approval just like the first time. The Versions tab keeps the full history, and each version carries its own effective dates, so you always know which logic applied when.
This is how a function evolves safely: the version that's live keeps running untouched until a new version is approved to take its place.
11. Comparing Versions — the Diff Tab
From the second version onward, a Diff tab appears. It shows what changed between the version you're viewing and the one before it — added, removed, or altered statements, mappings, and parameters.
It's especially useful for reviewers: before clicking Approve or Deny, open Diff to see exactly what's different from the last approved version, rather than re-reading the whole function. (The first version has nothing to compare against, so the tab is hidden there.)
12. A Note on Value Mappings
You may come across functions labelled Value Mapping · read-only on the Detail Page. These are a special kind of mapping that lives in the Value Mapping module — this screen only lets you view them. To change a value mapping, use the Value Mapping module instead; the editing, versioning, and approval actions are deliberately turned off for them here.
13. Quick Reference
A fast lookup for the most common actions.
| I want to… | Do this |
|---|---|
| See all existing functions | Browse → List of Functions |
| Find a specific function | Use the search box on the List of Functions |
| Start a new function | Create → Create Function, then follow the four wizard steps |
| Say what a function feeds | Add a Function Mapping (wizard step 2, or the Function Mappings tab) |
| Add an input the logic can use | Add a Parameter (wizard step 3, or the Parameters tab) |
| Build the logic | Open the Statements tab and fill in rows top to bottom |
| Set the fallback value | Fill in the Return Value (else) row at the bottom of Statements |
| Send it for sign-off | Submit for Approval (needs one mapping and one condition) |
| Approve or reject one (reviewers) | Open the function → Approve / Deny, or use the Approvals tab |
| Change an approved function | New Version, then edit the copy and resubmit |
| See what changed | Open the Diff tab (available from version 2 on) |
| Throw away an unfinished draft | Discard in the wizard |
| Save the list to a file | Export → choose Excel, CSV, or JSON (exports your current filtered view) |
Source: OnCoor Reusable Functions product documentation, written for end users. For the latest screens and options, always refer to the in-app interface.