Which business rules should operations configure, and which require formal change control?

Not every business rule should be hard-coded, and not every rule belongs in an administration screen. Operations can safely own parameters whose meaning is already settled, whose inputs and scope can be constrained, and whose effects can be previewed and reversed. A rule that changes money, entitlements, access, a core state model or an external contract needs formal change control. The design problem is therefore not “configuration versus code.” It is how to govern rules according to impact.

Separate a parameter change from a change in business meaning

Two fields on the same screen may carry very different risk. Moving the earliest booking time from two hours to four hours adjusts a known boundary. Changing inventory from “reserved when booked” to “reserved only after payment” alters the shared meaning of booking, inventory, cancellation and refund states. The first can be a controlled parameter; the second is a product change.

China's official Enterprise Internal Control Application Guidelines call for key control points and processing rules to be embedded in information systems, incompatible duties to be separated through access control, and information-system changes to follow a defined management process. NIST SP 800-128 describes a change lifecycle covering request, recording, impact analysis, testing, approval, implementation and post-implementation verification. It also notes that pre-approved changes are still tested and documented. Neither source decides a company's discount or approval threshold, but both show why flexibility needs authority, evidence and impact control.

When a request exceeds the agreed configuration boundary, return to the project's requirements-change, impact-assessment and pricing process. Calling something configurable does not settle whether it is inside the contracted scope.

Four classes are more useful than “configurable or not”

Class	Examples	Appropriate operator	Minimum controls
A: routine parameters	Display order, reminder lead time, non-critical copy, optional labels	Named operations staff	Input validation, preview, audit record, restore default
B: controlled commercial parameters	Campaign dates, service radius, per-customer limits, bounded discounts	Business owner or dual review	Scope, upper and lower bounds, effective time, approval, version and rollback
C: high-impact business rules	Price calculation, refund eligibility, credit, inventory deduction, entitlements, automatic approval	Product, business, finance or risk owners together	Impact analysis, representative tests, staged release and rollback plan
D: system and contract changes	Role model, order-state structure, interface semantics, retention, identity or payment flow	Formal project change	Requirements and architecture review, development, migration, integration testing and release approval

Classification is not determined by the number of lines of code. Ask who is affected if the change is wrong, whether failure is detectable, whether it is reversible, and whether it changes historical records or an external promise. A single numeric threshold may decide who can refund or buy on credit; technical simplicity does not make it a low-risk setting.

Six conditions for safe operations self-service

A rule is a good candidate for self-service only when all six conditions are satisfied:

1. Its meaning is stable. The value adjusts an agreed parameter rather than redefining an order, case or entitlement.
2. Its scope is explicit. The change can be limited to a store, channel, product, region, customer group or period.
3. Its input is constrained. Type, range, dependencies and conflicts are validated; arbitrary scripts and formulas are not accepted.
4. Its outcome can be previewed. Representative orders or journeys show the difference between the current and proposed rule.
5. It can be reversed. A prior version remains available, with a clear rule for new transactions versus historical records.
6. Responsibility is attributable. The system records operator, time, reason, reviewer, old value, new value and effective scope.

Failure to meet one condition does not mean the rule can never be configurable. It means the first changes should be managed and observed before the organisation turns them into a safe product capability.

Five rule groups need formal change control

Money and customer entitlements

Pricing, tax, commission, refunds, credit, promotion stacking, membership duration and service credits affect settlement or fulfilment. Test boundaries, rounding, concurrency, historical orders, reconciliation and exceptions—not just whether the Save button works.

Access, approvals and separation of duties

Giving operations direct price-change rights, allowing one person to request and approve, or expanding export access changes the control model. Review least privilege, incompatible roles, temporary access and offboarding against actual jobs.

Core states and the interpretation of historical data

Adding an order state, merging service stages, recalculating inventory or reassigning completed records can make reports, integrations and evidence disagree. Decide how old data maps, how work in progress behaves and whether a failed migration can be reversed.

External interfaces and platform commitments

Interface fields, callback order, payment status, message templates and device protocols are not internal parameters controlled by one organisation. Confirm counterpart versions, compatibility periods, retries, idempotency and compensation before switching.

Law, contract or security boundaries

Retention, consent, identity, sensitive fields, encryption and audit scope should not be changed by ordinary operators on intuition. The accountable owner or specialist first confirms the applicable requirement; software then implements the approved decision.

Eight capabilities a configuration console needs

1. Role-specific access: separate view, edit, approve, publish and rollback rights.
2. Scope: make global, entity, store, product, channel and user coverage explicit.
3. Versioning: retain draft, pending, active, retired and rolled-back versions.
4. Effective time: support scheduled activation and expiry with one defined timezone policy.
5. Validation: reject invalid ranges, dates, dependencies, conflicts and dangerous combinations.
6. Preview and simulation: compare representative results without changing production records.
7. Audit and notification: record the full change and inform affected business and support owners.
8. Stop and recovery: provide emergency disablement, a known-good version and a clear rollback effect.

A page containing only a field name, input and Save button transfers direct-database risk from engineers to operations. It does not create an operable rules product.

Scope the first release around one bounded rule

Begin with a frequent, low-consequence rule such as opening hours for store appointments:

1. Gather the values actually used, reasons for change and accountable owner.
2. Define permitted ranges, lead time and conflicts with staff availability.
3. Name the drafter, approver and person allowed to suspend the rule in an incident.
4. Test normal, boundary, conflicting and in-progress appointments.
5. Activate it first for one store or business group.
6. Verify new and existing appointments, reminders and reports agree.
7. Prove restoration of the previous version before expanding access.

The same approach can cover reminder timing, service areas, quantity limits and campaign windows. Avoid arbitrary formulas, scripts and cross-table expressions in the first release. Greater expressive power multiplies test combinations, explanation cost and misuse risk.

Acceptance journeys before launch

• An ordinary operator cannot edit rules outside their scope or bypass publication approval.
• Invalid boundaries, blanks, conflicts, expiry and timezone combinations are rejected clearly.
• Preview and live results agree for representative business cases.
• A defined policy determines whether work in progress uses the old or new rule.
• Integrations, notifications, reports and exports identify the same rule version.
• Each change exposes its reason, review, difference, effective time and rollback history.
• Rollback does not silently rewrite completed or settled transactions.
• An emergency change is still recorded, reviewed and stripped of temporary access afterwards.

Common mistakes

“Self-service removes development work.” Safe configuration needs access control, validation, versions, simulation, audit and recovery. It is a product capability in its own right.

“Once configurable, every request is no longer a scope change.” A request outside the agreed fields, scopes or state model still affects design, testing, delivery and cost, and should be treated as a project change.

“More approvals always mean more safety.” Excessive approval on routine parameters drives people back to chat and direct database edits. Match control strength to impact: pre-authorise Class A, and reserve fuller control for Classes C and D.

“An audit log makes broad access safe.” A log helps reconstruction after an event. It does not replace prevention, separation of duties or rollback.

Six decisions the accountable owner must make

1. Which rules adjust a stable parameter, and which alter business meaning?
2. Who owns, edits, reviews and technically supports each class?
3. What are the scope, effective time and treatment of historical and in-progress work?
4. Which values, combinations and dependencies are allowed?
5. What are the tests, rollout, monitoring, stop and rollback conditions?
6. When should repeated formal changes be promoted into controlled self-service?

A mature custom system neither locks every decision in code nor exposes every switch to operations. It makes routine commercial adjustment fast while preserving judgement, evidence and recovery for consequential change.

Sources

• Ministry of Finance and other authorities: Enterprise Internal Control Application Guidelines, particularly Guideline No. 18 on information systems; accessed 9 October 2026.
• NIST SP 800-128: Guide for Security-Focused Configuration Management of Information Systems, covering configuration change control, testing, approval and post-implementation verification; accessed 9 October 2026.