Business logic and workflows

Why logic needs a human

A scanner can tell you a field is reflected without encoding. It cannot tell you that a discount should apply once, that a refund should never exceed the payment, or that an invoice must be approved before it is sent. Those rules live in your product’s design, and they are where some of the most expensive real-world issues come from.

Start with the rules

On the scoping call we ask your team to walk through the workflows that matter commercially: sign-up and trials, plan changes, checkout, approvals, refunds, invitations and anything that moves money or grants access. For each, we write down the rules in plain language. Those rules become test cases.

How we test

For workflow order, we try to reach later steps without completing earlier ones, repeat completed steps and change a request after it has been approved. For limits, we check that the server enforces seats, quotas and plan features on every route, including the API and bulk imports, rather than only in the interface. For value, we check that prices, discounts and credits are calculated on the server and cannot be influenced by the client.

Concurrency gets particular attention. Single-use actions such as coupons, invitations and transfers are exercised with closely timed requests to see whether the rule holds when two requests arrive together. This is done within the rate ceilings agreed in the rules of engagement and against non-production systems wherever possible.

Finally, we look at indirect routes. An import, an integration or a scheduled job may perform an action that the importing user could not perform directly. Those paths are easy to forget and are tested against the same rules.

A synthetic illustration

A fictional subscription product at app.example.com limits each plan to five seats. The interface hides the invite button at five, but a bulk CSV import adds users without checking the limit. The finding records the plan, the import, the seat count before and after, and recommends enforcing the limit in the membership service that both paths call.

What evidence looks like

Logic findings are described as a broken rule: the rule as your team stated it, the sequence that broke it, and the observed result. Evidence uses synthetic accounts and values. Severity reflects commercial impact as well as security impact, and the rationale says which.

Fixes

Good fixes put each rule in one place on the server, make state transitions explicit, and use database constraints or locks for single-use and balance updates. We note where a single change would close several related findings.