Business Rules
A new business rule in your ERP.net instance — described in plain language, designed, and created for you.
ERP.net comes with a business rules engine: you can configure rules that keep data correct and work happens by itself — a field becomes required when another one is filled, a value is calculated and entered on save, a document state changes when conditions are met. Setting one up normally means knowing where in the instance the rules live and how they are written. In Operator you describe the rule in your own words, and Operator designs it, creates it, and shows it working.
What you get
- A business rule created directly in your ERP.net instance, on the entity you choose.
- The rule's conditions and actions written against your instance's real model — including your stored attributes and custom fields.
- A short explanation of what the rule does, so you can check it, adjust it later, or reuse the pattern.
Example
You say: "when a sales order line has a quantity but no product group, warn the user before saving." Operator inspects
Crm.Sales.SalesOrderLines, finds the matching fields in your instance, proposes the rule, and — after your approval — creates it in the instance. You try it on a real order and it works.
How to ask for one
Describe what should happen and when, in your own words:
when a customer's credit limit is exceeded, prevent confirming the order
set the payment account automatically for cash sales, based on the store
require a delivery date on sales orders for this customer group
when an invoice line's discount is above 20%, ask the user to confirm
Useful things to mention:
- Which entity — sales orders, invoice lines, customers, products — and whether the rule watches the header or the lines.
- The condition — what situation should trigger it ("quantity is filled", "customer group is VIP").
- The action — warn the user, prevent saving, fill in a value, change a field, change the document state.
- Who it applies to — everyone, or a specific user group; the rule lives in the instance, so its access settings matter.
Operator inspects the entity first — pulling in your instance's custom fields and any Entity Instructions you have written — then proposes the rule before creating anything. You can correct it in plain language ("check the net amount, not the total") and it adjusts.
What to check before approving
- The trigger and the action are the ones you mean. Operator shows you the rule before creating it; read the condition once, especially which fields and values it compares.
- It behaves on real data. Ask Operator to test the rule on a real record — a save that should warn, an order that should be blocked — before people start working with it.
- Nobody is surprised. A rule that prevents saving affects everyone who works with that entity; if it should only apply to some users, say so while designing.
Changing it later
- Adjust the rule — "check gross amount instead", "apply it only to order lines" — and the rule is updated in the instance.
- Turn it off — "disable the credit limit rule" — and it stops running but keeps its definition; "enable it" brings it back.
- Remove it — "delete the rule" — when it is no longer needed. Removing waits for your confirmation.
Good to know
- Business rules live in your ERP.net instance, not in Operator. Once created, they apply everywhere — forms, imports, the Domain API, other apps.
- Rules can be used for data validation, for filling values automatically, and for reacting to changes — the same request covers all three.
- A rule runs for every user who saves a matching record, including API calls and imports; test with a couple of scenarios before rolling it out.
- If the rule needs a field that does not exist yet, Operator tells you instead of guessing — that is the moment to decide whether you need a stored attribute first (see Calculated Attributes for computed fields that don't need storing).