> ## Documentation Index
> Fetch the complete documentation index at: https://help.owlery.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Tagging Rules
> Automatically apply tags and GL codes to orders, loads, and quotes as they arrive.
If you are an Enterprise customer with individual subsidiary organizations, remember that **shipper settings are organization specific**. Settings must be configured at the individual subsidiary organization level to ensure each subsidiary's operations work as expected.
**Where to find it:** `Dashboard → Settings → Tagging Rules`
A tagging rule is a saved instruction that watches records as they arrive and applies a tag or a GL code whenever one matches. Write the rule once instead of tagging thousands of records by hand.
If every order from a particular supplier should be tagged `Co-Man`, that's one rule.
## The Rules Table
The Tagging Rules page lists every rule you've created, newest first, with the record types it covers, the tag or GL code it applies, its description, and when it was created.
* **Click a row** to open the rule's details, written out in plain language with facilities and trading partners resolved into real names and addresses.
* **Create Tag Rule** opens the create dialog.
* **Select** turns on multi-select so you can delete several rules at once.
* **Delete** removes a rule permanently, after a confirmation.
Rules can't be edited in place. To change one, create the corrected rule and delete the old one.
## What a Rule Can Apply
| Rule type | What it adds | Record types it can apply to |
| ----------- | ------------------------------------------------------------------------ | ---------------------------- |
| **Tag** | A free-text label, such as `Transfer`, `Co-Man`, or `Rush` | Orders, loads, and quotes |
| **GL code** | A single general ledger code, used downstream for invoicing and payments | Orders only |
Rules belong to one organization and can only reference facilities and trading partners that organization can see.
## Create a Rule
Click **Create Tag Rule**. The dialog opens in **Guided conditions** mode, which is what almost everyone should use.
Add one condition row per thing that must be true. Pick a field, an operator, and a value.
**All rows must be true for the rule to fire.** Guided mode always combines conditions with AND — there's no "any of these" option at the row level. To mean "any of these facilities", use one row with the **contains** operator and pick several values.
Pick **Tag** or **GL code**, then type the tag text or GL code the rule should apply.
The description is optional and purely for your team, but it's the only place the rules table can explain what a rule is for. Write one.
Under **To**, tick **Order**, **Load**, or both.
### Fields You Can Match On
| Field | What it means |
| --------------------------------------- | ------------------------------------------------------ |
| **Order Type** | The order's type, such as purchase, transfer, or sales |
| **Trading Partner (Customer) on Order** | The customer-side trading partner on the order |
| **Trading Partner (Supplier) on Order** | The supplier-side trading partner on the order |
| **Pick up Facility** | The first pickup facility |
| **Drop off Facility** | The last dropoff facility |
| **Is Outsourced** | Whether the order is outsourced |
The value picker changes to match the field — a list of order types, a searchable trading partner list, a searchable facility list with addresses, or Yes/No.
### Operators
| Operator | What it means |
| ---------------- | ---------------------------------------------------------------------------------------- |
| **contains** | The record's value is one of the values you picked. Pick several to mean "any of these". |
| **not contains** | The record's value is none of the values you picked. |
| **equals** | The record's value is exactly the value you picked. |
| **not equals** | The record's value is anything other than what you picked. |
| **is set** | The field has a value, any value. No value box appears. |
| **is not set** | The field is empty. No value box appears. |
**contains** and **equals** behave almost the same when you pick a single value. Use *contains* when you want to pick several, *equals* for one exact match.
**not contains** and **not equals** only match records where the field actually has a value. A record with an empty field will not match them. If you want "everything except X, including blanks", add a second rule using **is not set**.
### Ticking Both Order and Load
In guided mode, ticking both **Order** and **Load** creates **two separate rules**, one per record type. Each gets its own row in the table, and they're deleted and rerun independently.
That's deliberate, because the conditions mean slightly different things on each:
* **On an order**: the conditions are checked against the order itself.
* **On a load**: order-level conditions — order type, trading partners, outsourced — are checked against the load's linked orders, and the load matches if at least one of its orders satisfies them. Pickup and dropoff facility are checked against the load's own stops.
## When Rules Run
You don't have to do anything for rules to apply to new work. Rules run automatically when:
* **Orders are created or updated**, including orders that arrive through an ERP integration, the API, inventory monitoring, or document analysis.
* **Loads are created or synced** from an integration.
* **Quotes are created.**
* **An order changes**: Owlery also re-checks load rules for that order's loads, because a load rule can depend on order fields. Editing an order's trading partner can change its loads' tags without anyone touching the loads.
Rules run independently of each other, so one record can match many tag rules and collect all of their tags.
**New rules are not retroactive.** Creating a rule does not go back and tag records you already have — it only affects records created or updated from that point on. To apply a rule to past records, rerun it.
## Apply Rules to Records You Already Have
Three controls on the Tagging Rules page cover this.
| Control | What it does |
| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Rerun Rule** | Open a rule and use this in the drawer header to run that one rule across all existing matching records. |
| **Update All Tags** | Re-checks every tag rule against all orders, loads, and quotes, including closed ones. |
| **Update All GL Codes** | Re-checks every GL code rule. Choose **Orders** to re-check rules against orders, **Loads** to recompute loads' GL codes from their parent orders, or both. Closed records are included. |
Reruns process records in batches and can take a while on a large dataset. The success message appears once the run is finished.
### The Remove Old Tags Checkbox
Both **Update All** dialogs carry a checkbox to clear old values first.
* **Left unticked (the default)**: the rerun only adds. Tags that rules applied previously stay put, even if the rule that created them has since been deleted or rewritten.
* **Ticked**: every automatically applied tag or GL code across your organization is cleared first, then your current rules are applied fresh.
Tick it when you've deleted or rewritten a rule and stale tags need to disappear.
This only clears values that rules applied automatically. Tags someone added by hand are never touched.
## Automatic Tags vs. Tags People Add
Owlery tracks two separate sets on each record: tags a person applied by hand, and tags a rule applied automatically.
**Tags applied by hand take precedence.** If anyone has hand-tagged a record, that record shows its manual tags and the automatically applied ones aren't displayed. The rules still ran — their results just aren't what you see.
If a rule's tag seems to have vanished from one record, a manual tag on that record is the usual reason.
## GL Code Rules
GL code rules work a little differently from tag rules.
* **Orders only.** Choosing GL code locks the target to Order and disables Load and Quote.
* **One GL code per record.** Even if several GL code rules match the same order, only one GL code is kept. Write your GL code rules so they don't overlap rather than relying on an order you can't control.
* **GL codes flow down to the order's loads**, so invoicing and payments can see them.
* GL codes from rules also feed the GL code picker elsewhere in the product, such as when you set up payment statement contacts.
**Editing a GL code by hand locks that record.** Once someone edits a record's GL code manually, automatic GL code rules skip that record from then on — including during a full rerun. This protects deliberate accounting corrections, and it's the most common reason a GL code rule looks broken.
## Where to Go Next
Why a rule isn't applying, and answers to the questions that come up most.
Write a rule as a raw JSON expression when guided mode can't express it.