Before you start
- The current workflow and the exact result that needs to change.
- A decision-maker for the rule and an operator who can validate it.
- Representative examples, including exceptions. This is the service procedure; no universal in-product change-request button is assumed.
Specify the change in operational terms
State current and desired behavior
For example: “Account group A needs a minimum order quantity of 12 for product X; other accounts retain the existing minimum.” Name the applicable account/product/channel context.
Provide examples
Supply a should-pass case, should-fail case and unaffected case. Include quantities, dates and amounts so the result is objectively checkable. Use approved sample records rather than vague statements such as make checkout smarter.
Identify the affected layers
Decide whether the rule belongs in data configuration, pricing logic, workflow, permission, integration or presentation. Buffaly-assisted implementation still needs one authoritative rule, not contradictory copies in UI and service.
Approve the scope
Agree who approves the behavior, who implements it and which historical records or ongoing subscriptions should remain unchanged. A request to change future pricing is not automatically a request to rebill existing customers.
Deliver and verify the change
Implement against the agreed examples
The service team makes the scoped change and records the affected contract/configuration. Preserve explicit validation and visible failure behavior.
Test the actual workflow
Run the positive, negative and unaffected cases in the appropriate test environment. Verify the saved record, totals and downstream integration outcome, not only a successful build.
Review and release
The business owner reviews the evidence. Record the release version, operating responsibility and recovery plan, then deploy through the installation’s approved process.
Update this manual
Change the affected task steps, fields, examples and source references. Re-test navigation/search so an operator can find the new procedure. Documentation updates are part of the change, not a separate marketing exercise.
Fields & records
| Field / record | Meaning or use |
|---|---|
| Rule statement | Who/what it applies to, condition, outcome and exceptions. |
| Acceptance example | Concrete inputs and expected output or rejection. |
| Release record | Version, approval, evidence and operating owner. |
Verify the result
- The requested and unaffected examples both behave as agreed.
- Operator documentation matches the released controls and result.
- The team can trace the rule to its authoritative implementation and release.
Troubleshooting
| What you see | What to check or do |
|---|---|
| Request cannot be tested | Add concrete examples and expected outcomes before implementation. |
| UI accepts a value the service rejects | Fix the authoritative contract/flow; do not hide the rejection with client-only behavior. |
| Existing customers changed unintentionally | Define historical/ongoing-record scope explicitly and test it. |
Version & scope
Service implementation procedure, grounded in the current software contracts. Source verification is not a claim that a live payment, message, customer transaction or full operator run occurred.
Public guides describe shared controls, records and configuration boundaries using fictional data. Tenant URLs, credentials, customer records, provider identifiers and installation-only procedures belong in customer-controlled documentation and are excluded from public pages and search.
- Version
- 2.0.0
- Change source
- Current Feeding Frenzy forms/services plus reconciled Wiki topics
- Feedback key
guide:changing-a-rule
Feedback records only the page, guide ID and yes/no choice. It never records documentation search text.
Implementation references (2)
FeedingFrenzy.Commerce/Baskets/Quotes.csFeedingFrenzy.Admin/wwwroot/kScripts/Products/Product.Edit.ks.html