The customer submits an order. The portal shows a confirmation. The API returns 200 OK, and the release checks pass.

The next morning, operations asks why the order never appeared in the approval queue. Support has a ticket. A developer has to trace the order through the database and figure out whether someone can safely submit it again.

For teams maintaining a ColdFusion or Lucee application, this is a frustrating kind of release failure: the team did run its checks, but those checks didn’t cover the part of the workflow that broke.

In Inherited a CFML Application With Few Tests? Here’s Where to Start!, we used a fictional customer portal to show how to choose your first workflow to protect. This time, we’ll follow one order from the API response to the point where operations can act on it.

Start with what the customer thinks happened

In our example, submitting an order means the portal has accepted it for approval. The order should be saved under the right customer account, an authorized reviewer should be able to find it, and the customer should receive a confirmation. The confirmation is useful, but an email outage should not undo an order that operations can still process.

That last sentence is a business rule for this example. Your team may make a different decision. Agree on it before writing the test, because it determines whether a failure should reject the order, leave it pending, or trigger a retry.

The HTTP specification defines 200 OK as a successful request. If your test only checks the status, it confirms what the endpoint reported. To know whether the application kept its promise, check what happened to the order.

Follow one order past the response

In a test environment, sign in as a customer and submit two units of a test item priced at $25 each. Use a unique submission reference so you can trace this run without confusing it with an older order. For this example, the order total is $50 before any tax or shipping.

Suppose the existing POST /api/orders contract returns 200 OK with this body:

{
  "orderId": "ORD-10482",
  "status": "pending_approval",
  "totalCents": 5000
}

Here’s how to turn that request into a useful regression test:

Where to look	What to verify	What the check could catch
API response	The body contains an order ID, the expected status, and a total of 5000 cents.	The endpoint reports success but returns a status the portal doesn’t recognize or shows the customer the wrong amount.
Saved data	Using the returned ID, look up the order independently. Confirm it belongs to the signed-in customer and has the expected item, quantity, and total. Confirm that the submission produced exactly one order.	The response looks right, but the database contains the wrong customer, incomplete line items, or duplicate records.
Approval queue	Using an authorized reviewer account, check that the same order appears in the queue operations actually uses. If a worker updates the queue, give it a defined window to do so.	The order was saved, but nobody can approve it because a routing rule or background job failed.
Confirmation	Check that a test mailbox receives a confirmation for that order, addressed to the expected recipient. If you only check a notification record, report that the notification was queued.	The application handed off the notification but didn’t deliver it, or used the wrong recipient.

The approval check matters because an order row can exist while the business workflow is stuck. If operations still has to hunt for the order or ask the customer to resubmit it, the release check missed the failure that mattered.

Test what happens when something goes wrong

Once the valid order works, test the cases most likely to create support tickets or manual cleanup. For this portal, start with three:

1. The customer retries after a timeout. Submit an order, then replay the same request with the same submission key to simulate a client that missed the first response. If the agreed rule is that a retry refers to the same order, verify there is still one order and one approval entry. Check that the retry doesn’t generate a second confirmation.
2. The customer tries to submit for another account. Sign in as customer A and submit a request containing customer B’s account ID. Verify the request is rejected and creates no order, approval entry, or notification for customer B. The error response alone won’t tell you if the application wrote data before rejecting the request.
3. The confirmation email fails. Simulate a mail failure in the test environment. In this example, the order must still be saved and available for approval, and the notification failure must be recorded against that order so support can find it. If notifications are retried, verify that retrying the email doesn’t create a new order.

Give each test a failure message that tells the team where to look. “Order ORD-10482 was saved but never appeared in the approval queue” is more useful in a release review than “Order test failed.”

Put the checks where your CFML team can maintain them

If the API runs in ColdBox, use ColdBox integration testing to exercise the route through the application. Connect the test to a dedicated datasource and verify the saved order from a separate lookup. If the endpoint is an older remote CFC or a .cfm handler, call it over HTTP in a controlled environment and apply the same checks. You can start protecting the workflow before changing its architecture.

Keep one test that exercises the actual approval handoff. A simulated mail failure is useful for checking how your code responds, but it won’t tell you whether the deployed mail configuration works. Likewise, a test that replaces the approval worker with a stub won’t catch a worker that never runs after an upgrade.

Before a ColdFusion update, Lucee migration, or API refactor, run the same workflow checks on the current and target environments using equivalent test data. Use the agreed business behavior as the benchmark. If an order was already disappearing from the queue on the current environment, don’t turn that defect into an expected result.

What to change before your next release

Pick one endpoint your team already checks. Ask operations or support what they would look for if a customer said, “The portal told me it worked, but nothing happened.”

Add that evidence to the test. For our sample portal, that means proving the order is saved under the right account and visible to the person who approves it. Agree that either failure blocks the release. A notification failure can have a different release rule if operations can still process orders and the team can recover the notification.

That’s what makes a regression check useful when it’s time to ship: it tells your team which work customers and operations can still complete, and what to investigate if they can’t.

Do your API checks pass while the same workflow keeps breaking? Bring Ortus one recurring issue or a workflow you’re worried about before an upgrade. Our QA team can help you trace where the checks stop and prioritize coverage for the next release.

Request a free 30-minute QA consultation

---

Join Our Developer Community

Connect with developers, ask questions, share what you're building, and engage directly with the Ortus team.

• Join the BoxTeam Community on Slack
• Join the Ortus Community Forum

Follow Ortus Solutions

Keep up with releases, technical content, events, and everything happening across the ecosystem:

• X (Twitter)
• Facebook
• LinkedIn
• YouTube
• GitHub

You can also explore the latest articles anytime on the Ortus Solutions Blog.