Rule Pilot
User Guide — Building, Validating, and Scoring Data-Quality Rules for an Enterprise Object
| Last updated: August 2026
Contents
- Overview
- Key Concept: Rules, Statuses, and Scores
- Finding Your Way Around
- The Rules Workspace
- Adding a Rule: Simple or Complex
- Simple Rules — Column Quality Checks
- Complex Rules — The SQL Editor
- Duplicate Detection (Dup Check)
- Validating and Activating a Rule
- Scores and Findings
- Managing the Rule Lifecycle
- Quick Reference
1. Overview
Rule Pilot is where you build and manage the data-quality rules for a single Enterprise Object. A rule is a check that OnCoor runs against your data to find records that don't meet a standard — a missing value, a duplicate, a value outside an allowed range, or anything you can describe with a condition. Rule Pilot lets you write those checks, try them out against real data, see how clean the data is, and switch them on.
Rules are organised per Enterprise Object and per layer. The page you're looking at always belongs to one object in one layer (for example, the Cleansing layer), shown in the title as Cleansing Rule Pilot: [Object Name] with a Source badge naming the layer. If your object flows through several layers, each layer has its own Rule Pilot with its own set of rules.
There are two kinds of rule you can create, and one you switch on rather than write:
- Simple rules — click-to-configure checks on a single column, such as "this column must not be empty." No typing required.
- Complex rules — your own condition written as a piece of SQL, for checks that span several columns or tables, or that need custom logic.
- Duplicate detection — a built-in check you turn on per table to flag duplicate records; OnCoor writes the rule for you.
What you can do here
- Create rules for any column or table in the object — simple point-and-click checks or full custom conditions.
- Turn on duplicate detection for a table without writing anything.
- Validate a rule by running it against your real data and seeing exactly which records fail.
- See a quality score for each rule, so you know how clean the data is at a glance.
- Manage the rule's life — keep it as a draft, activate it, retire it, or send it back for another round.
- Filter, search, and export your rules to keep large rule sets manageable.
WHERE TO FIND IT — Rule Pilot is a tab on the Enterprise Object. Open the object, choose the layer you want to work in, and select the Rule Pilot tab. It sits alongside the object's other tabs such as Cognitive DeDup, Data Gen, Validation, and Data Approval.
2. Key Concept: Rules, Statuses, and Scores
Three ideas run through everything in Rule Pilot. Getting these straight first makes the rest of the page easy to follow.
A rule has a type. Every rule is either Simple (a check on one column, configured by clicking) or Complex (a condition you write yourself as SQL). The type is shown as a badge on every rule and is the first way you can filter the list.
A rule has a status. A rule moves through a short life. It starts as a Draft, becomes Active once you've validated it, and can later be made Inactive when it's no longer needed. Only these three statuses are part of the everyday Rule Pilot workflow.
| Status | What it means |
|---|---|
| Draft | Newly created and not yet in force. You can edit it freely, and you validate it to promote it to Active. Every new rule — including duplicate detection — starts here. |
| Active | Validated and live. The rule is part of the object's quality checks. From here you can retire it (Inactivate) or send it back to Draft (Revalidate). |
| Inactive | Retired. The rule is kept on file, with its history, but is no longer applied. You can bring it back to Draft later. |
A rule has a score. When a rule is validated, OnCoor runs it against your data and works out a score — the percentage of rows that pass the check. A score of 100% means every row is clean; a lower score means some rows fail. Scores are colour-coded so you can read them at a glance.
| Score | Colour | Meaning |
|---|---|---|
| 99% and above | Green | Effectively clean — all or nearly all rows pass. |
| 95% to just under 99% | Amber | Mostly clean, with a small number of failing rows. |
| Below 95% | Red | Defects found — the data needs attention. |
DRAFTS DON'T SHOW A SCORE — A rule only has a meaningful score once it has been run against real data. While a rule is still a Draft, the Score column reads "Not run" even if you preview it — the score becomes part of the record when you validate the rule.
3. Finding Your Way Around
Open the Enterprise Object, pick the layer, and select the Rule Pilot tab. The page is laid out top to bottom:
- The title bar names the object and shows the Source badge for the layer you're in, plus a count of how many rules exist.
- The filter bar — type and status chips, a search box, and the Filter, Export, and Add Rule buttons.
- The Dup Check bar — a row of table toggles for turning duplicate detection on and off.
- The rules table — one row per rule, with per-row actions on the left.
- The rule detail panel — a slide-out panel on the right that opens when you view a rule's details.
The rest of this guide follows that layout: first the workspace and how to find rules, then how to create each kind of rule, then how to validate and manage them.
4. The Rules Workspace
The table lists every rule for the object, one row per rule. Above it, the filter bar helps you narrow a long list down to what you're looking for.
4.1 The columns
| Column | What it shows |
|---|---|
| Actions | The buttons for what you can do to this rule (see section 11). Which buttons appear depends on the rule's status and whether it's editable. |
| Table | The table the rule belongs to. |
| Column | The column the rule checks (for simple rules). |
| Type | Simple or Complex. |
| Rule Description | A short description of what the rule checks. |
| Dimension | The quality dimension the rule measures, such as Completeness, Validity, or Accuracy. |
| Priority | How important the rule is — High, Medium, or Low. You can change this directly in the table. |
| Status | Draft, Active, or Inactive. |
| Score | The rule's latest quality score, as a coloured bar and percentage. Blank for Drafts. |
| Passed | How many rows passed at the last run. |
| Failed | How many rows failed at the last run. |
| Validated By | Who last validated the rule. |
| Updated | Who last changed the rule, and when. |
Click any sortable column heading to sort by it. Click a rule's View Detail action to open the detail panel on the right, which gathers the rule's information, its steward and validation history, and its findings in one place, with quick buttons to run validation or edit the rule.
4.2 Filtering and searching
The filter bar gives you several ways to trim the list. All of them work together — set as many as you like.
- Type chips — All, Simple, or Complex. Each chip shows a count.
- Status chips — All, Draft, Active, or Inactive, again with counts.
- Search box — type any text to match against the rule's description, name, column, table, dimension, or priority.
- The Filter button — opens an advanced panel with extra filters for Priority, Dimension, and Table. A small badge on the button tells you how many of these advanced filters are active. Use Clear All Filters in that panel to reset everything.
YOUR FILTERS STAY PUT — The filters you set are remembered in the page address, so a reload keeps your view, and you can copy the link to share the exact filtered list with a colleague.
4.3 Exporting
The Export button downloads the rules currently shown in the table as an Excel file, named after the object and today's date. Because it exports what's currently filtered, you can narrow the list first — for example to one table, or only the Active rules — and export just that slice. If the filtered list is empty, OnCoor tells you rather than producing a blank file.
5. Adding a Rule: Simple or Complex
Click Add Rule in the filter bar. A small chooser opens with two cards:
| Choice | Use it when… |
|---|---|
| Simple Rule | You want a standard quality check on a single column — is it filled in, is it one of an allowed set of values, is it in range, is its length right. Configured by clicking; no SQL. |
| Complex Rule | You need custom logic — a condition across several columns, a check against another table, or anything a single-column check can't express. Written as SQL. |
Whichever you pick, the new rule is created as a Draft. Nothing is live until you validate it, so you can create and refine rules safely.
CHECK YOUR PERMISSIONS — The Add Rule button is only available if your role allows creating rules. If it's greyed out, hover over it for the reason. The same applies to editing, deleting, and toggling duplicate detection — actions you're not permitted to take are disabled with an explanation.
6. Simple Rules — Column Quality Checks
A simple rule is the fastest way to add quality checks. You pick a table and a column, then switch on one or more ready-made quality check types for that column. Each check you switch on becomes its own Draft rule.
6.1 What a quality check type is
Quality check types are the catalogue of standard checks OnCoor offers — "must not be empty," "must be one of these values," "must fall in a range," and so on. The list you see is tailored to the column you chose, because not every check makes sense for every kind of data (for example, "Non Negative" only appears for number columns). These check types are defined once for your environment; an administrator manages them in the Data Quality module's Check Type area, so your list may differ slightly from the standard set below.
6.2 The quality checks you can switch on
OnCoor ships with a standard set of check types. Each one, when enabled on a column, becomes its own Draft rule with the default dimension shown here (you can change the dimension per check).
| Check | What it verifies | Default dimension | What you configure |
|---|---|---|---|
| Not Null | The column is always filled in — it flags empty or blank values. | Completeness | Nothing — just enable it. |
| Set Of Value | Every value is one of a specific list of allowed values you provide. | Validity | The allowed values, typed in. |
| Range Of Value | Each value falls between a lower and an upper bound. | Accuracy | A From value and a To value. |
| Member Of a Specific Set | Each value exists in a chosen reference table — i.e. it's a valid, recognised code (referential integrity). | Validity | The reference table to check against, from a dropdown. |
| Non Negative | Numeric values are zero or greater — it flags negative numbers. Only offered for number columns. | Completeness | Nothing — just enable it. |
| Length | The value's length meets a rule — for example exactly, at most, or at least a set number of characters. | Completeness | An operator (=, ≤, ≥, …) and a number. |
| Comparison | This column compared against another column using an operator — for example Start Date ≤ End Date. Can be added more than once. | Completeness | An operator and the other column to compare against. |
DUPLICATE CHECK LIVES IN THE DUP CHECK BAR — There's an eighth standard check type, Duplicate Check (which flags repeated values, dimension Accuracy). In Rule Pilot you don't switch it on from this list — you turn it on per table from the Dup Check bar instead (see section 8). That's why it doesn't appear among the per-column checks here.
THE LIST DEPENDS ON THE COLUMN — Only the checks that make sense for the column's data type are shown. A number column offers Non Negative; a text column doesn't. If a check you expected is missing, it's usually because it doesn't apply to that column's type.
6.3 Creating a simple rule
- Click Add Rule → Simple Rule.
- Choose the Table and Column you want to check. (If you opened the dialog from an existing rule's Edit action, it's already scoped to that column.)
- Set a default Dimension if you want one — it's applied to each check you switch on, and you can override it per check.
- Switch on the checks you want. For each check type in the list (see the table above), click Enable. Some checks — such as Not Null and Non Negative — need no further settings and show "Will create on Save" as soon as they're enabled. Others open a small set of inputs (for example Range Of Value's From/To, or Length's operator and number); fill those in.
- Each enabled check can carry its own dimension. Adjust it if the check measures something different from your default.
- Save. Use Apply to save your changes and keep the dialog open, or Save and Close to save and return to the table. Each enabled check is saved as its own Draft rule.
You can also validate a check straight from inside the dialog using its Validate action, which hands the new rule to the standard validation workflow described in section 9.
ONE CHECK, ONE RULE — Each quality check you switch on for a column is saved as a separate rule with its own status and score. This is deliberate: it lets you validate, activate, or retire each check independently rather than treating a whole column as pass-or-fail.
7. Complex Rules — The SQL Editor
A complex rule is a condition you write yourself. It's the tool for checks a single-column check can't express — comparing two columns, checking a value against a reference table, or applying custom logic. You describe the rule as a SQL WHERE condition that identifies the failing rows, and OnCoor scores the rule by how many rows match it.
The Complex Rule editor is a full workspace. This section walks through every part of it.
7.1 The layout
The editor is divided into three areas:
- The details bar across the top — the rule's Table, Column, Name, Description, Priority, Dimension, and read-only Status, plus a note reminding you of the rule's scope.
- The schema panel on the left — the tables and columns you're allowed to reference, ready to click into your SQL.
- The SQL editor on the right — where you write and check the condition. It stacks a Round-trip tools bar, a Snippets and Domain functions bar, a Saved CTEs panel, the editor itself, and a live feedback bar underneath.
7.2 The details bar
Before you write the condition, set the rule's basics:
| Field | What it's for |
|---|---|
| Table | The primary table the rule runs against. Pick it from the searchable list. |
| Output Column | The column the rule is associated with. |
| Rule Name | A short, unique name — for example "Active FERT Materials." Names must be unique on the object because other rules can refer to them (see below). |
| Description | A brief, plain-language description of what the rule checks. |
| Priority | High, Medium, or Low. |
| Dimension | The quality dimension the rule measures. |
| Status | Shown for reference only; it's set by the workflow, not typed here. |
7.3 The schema panel — what you can reference
A complex rule may only reference the tables and columns that are in scope for this Enterprise Object. The schema panel lists them for you, split into two groups:
- Primary tables — the object's own tables.
- Direct references — related reference tables you're allowed to reach, each with the link (the foreign-key predicate) already understood.
Use the Search tables & columns box to find what you need, then click a column to insert it into your SQL at the cursor. Inserting from the panel is the safe way to reference data — it always uses a name that's in scope.
WHY SCOPE MATTERS — Rule Pilot deliberately limits a complex rule to the object's own tables and its approved references. This keeps rules portable and safe: a rule can't quietly depend on data outside the object. References to anything else are blocked, as explained under the live checks below.
7.4 Writing the condition
Write a WHERE condition that describes the rows that FAIL the rule. For example, to require that a status column is always filled in, the failing rows are the empty ones, so the condition is the column IS NULL.
The SQL editor gives you several aids:
-
The snippet bar — one-click inserts for common SQL fragments, so you don't have to remember exact syntax:
Snippet Inserts IS NULL / IS NOT NULL An empty / not-empty check. BETWEEN A range check ( BETWEEN 'start' AND 'end').LIKE '%' A pattern match ( LIKE '%pattern%').IN (...) A list check ( IN ('val1', 'val2')).NOT IN (sub) A "not present in another table" check, as a subquery. EXISTS (...) An "exists in another table" check. ROW_NUMBER() A numbering expression, useful for finding repeats. AND / OR / ( ) Joining and grouping conditions. -
Format and Clear — tidy the SQL's layout, or empty the editor to start over.
-
Referencing another rule — you can reference an existing rule on the same object by name using the form
@{Rule Name}. This lets one rule build on another. The name must match an existing rule on the object exactly, and the live checks confirm it with a tick or flag it if it can't be found.
7.5 Domain functions
Next to the snippets is a Domain functions (𝑓) dropdown. Domain functions are ready-made pieces of logic — defined once for your environment and shared across rules — that save you from re-writing the same calculation or check every time. They appear in your SQL as dq.functionName(...).
Open the dropdown to browse them. They're grouped by category and there's a search box to find one by name, description, or category. Click a function to insert it into your condition at the cursor, then fill in its inputs. Using a domain function means every rule that needs that logic behaves identically, and if the logic is ever corrected centrally, every rule picks up the change.
NO FUNCTIONS IN THE LIST? — If the dropdown is empty, none have been set up yet for your environment. An administrator adds them under Management → Config → Domain Functions; once added, they appear here for everyone building rules.
7.6 Saved CTEs — reusable SQL building blocks
Above the editor sits the Saved CTEs panel — your own library of reusable SQL fragments, saved per table so you can reuse them across rules without rewriting them. ("CTE" is a common SQL term for a named building-block query; here it simply means a saved snippet you've named.)
| Action | How |
|---|---|
| Save a fragment | Write a piece of SQL in the editor, then click Save as CTE. Give it a Name (for example, "Active FERT Materials") and an optional Description, and save. |
| Insert a saved fragment | Click ↙ Insert on its chip in the Saved CTEs panel to drop it into the editor at the cursor — or simply type @ in the editor and pick it from the autocomplete list. |
| Edit or remove | Use the pencil (✏️) to rename or update a saved fragment, or the cross (✕) to delete it. |
Saved CTEs are ideal for a condition you find yourself writing again and again — for example a "currently active" filter or a standard join to a reference table. Save it once, then reuse it in every rule that needs it.
7.7 Round-trip tools
The Round-trip bar at the top of the editor helps you move a condition between Rule Pilot and your own SQL tool (such as DataGrip) so you can test it against the database before committing.
| Tool | What it does |
|---|---|
| 📋 Copy as testable | Copies your condition wrapped as a ready-to-run query (SELECT TOP 100 * FROM [table] WHERE …). Paste it into your SQL tool to eyeball the actual rows your condition selects. |
| 📊 Copy as defect counter | Copies a counting query that mirrors exactly how OnCoor scores the rule — it returns the number of defective rows and the total rows. Use it to confirm the score you'll get before you validate. |
| 📥 Paste from SQL | The return trip. Paste a full SELECT … FROM … WHERE … statement and Rule Pilot extracts just the WHERE part into the editor — so you can perfect a query in your own tool, then bring only the condition back. |
| 📋 History | Shown when editing an existing rule. Opens the rule's version history so you can compare any two versions side by side and see exactly what changed. |
TEST OUTSIDE, KEEP INSIDE — The round-trip tools are the recommended way to sanity-check a tricky condition: copy it out, run it in a database tool where you can see real rows, then paste the finished predicate back. The rule itself stays inside Rule Pilot, in scope and under version history.
7.8 The Expression Builder
If you'd rather not write SQL by hand, click Insert via builder to open the Expression Builder, a visual condition builder that slides in from the right. It generates a SQL fragment and inserts it at your cursor — it's a productivity aid, not a separate kind of rule.
In the builder, each condition row has a left-hand side you choose from:
- Field — a searchable picker for any column in the reachable tables.
- Function — a picker of functions, grouped by category (String, Date/Time, Math, Conversion, Logical), each with argument slots you fill with either a field or a value.
You then choose an operator suited to the column's type (text, number, date, or true/false) and a comparison value. Conditions can be joined with AND / OR and nested into groups to any depth. When you're happy, the builder writes the equivalent SQL into the editor for you.
7.9 Live checks (the lint bar)
As you type, a feedback bar under the editor checks your SQL against the same rules the server enforces, so you catch problems while editing rather than at save time. It flags:
| Message type | What it's telling you |
|---|---|
| Out-of-scope table | You've referenced a table that isn't in this object's reachable set. Only the object's own tables and approved references are allowed. |
| Cross-database reference | You've used a three-part name (like database.schema.table). References across databases or servers aren't allowed. |
| Banned keyword | You've used a command that changes data or structure (INSERT, UPDATE, DELETE, DROP, and so on). A rule may only read and check data, never modify it. |
| Dangling or doubled AND/OR | A condition is empty or incomplete — for example an AND with nothing after it. |
| Unknown rule reference | An @{Rule Name} reference doesn't match any rule on this object. Check the name exactly. A matching reference is confirmed with a tick. |
The bar also shows a running count of Lines and Chars, and a Validate SQL button to check the whole condition on demand.
7.10 Saving
The footer offers Cancel, Apply (save and keep editing), and Save and Close. As with simple rules, a saved complex rule is a Draft until you validate it.
THINK IN TERMS OF FAILURES — A complex rule's condition selects the rows you consider wrong. If the condition matches no rows, the rule scores 100%. If it matches some, those are your defective rows and the score drops accordingly. When in doubt, write the condition that describes a bad record.
8. Duplicate Detection (Dup Check)
Duplicate detection is a ready-made check you switch on per table — you don't write anything. The Dup Check bar sits just above the rules table and shows one toggle for each table in the object.
To turn it on or off, click a table's pill in the Dup Check bar. A tick and highlight mean duplicate detection is on for that table; clicking again turns it off. The bar's header shows a running summary, such as "2 of 5 tables enabled," and you can collapse the bar when you don't need it.
When you switch duplicate detection on, OnCoor creates the duplicate-check rule for you as a Draft — it appears in the rules table like any other rule and follows the same validate-and-activate path. The matching logic and keys are managed internally, which is why this rule's SQL isn't hand-edited in the Complex editor.
DUP CHECK STARTS AS A DRAFT TOO — Turning on duplicate detection creates a Draft rule; the toggle shows as enabled straight away because a Draft still counts as "on." Validate it like any other rule to promote it to Active. Turning the toggle off retires the rule.
RELATED FEATURE — Dup Check flags duplicates within a table as a quality rule. It is not the same as Cognitive De-Duplication, the AI-powered record-matching feature that has its own tab on the Enterprise Object. Use Dup Check for straightforward duplicate rules; use Cognitive DeDup for fuzzy, AI-assisted matching.
9. Validating and Activating a Rule
Validating is how a rule goes from a Draft you've written to an Active check. It runs the rule against your real data, shows you exactly what it found, and — if you're happy — promotes it to Active. Start it from a Draft rule's Validate action (in the table, the detail panel, or from inside the Simple Rule dialog).
Validation is a short guided workflow with four steps, shown as a stepper across the top:
Step 1 — Review. A summary of the rule: its table, column, type, dimension, and description, with a reminder that it will move from Draft → Active after a successful validation. Check it reads as you intended, then click Run Validation.
Step 2 — Run. OnCoor executes the rule against the data, showing a progress bar while it scans. If the run can't complete — for example the SQL has a problem — you'll see a clear error and a Retry button rather than a silent failure.
Step 3 — Findings. The results. At the top is a large score dial for the rule, coloured green, amber, or red on the same thresholds as the table. Below it, a breakdown tells you how many rows passed and how many are defective, with a per-rule finding that says, in plain numbers, how many of how many rows matched the failure condition. From here you can look at the defective rows themselves to understand the problem.
Step 4 — Activate. If the findings look right, activate the rule. It moves to Active status and becomes part of the object's live quality checks, with its score and validation details recorded.
VALIDATION IS SAFE TO REPEAT — Running validation only reads and checks your data; it never changes it. You can run it as often as you like to see the current state, and re-validate a rule any time its data may have changed.
10. Scores and Findings
The score is the heart of how Rule Pilot reports quality. It's the percentage of scanned rows that pass the rule: if a rule scans 10,000 rows and 50 match its failure condition, 9,950 pass and the score is 99.5%. A rule that finds nothing wrong scores 100%.
Scores appear in several places, always with the same green / amber / red colours (green at 99% and above, amber from 95%, red below 95%):
- In the table, as a coloured bar and percentage in the Score column, alongside the Passed and Failed counts.
- In the detail panel, with the rule's steward and validation history.
- In the Findings step of validation, as the large score dial.
Defective rows. When a rule finds failing rows, you can open them to see the actual records that failed the check — the fastest way to understand why a score is low and what needs fixing in the data.
Redo Scoring. Sometimes you just want an up-to-date score without changing anything about the rule. The Redo Scoring action re-runs the rule against the current data and shows the fresh score and findings without moving the rule through the lifecycle — an Active rule stays Active, an Inactive rule stays Inactive. It's available whatever the rule's status. (A Draft's refreshed score still isn't shown in the table's Score column, by design — see section 2.)
HOW THE SCORE IS WORKED OUT — Across all the rows a rule scans, the score is
(rows that pass ÷ rows scanned) × 100. Rows that couldn't be scanned because the rule errored are left out of the calculation, so an error never quietly inflates or deflates a score.
11. Managing the Rule Lifecycle
Once rules exist, the Actions column and the detail panel let you move them through their life. The actions you'll see on any given rule depend on its status and on whether the rule is editable.
11.1 The actions
| Action | What it does | When it's available |
|---|---|---|
| Edit | Reopen the rule to change its definition. Simple rules reopen in the Simple dialog scoped to the column; complex rules reopen in the SQL editor. | Draft rules that are editable. |
| Validate | Run the four-step validation workflow to promote a Draft to Active. | Draft rules. |
| Redo Scoring | Re-run the rule and view a fresh score without changing its status. | Any status. |
| Inactivate | Retire an Active rule. Its score and history are kept but no longer shown until it's revalidated. | Active rules that are editable. |
| Revalidate | Send an Active or Inactive rule back to Draft so it can be validated again. | Active or Inactive rules that are editable. |
| View Detail | Open the slide-out detail panel. | Any rule. |
| Delete | Remove the rule. | Draft rules that are editable. |
When you inactivate or revalidate a rule, OnCoor asks you to confirm and explains what will happen — for example, that an inactivated rule keeps its score and validation history on file but stops being shown until it's revalidated.
11.2 Editable vs. locked rules
Some rules are system-managed — set up by OnCoor rather than hand-written. These are locked by default: you can view and validate them, but you can't change or delete their definition unless your environment specifically allows system-managed rules to be changed. This is a safety measure so that standard, centrally-defined rules aren't altered by accident. A locked rule shows fewer actions; the ones that don't change its definition (like View Detail and Redo Scoring) remain available.
11.3 Changing priority quickly
You don't need to open a rule to change how important it is. The Priority column in the table is editable directly — pick High, Medium, or Low from the dropdown and the change is saved straight away.
11.4 Data steward
When a rule is validated, the person who validated it is recorded as Validated By, and the detail panel shows this alongside any data steward assigned to the rule. This gives you a clear trail of who stands behind each active check.
12. Quick Reference
A fast lookup for the most common actions.
| I want to… | Do this |
|---|---|
| Open Rule Pilot | Enterprise Object → choose the layer → Rule Pilot tab |
| Add a standard column check | Add Rule → Simple Rule → pick Table & Column → Enable the checks → Save |
| Add a custom check | Add Rule → Complex Rule → write a WHERE condition for the failing rows → Save |
| Reference an approved reference table | In the Complex editor, click a column in the schema panel to insert it in scope |
| Reuse a standard piece of logic | Insert a Domain function (𝑓 dropdown) or a Saved CTE (click Insert, or type @) |
| Save a fragment to reuse later | Write it in the editor, then Save as CTE with a name |
| Test a condition in your own SQL tool | Copy as testable (or defect counter), run it, then Paste from SQL to bring the WHERE back |
| Reference another rule | Type @{Rule Name} using the exact name of a rule on the same object |
| Turn on duplicate detection | Click the table's pill in the Dup Check bar |
| Make a Draft live | Use Validate → step through Review, Run, Findings, Activate |
| See which records fail | Validate (or Redo Scoring) → open the defective rows |
| Refresh a score without changing status | Use Redo Scoring |
| Retire a live rule | Inactivate (it keeps its history) |
| Bring a rule back for another round | Revalidate (moves it to Draft) |
| Change a rule's importance | Pick High / Medium / Low in the Priority column |
| Find rules fast | Use the Type / Status chips, the search box, or the Filter panel |
| Get the list into Excel | Filter to what you want, then Export |
Source: OnCoor Rule Pilot product documentation, written for end users. For the latest screens and options, always refer to the in-app interface.