Provider Order Management UAT Guide · 23 modules · 100 scenarios
000 0 of 100 recorded
Connecting…
PHASE 1 Phase 1 fixes All 23 items from round one — what you reported, what we did, and where to check it. Read it PHASE 2 Phase 2 fixes Everything solved from Phase 2 testing (September 17 to 28): what you reported, what we changed, and a picture from before and after. Read it

Who does what

A short orientation to the system you are testing: which group you are in, who hears about an order, and how an order finds the person who reviews it. None of this is a test step — it is the background that makes the modules make sense.

The four groups

Access is granted by group, not by job title. Most testers are in the first one.

GroupWhat it lets you doIn QA on Oct 2
Provider Order Management — Standard UserPlace supply orders on behalf of a client, open any order, and see the supply limit on each line. This is the everyday internal role.17 people
Provider Order Management — AdminEverything above, plus the Compliance Configuration page and the compliance dashboards. This is the group that changes the ratios and thresholds.8 people
Compliance Approval ReviewerSees the review panel on an order that went over its limit, and can approve it, trim a line, or deny it with a reason.1 person
Supply Image ManagerEdit the supply catalog — names, supply numbers, prices and images (module PB12).7 people

If a screen or button named in a module simply is not there for you, you are probably not in the group that module assumes. Tell us rather than logging it as a defect — it is a two-minute fix.

Who gets told, and when

Nobody has to go looking. Every decision on an order notifies the people it affects.

When this happensWho hears about itHow
An order goes over its supply limitThe client's account managerBell notification in Salesforce and an email
The account manager approves itWhoever placed the orderEmail
A line is trimmed or the order is deniedWhoever placed the order, and the practiceEmail carrying the reviewer's reason
Nobody reviews it inside the windowBoth sidesEmail — the order releases itself (module PB8)
An admin recalls an order already sent for reviewThe person who submitted itNotification

How an order finds its reviewer

  • Every client record has a Client Owner. That owner is the account manager, and an over-limit order goes to them — there is no queue and no round-robin.
  • To see whose desk an order for the test client Sonora Quest Laboratories (77777) will land on, open that client in Salesforce, go to its Details tab and read Client Owner in the Account Details section. Testers take turns owning the client (module PB6), so the name changes during the round.
  • If you place an order for a client somebody else owns, it goes to that person and will sit there unactioned. Stay on the test client unless a module tells you otherwise.
  • The reviewer is decided at the moment the order is submitted. Changing the owner afterwards does not move an order that is already waiting.
  • If nobody acts within 1 hour, the order releases itself. That short window is a testing value so module PB8 fits in one sitting.

Two things that surprise people

  • "In Progress" is not stuck. It means the order is with an account manager. That is the system working, not a failure.
  • The portal and the internal view show the same limits. Both are scored against the client's real usage feed (Data Cloud) over the last 90 days. The only time you will see a Limit Estimated chip is on a supply with no usage history for that client — then a flat 50 is used, and the screen says so.

Choose your track

Phase 1 and Phase 2 are one system, so they are one journey here: the copper-numbered modules are what’s new this round — the compliance engine, woven into the same two paths.

Track A — Client Supplies

For client-side testers — everything a provider practice does, from first login to the supply limit on every order.

11 modules · 53 scenarios · work through them in number order (1 → 11).

1PA1Not started
Start here

Get in & portal access

Sign in, find your way around, and see only your practice's orders

5 scenarios · about 29 min SQL2-20 · SQL2-21 · SQL2-41 · SQL2-22
2PA2Not started

Wizard UX & validations

Build a cart: search, quantities, units, and the guardrails that stop mistakes

5 scenarios · about 27 min SQL2-24 · SQL2-25 · SQL2-77 · SQL2-26 · SQL2-198
3PA3Not started

Review, confirm & polish

Check the order over, remove a line, and understand what Continue is waiting for

6 scenarios · about 31 min SQL2-45 · SQL2-25 · SQL2-185
4PA4Not started

Catalog deep-dive: search, images, data

Search, categories, product pictures and the detail everyone asks for

5 scenarios · about 22 min SQL2-60 · SQL2-34 · SQL2-36 · SQL2-198
5PA5Not started

Shipping & delivery instructions

Where it ships, standing delivery notes, and notes for this order only

5 scenarios · about 24 min SQL2-44 · SQL2-31
6PA6Not started

Reordering

Copy a past order into a new one, then change it before you place it

Needs one completed order — do PA9 or use an existing one 6 scenarios · about 32 min SQL2-81 · SQL2-94 · SQL2-185 · SQL2-195 · SQL2-197
7PA7Not started

My Order History & the order page

The rebuilt list and order page: tabs, search, recurring deliveries, decisions

6 scenarios · about 33 min SQL2-29 · SQL2-30 · SQL2-196 · SQL2-199 · SQL2-195
8PA8Not started

Support requests & notifications

Raise an inquiry about an order and follow it to an answer

4 scenarios · about 22 min SQL2-27 · SQL2-66 · SQL2-182 · SQL2-202
9PA9Not started

The full journey — place a real order

The finale: place a real order end to end and watch what follows

Do this after PA1–PA5 4 scenarios · about 26 min SQL2-24 · SQL2-25 · SQL2-29 · SQL2-66
10PA10Not started

An order inside the allowance

An ordinary order inside the client's allowance — straight through

3 scenarios · about 20 min SQL2-124 · SQL2-125 · SQL2-127 · SQL2-142 · SQL2-144
11PA11Not started

Asking for more than the allowance

Ask for more than the allowance: what the provider sees and must justify

4 scenarios · about 32 min SQL2-142 · SQL2-143 · SQL2-128 · SQL2-135 · SQL2-144 · SQL2-147
Track B — Internal (Sonora Quest)

For Sonora Quest staff — ordering for clients, catalogue, locations, support, and the compliance review desk.

12 modules · 47 scenarios · work through them in number order (1 → 12).

1PB1Not started
Start here

Order on behalf of a client

Place an order for a client from their record

5 scenarios · about 29 min SQL2-24 · SQL2-94 · SQL2-200 · SQL2-194 · SQL2-186
2PB2Not started

Catalog management

Price books, exclusive product access, and which catalogue a client gets

5 scenarios · about 26 min SQL2-33 · SQL2-35 · SQL2-187 · SQL2-188 · SQL2-189
3PB3Not started

Locations, geocoding & delivery defaults

Create locations, let geocoding fill in the map, set delivery defaults

5 scenarios · about 29 min SQL2-78 · SQL2-32 · SQL2-190 · SQL2-191 · SQL2-192 · SQL2-193
4PB4Not started

Recurring orders (internal)

Standing orders: build a template, manage it, watch a delivery generate itself

5 scenarios · about 33 min SQL2-63 · SQL2-183 · SQL2-184
5PB5Not started

Manage orders, cases & notifications

Find the case behind an order and answer the client where they can see it

Pairs with PA8 — raise the inquiry there first 5 scenarios · about 32 min SQL2-29 · SQL2-27 · SQL2-28 · SQL2-182 · SQL2-202
6PB6Not started

The account manager's review

The Account Manager's review screen: adjust, approve, release

3 scenarios · about 24 min SQL2-146 · SQL2-163 · SQL2-149
7PB7Not started

Saying no, and saying why

Denial: the decision, the reasons, and what the client is told

After PA11 — needs an order under review 3 scenarios · about 20 min SQL2-146 · SQL2-148 · SQL2-163
8PB8Not started

When nobody reviews it in time

Nobody reviews it in time — the order releases or cancels itself

3 scenarios · about 19 min SQL2-147 · SQL2-163
9PB9Not started

Locking a decided order

Once decided, an order locks: what can and cannot be changed

3 scenarios · about 21 min SQL2-148 · SQL2-143 · SQL2-149
10PB10Not started

Recurring orders meet the engine

Standing orders through the engine: approved, held or denied without anyone clicking

Pairs with PB4 3 scenarios · about 21 min SQL2-146 · SQL2-135 · SQL2-179
11PB11Not started

Running the engine day to day

Behind the scenes: the evaluation log, dashboards, the approval queue, Workday

4 scenarios · about 32 min SQL2-145 · SQL2-149 · SQL2-151 · SQL2-150 · SQL2-193 · SQL2-201
12PB12Not started

Keep the supply catalog client-ready

The Supply Images page: what clients see on every card, and how to rename, re-image, price and retire a supply

3 scenarios · about 24 min SQL2-34 · SQL2-60 · SQL2-177
All modules PA1

Get in & portal access

Not started

Why you're testing this

Before anyone can order supplies they have to get into the portal, land somewhere useful, and see only their own practice's data — nothing more. This module is the front door: a branded Client Supplies page whose three tiles take you everywhere, a My Order History list that actually tells you where every order stands, an order page you can read at a glance, and a draft you can leave and come back to.

Full story & acceptance criteria

SQL2-20 — "As a Provider Portal User, I want to use a branded, navigable Experience Cloud portal home and menu, so that I can find key ordering areas quickly." A branded portal home page is available with clear navigation to Orders, Catalog, and Help; I see announcements or quick links to start common tasks; menu options change based on my role.

SQL2-21 — "As a Provider Portal User, I want to work with clear page layouts and helpful list views for Orders and Products, so that I can manage records quickly and confidently." Key fields are grouped logically on Order and Product pages; helpful default views exist (for example, My Draft Orders, Recently Viewed); I can save a personal view and find it later.

SQL2-41 — "As a Provider Portal User, I want to see only the information and actions allowed for my role, so that sensitive data stays protected." I can access what I need for my job and nothing more; I cannot open records from other organizations; if I try an action I am not allowed to do, I see a clear message.

SQL2-22 — "As a Provider Portal User, I want to get friendly checks and automations when I work on orders, so that mistakes are prevented and data stays clean." If I miss a required field, I see a helpful message telling me what to fix; successful saves apply sensible defaults; I can save a draft and return later.

Getting in — you have three separate logins

They are three different accounts on three different systems. They do not share a password, and resetting one does not touch the others. Get all three open before you start and the rest of the day is easy.

What it isWhere you goWhat you use
This testing guide penroddelivery.com Your plain work email, and the password sent to you
The portal, as a client sees it sonoraquest--qa.sandbox.my.site.com/ClientSupplies/
or sign in at qa.sonoraquest.com/providers/dashboard/ with Supply Order SSO, then open the address above
Your portal username — see the table below, the endings differ per person
Salesforce, as our staff see it sonoraquest--qa.sandbox.lightning.force.com Your internal username, always ending .qa

Do not go straight to Salesforce for the client view

To see what a client sees, open the Client Supplies address above and sign in with your portal username, or come in from the Provider Dashboard with Supply Order SSO and then open the same address: you are already signed in there. Going to the Salesforce sandbox directly and signing in there is a different system with a different account, and it will not show you the client experience. If you land on a single sign-on error, this is almost always why — you used the internal login on the portal route.

Your usernames

The endings are not consistent between people. Copy them exactly.

TesterInternal SalesforcePortal (client view)
Aaron Collinsaaron.collins@sonoraquest.com.qaaaron.collins@sonoraquest.com
Bhavani Mamidibhavani.mamidi@sonoraquest.com.qaclinicalreviewuat@sonoraquest.com
Jef Wrightjef.wright@sonoraquest.com.qajefmwright@gmail.com
use this one — the sonoraquest.com portal account sits on a different practice
Kamil Popielakamil.popiela@sonoraquest.com.qakamil.popiela@sonoraquest.com
Mike Davismike.davis@sonoraquest.com.qamike.davis@sonoraquest.com.qasb
Olivia Seiterolivia.seiter@sonoraquest.com.qanot set up yet — internal only for now
Ryan Eidsonryan.eidson@sonoraquest.com.qaryan.eidson@sonoraquest.com.portal

Four things that catch people out

  • Passwords expire after 90 days. If yours has, you will be asked to set a new one on the way in. That is normal. You cannot reuse any of your last five.
  • Stop after two failed attempts. A third locks the account for 30 minutes and no reset will work until it clears. Message us instead and we will send a reset.
  • Salesforce may ask you to set up a passkey. This is new, and it applies to accounts with the System Administrator profile. Choose a verification method and follow the prompt — using your phone camera is the quickest route. It takes a few seconds and you only do it once.
  • If this guide will not load at all, it is your network, not your password. The address ends in .app, which the Sonora network blocks by default. It needs adding to the allow list — tell us and we will chase it rather than you burning time on sign-in.

Something to raise that is not a pass or fail?

Every scenario has a fourth button next to Pass, Fail and Blocked for a suggestion — a cosmetic tweak, or something you wish the system did. There is also a general suggestions box on the module list for anything that does not belong to one scenario. Use them freely; they reach us the same way a failure does.

Scenario 1 · ~5 min SQL2-20

Sign in and find your way around

Not run

What you're checking: the supply pages, which start at Client Supplies, are clearly Sonora Quest's, and the three tiles and the back arrow reliably get you to every area you'll use for the rest of this guide — and back again.

  1. Open the Client Supplies address, sonoraquest--qa.sandbox.my.site.com/ClientSupplies/, and sign in with your portal username and password. The sign-in box itself is a plain Salesforce login screen — no Sonora Quest logo there yet. That's expected; the branding starts the moment you're inside. If you came in from the Provider Dashboard with Supply Order SSO, open the address in the same browser: you are already signed in, and no sign-in box appears.
  2. Confirm the page you land on is branded: the Sonora Quest Laboratories logo top-left, Return to Provider Dashboard top-right, and the heading Client Supplies underneath.
    Client Supplies — home
    Branded home: the logo, Return to Provider Dashboard, the Client Supplies heading and three tiles — Order Supplies, My Order History, Knowledge Center
    The menu that used to run under the logo — Home · My Orders · TIQs · Support · New Order — is gone from the supply pages, and so is Contact Us. That is deliberate: you now move with the three tiles and the back arrow beside each page's name.
  3. Check the three grey tiles under the Client Supplies heading — Order Supplies, My Order History and Knowledge Center — each with its icon and one line saying what it is for.
  4. Click Order Supplies. The order screen opens with a back arrow and its own name at the top-left: ‹ Order Supplies. Click that arrow to come back to Client Supplies.
  5. Click My Order History. Your list of orders opens, headed ‹ My Order History. Click the arrow to come back.
  6. Click Knowledge Center. It opens Sonora Quest's Support page. That page belongs to Sonora Quest's own portal, not to the supply pages, so it keeps their header and a menu of its own, whose Home leads to that portal. Use your browser's Back button to come back to Client Supplies.
Expected result
  • Once you're signed in, the supply pages carry the Sonora Quest logo and Return to Provider Dashboard — and no menu bar.
  • All three tiles open a real page — no blanks, no errors.
  • The back arrow beside a page's name always returns you to the same Client Supplies screen with its three tiles, and each tile opens the area its label promises.
Result:
Scenario 2 · ~6 min SQL2-41

You only ever see your own practice's data

Not run

What you're checking: the practice you're ordering for and the person the order can be shipped to are both scoped to your account — there is no picker that lets you wander into another organization's data.

  1. Click the Order Supplies tile on Client Supplies. The wizard opens straight onto Select Items with your products already loaded — nothing to choose first.
  2. Look at the Filters panel down the left: CLIENT / FACILITY is already filled in with your practice's name. Open that dropdown.
    Order Supplies — Select Items, Filters panel
    CLIENT / FACILITY is pre-filled with your practice; the catalog has already loaded underneath it
  3. Confirm your own practice is the only option in that dropdown — no list of Sonora Quest's other customers. Close it again.
  4. Click Add to Cart on any product, then Continue to Review.
  5. On Review Your Order, find the Shipping Contact card on the right and read SHIP TO CONTACT. It is already filled in with your own name, and there is nothing to open — no list, no picker.
    Review Your Order — Ship To Contact, pinned
    SHIP TO CONTACT is filled in with your own name and locked — a portal sign-in never gets a list of other people to choose from
    Seeing your own name, fixed, with no dropdown to open is the correct result, not a missing control. Portal sign-ins are deliberately pinned to the contact behind the login so an order can't be shipped to someone else's name by accident. (Sonora Quest staff ordering internally do get a picker — limited to your practice's portal contacts.)
  6. Leave the wizard (click the back arrow, ‹ Order Supplies, at the top-left) — you don't need to finish this order.
Expected result
  • CLIENT / FACILITY offers your practice and nothing else.
  • Ship To Contact is fixed to your own name — there is no list of other people.
  • Nowhere in the wizard is there a way to pick another organization.
Result:
Scenario 3 · ~6 min SQL2-21

My Order History — your home base for everything you've ordered

Not run

What you're checking: My Order History opens as a purpose-built list — filter tabs with live counts, a search box, and a one-line summary of what each order actually contains — instead of a generic table you have to decode.

  1. Click the My Order History tile on Client Supplies.
    Portal — My Order History
    Filter tabs with live counts, a line under them when only your most recent orders are listed, one row per order with its status and contents, pagination underneath, and a right rail with Create Order and At a glance
  2. Read the filter tabs across the top — All, Drafts, In Review, Completed, Denied, Recurring — each with its own count. Click two or three of them and watch the list below change.
  3. Look at any single row: the order number, a coloured status tag, and a plain-English summary line such as "2 items · 2 units — " followed by the product names, with the date on the right.
  4. Type part of an order number into Search by order number... at the top, and confirm the list narrows to matching orders. Clear it again.
  5. Check the right-hand rail: a teal Create Order button, an At a glance box that counts, among the listed orders, those awaiting review, the drafts to finish, the ones completed this month and those with an open or an answered inquiry, and a short "Question about an order?" explainer.
  6. Scroll to the bottom and confirm the pagination line ("Showing 1–10 of ...") and the page numbers. Click page 2 and then back to 1.
Expected result
  • The tabs, the counts and the list all agree with each other, and switching tabs is instant.
  • Every row tells you what the order contains without opening it.
  • Search narrows the list; pagination moves you through it ten orders at a time.
  • The Recurring tab and the deeper behaviour of each row get their own module later — here you're only checking that the list itself works.
Result:
Scenario 4 · ~5 min SQL2-21

Open an order and read it at a glance

Not run

What you're checking: one click from the list gets you a full order page where the status, the items, the shipping details and the history are all grouped into labelled cards rather than one long list of fields.

  1. Click anywhere on an order's row in My Order History (the whole row is the button — the chevron on the right is just a signpost).
  2. Check the top of the page: the order number, its status tag, your practice name, and an Order Progress bar running Draft → In Progress → Approved → In Fulfillment → Shipped, with Denied and Canceled at the end. The stage the order has reached is highlighted, and Last Updated sits beside it.
    Portal — order page
    Order Progress and Last Updated up top; Items on this Order, Details, Shipping and Order History in labelled cards below
  3. Confirm the two action buttons under the progress bar: View Order (or Resume Order if this one is still a draft) and Submit an Order Inquiry.
  4. Read the Items on this Order card — it lists each product with its supply number, its ordering unit and the quantity, and a total line such as "2 items · 2 units".
  5. Scroll down through Details (client, order date, created, status), Shipping (location, address, ship-to contact) and Order History (a timestamped log of every status change).
Expected result
  • The order opens on its own page with the number in the URL and the status shown twice — as a tag and on the progress bar.
  • Items, details, shipping and history are each in their own labelled card; nothing important is buried.
  • Order History shows at least the "Created" entry, plus one row per status change with the date and time.
Result:
Scenario 5 · ~7 min SQL2-22

Save a draft, walk away, come back to the same order

Not run

What you're checking: Save Draft confirms with a real order number, the draft is easy to find again, and resuming it brings back exactly what you left — under the same number, never a duplicate.

  1. Open Order Supplies from Client Supplies, add one product with Add to Cart, then click Continue to Review.
  2. Click Save Draft at the top-right of the Review screen and write down the order number in the green confirmation.
    Review Your Order — Draft Saved
    Green toast: "Draft Saved — Order 00000631 saved as draft." — and the button has changed from Save Draft to Save Changes
    Once the draft exists the button relabels itself to Save Changes. That's the signal that further saves update the same order instead of creating another one.
  3. Go to My Order History — click the back arrow, ‹ Order Supplies, then the My Order History tile — and click the Drafts tab. Your new order is at the top with a yellow Draft tag and the item you added.
  4. Open it. The order page shows Resume Order instead of View Order, and its Items card is labelled "draft contents, may change until the order is placed".
  5. Click Resume Order and confirm the wizard comes back with your product and quantity exactly as you left them, on the Review Order step.
    Order page — Resume Order
    Resume opens the wizard as a window on top of the order page, already on Review Order with your item loaded
    Resume opens the wizard in a window over the order page rather than moving you to a new page, so the address bar doesn't change and you can still see the order behind it. Close the window with the × in its top-right corner.
  6. Change the quantity to something else, click Save Changes, then reopen the draft from My Order History and confirm the new quantity stuck — and that there is still only one draft with that number.
Expected result
  • Save Draft always confirms with a real order number you can find again.
  • The draft appears under the Drafts tab and opens with a Resume Order button.
  • Resuming restores everything you entered, and saving again updates the same order — it never creates a second one.
Result:
All modules PA2

Wizard UX & validations

Not started

Why you're testing this

This is the skeleton every other portal module stands on: the five-step trail, the cart, the quantity guardrails and the filters. The job here is to try to break it on purpose — jump backwards, push forward with an empty cart, type nonsense quantities — and prove it fails safely and tells you why. It's also where you'll first see each product's ordering unit spelled out, which was one of the things you asked for after the last round.

Full story & acceptance criteria

SQL2-24 — "As a Provider Portal User, I want a step-based order wizard framework and navigation design, so that I move through ordering with clear progress." The wizard shows clear steps; I can move forward and back without losing my progress; empty, loading and error states are easy to understand.

SQL2-25 — "As a Provider Portal User, I want a product selection and cart experience, so that I can add multiple items and adjust quantities easily." I can add or remove items and see totals update immediately; I can change quantities and see clear guidance if something is invalid; my selections are remembered as I move between steps.

SQL2-77 / SQL2-26 — (the same request logged twice) "As a Provider Portal User, I want to search and filter products with results in pages, so that I can locate products by keyword and filters." Typing letters returns matching products; I can apply simple filters to narrow results.

SQL2-198 — "As a Provider Portal User, I want to know what unit I'm ordering in." Every product now carries a unit-of-measure chip — Each, Box, Case and the rest of the Workday unit list — on the product row, in the cart, on Review, on Confirm and on the finished order.

Scenario 1 · ~6 min SQL2-24

Move forward and back without losing your progress

Not run

What you're checking: the step trail across the top always tells you where you are, and jumping backwards never throws away what you already picked.

  1. Open Order Supplies from Client Supplies and read the trail across the top: 1 Select Items → 2 Review Order → 3 Shipping Address → 4 Confirm → 5 Submitted. Step 1 is filled in teal; the rest are grey.
    Order wizard — Select Items
    The five-step trail sits right under the page's name; Continue to Review is pale and unclickable while the cart is empty
  2. Add one product with Add to Cart, then click Continue to Review.
  3. Look at the trail again — Select Items now shows a teal tick, and Review Order is the numbered, highlighted step. Back and Continue sit at the top-right of the page.
  4. Click the words Select Items in the trail itself (not the Back button). Click the step's label or its circle, not the empty space beside it. Steps you've already completed turn into a pointer when you hover; steps you haven't reached yet don't respond at all — that's deliberate.
  5. Confirm you land back on Select Items with everything intact: the product still carries an In Cart badge, Your Cart still lists it, and the counter still reads 1 Items in Cart.
    Select Items — after jumping back from Review
    The cart survived the jump: Your Cart (1) in the sidebar and the In Cart badge on the product row
  6. Click Continue to Review again — your item is still there, unchanged.
Expected result
  • The trail always shows the current step, with completed steps ticked and later steps greyed out.
  • Completed steps are clickable; steps you haven't reached are not.
  • Going back and forward leaves the cart exactly as it was.
Result:
Scenario 2 · ~3 min SQL2-24

An empty cart can't move forward

Not run

What you're checking: you can't get past Select Items with nothing in your cart, and the button tells you so without an error message.

  1. Open Order Supplies fresh. If anything is already in the cart, click Remove on each row until the cart is empty.
  2. Look at Continue to Review in the top-right with nothing in the cart — it's a washed-out pale teal instead of the solid teal it turns once something is added.
  3. Click it anyway. Nothing happens — and no error pops up, because a disabled button has nothing to complain about. The greyed-out button is the message.
  4. Add any one product and watch the same button turn solid teal, with a Items in Cart counter appearing beside it.
Expected result
  • With an empty cart, Continue to Review is visibly disabled and does nothing when clicked.
  • Adding one product enables it immediately and shows the cart counter.
Result:
Scenario 3 · ~6 min SQL2-198 SQL2-25

Add to cart — and see the unit you're ordering in

Updated from your feedback Not run

What you're checking: adding a product changes the row into a working cart line, and every product now states its ordering unit — Each, Box, Case — so "1" never has to be guessed at again. This is the change made after your note that you couldn't tell what a unit was.

  1. Open Order Supplies and look along the top line of any product row: the supply number, then a small teal chip with an icon — Each, Box or Case. That chip is the unit one of that item ships in.
  2. Hover your mouse over the chip and wait a second. A tooltip spells it out in words, e.g. "Case — ordered by the case". If a chip reads N/A, that item's unit hasn't been supplied by the item master yet — it's a data gap on that one product, not a broken chip. Note the product name in your comments and carry on.
  3. Click Add to Cart on two different products with different unit chips if you can find them.
    Select Items — two products added
    Green Product Added toast, an In Cart badge on the row, and the row now shows a UNIT column (Kit), a QTY box and a red Remove button
  4. Confirm for each added row: a green Product Added toast appears top-right, the row gains an In Cart badge, and the Add to Cart button is replaced by a UNIT chip, a QTY box and a red Remove button.
  5. Check the Your Cart panel at the bottom of the left-hand column — it lists each product with its quantity — and the Items in Cart counter at the top.
  6. Click Remove on one of them and confirm it disappears instantly, the counter drops, and the row goes back to showing Add to Cart.
Expected result
  • Every product row states its ordering unit as a chip, with a plain-English tooltip on hover.
  • The same unit follows the item into the cart's UNIT column — and, later, onto Review, Confirm and the finished order.
  • Adding and removing update the cart, the counter and the row instantly, with no page reload.
Result:
Scenario 4 · ~7 min SQL2-25

Quantity guardrails — and the Continue button that won't let you past them

Not run

What you're checking: the QTY box rejects nonsense with a message that names the product, and the wizard refuses to carry a bad quantity forward.

  1. Add PIPET TRANSFER W/GRADUATIONS (supply 900010) to your cart, then click into its QTY box (it sits next to the UNIT chip). Using this one supply all the way through keeps the numbers in the last step predictable.
  2. Select everything in the box, type 0, then click somewhere else on the page to confirm the value.
    Select Items — quantity 0
    Red toast top-right: "Invalid Quantity — Quantity must be at least 1 for [product]. Please enter a valid quantity." — and Continue to Review has gone pale again
  3. Read the red toast: it names the exact product and tells you the minimum. Now look at Continue to Review — it has greyed out. Click it; you stay where you are.
  4. Try -5 the same way — the same "must be at least 1" toast appears.
  5. Try typing letters into the box. Nothing appears as you type: it's a numbers-only field, so letters are blocked at the keyboard rather than rejected afterwards.
  6. Set the quantity to a sensible number such as 5. The toast stops coming back and Continue to Review turns solid teal again.
  7. Now set the quantity deliberately over the allowance — type 60 — and click Continue to Review. Over-allowance quantities are allowed here on purpose — they're checked against your practice's supply allowance on the next screen, where you'll see a SUPPLY LIMIT panel and, if you're over, a request for a justification. That panel shows ALLOWED with a chip: Within Your Limit and a figure built from your practice's real usage on the four feed-backed supplies, or Limit Estimated with a flat 50 on a supply that has no history. Either way, 60 goes over it. That whole conversation has its own set of modules; for this scenario just confirm the wizard lets you through and the Review screen shows a supply-limit panel on the line.
Expected result
  • 0 and negative numbers both raise a red Invalid Quantity toast naming the product.
  • While a quantity is invalid, Continue to Review is disabled — you cannot carry a bad line forward.
  • Letters can't be typed into the box at all.
  • A valid quantity clears the toast and re-enables the button; a quantity over the allowance is still carried through to the supply-limit check on Review.
Result:
Scenario 5 · ~5 min SQL2-77 SQL2-26

Narrow the list without leaving the step

Not run

What you're checking: the Filters panel narrows the product list live, and whatever is in your cart survives every search you type.

  1. On Select Items, note the bold count above the list ("n products found") — it always matches the number of rows showing.
  2. Type a few letters of a product you can see into Search Products — the list narrows as you type, with no button to press.
    Select Items — search in progress
    The count above the list updates on every keystroke and the rows below match what you typed
  3. Open the Category dropdown below the search box and pick one of the categories offered. The list narrows again; the count follows.
    Select Items — Category dropdown open
    Category sits directly under Search Products and opens as a plain list, starting with All Categories
  4. Set Category back to All Categories and clear the search box — the full list comes back.
  5. Confirm that anything you had in Your Cart before searching is still there, and still marked In Cart once its row reappears.
Expected result
  • Search filters the list on every keystroke; the "products found" count always matches what's on screen.
  • Category narrows the list further and combines with the search term.
  • Clearing both restores the full catalog, and the cart is untouched throughout.
  • Searching, sorting and the product-detail window are covered in more depth in the catalog module.
Result:
All modules PA3

Review, confirm & polish

Not started

Why you're testing this

The last two steps of the wizard carry the whole promise: before you submit you can see everything — items, units, quantities, who it's going to, where it's going and what it totals — and after you submit you get a number you can quote. This module also carries the change you asked for last round: you can now drop a line straight from the Review screen instead of going back to the catalog.

Full story & acceptance criteria

SQL2-45 — "As a Provider Portal User, I want to review and submit an order with clear confirmation, so that I know exactly what I submitted." Before submitting, I see items, quantities, shipping and totals; after submitting, I see a confirmation with my order number; if there is an error, I get a friendly message and no order is created.

SQL2-25 — "As a Provider Portal User, I want a product selection and cart experience, so that I can add multiple items and adjust quantities easily." I can add or remove items and see totals update immediately; my selections are remembered as I move between steps.

SQL2-185 — Your feedback: there was no way to remove an item once you reached the Review screen — you had to walk back to the catalog. Each line on Review now has its own Remove control with a confirm step, so a mis-added item takes two clicks to undo.

Scenario 1 · ~6 min SQL2-45

Review Order — everything on one screen before you commit

Not run

What you're checking: the Review screen shows every line with its unit and quantity, a running Order Summary, and the shipping contact card — with nothing hidden until later.

  1. Open Order Supplies, add two different products, then click Continue to Review.
    Order wizard — Review Your Order
    Order Items with a count chip, each line showing UNIT / QTY / Remove and a SUPPLY LIMIT panel; Shipping Contact and Order Summary down the right
  2. Check each line shows: the supply number, the product name, a short description, the UNIT chip carried over from the catalog, an editable QTY box and a Remove control.
  3. Check the Order Items heading carries a count chip ("2 items") that matches the number of lines.
  4. Check the Order Summary card on the right shows Total Items and Total Quantity. Change one line's quantity and watch both update immediately.
  5. Note the SUPPLY LIMIT block under each line — a status chip, an ALLOWED figure and a How is this calculated? link. The supply-limit panel is the compliance check, and it has its own set of modules later in this guide. For this scenario just confirm the panel is there on every line — you're not judging the numbers yet. The ALLOWED figure differs from line to line — it is three times the client's recorded usage over the last 90 days, less what has already been ordered — and the chip reads Within Your Limit on the four supplies that carry usage history. A supply with no history falls back to 50, badged Limit Estimated.
  6. Note the Save Draft button in the top-right corner of the card — it's available from here on, on every remaining step.
Expected result
  • Items, units, quantities and totals are all visible on this one screen without scrolling to another page.
  • Totals recalculate the moment a quantity changes.
  • A Shipping Contact card and a supply-limit panel per line are both present.
Result:
Scenario 2 · ~5 min SQL2-185

Drop a line without leaving the Review screen

Updated from your feedback Not run

What you're checking: the fix for the thing you hit last round — a wrong item on the Review screen can now be removed right there, with a confirm step so it can't happen by accident.

  1. Start from Review Order with two or more lines (add a third product if you only have two — you'll want at least one left afterwards).
  2. Click the red Remove on the line you want gone. It does not disappear yet — the control arms itself and changes to a solid red Confirm?.
    Review Your Order — Remove armed
    One click arms the control: the second line's button has become a solid red Confirm? while the other line still reads Remove
  3. Wait a few seconds without clicking. The control disarms itself and goes back to Remove — nothing is lost by hesitating.
  4. Click Remove again, then Confirm? straight after. The line disappears immediately.
  5. Check the Order Items count chip and the Order Summary totals both drop to match what's left.
  6. Click the Select Items step in the trail and confirm the product you removed is back to showing Add to Cart — the removal reached the cart, not just the display.
Expected result
  • Remove takes two deliberate clicks — the first arms it, the second removes.
  • An armed control resets itself after a few seconds if you don't confirm.
  • The count chip, the totals and the cart on Select Items all agree afterwards.
Result:
Scenario 3 · ~5 min SQL2-45

Two quiet guards: a pinned contact and a quantity that won't go to zero

Not run

What you're checking: the order can't leave the Review screen without a contact or with an empty line — and both guards work quietly (a name that is set for you, a box that refuses 0) rather than as an error after the fact.

  1. Look at the Shipping Contact card on the right. SHIP TO CONTACT is marked required with a red asterisk and already reads your own name, with nothing to open — that is the first guard: an order can never leave Review without a contact, and yours is set for you.
  2. Look at Continue at the top-right of Review Your Order — it is solid teal before you touch anything, because the contact is set and every quantity is valid.
    Review Your Order — contact pinned, Continue live
    SHIP TO CONTACT already holds your name and can't be changed; with every quantity valid, Continue is solid teal from the start
  3. Set one line's QTY to 0 and click elsewhere. The box refuses it and snaps back to 1 — the second guard. A line can never sit on the order at zero; to get rid of one, use Remove (Scenario 2).
  4. Type a valid number back in, for example 2, and check the Order Summary follows. Continue stayed teal throughout — it only greys out when a line is over its allowance, which modules PA10 and PA11 cover.
Expected result
  • SHIP TO CONTACT is filled in with your own name and can't be changed — Continue never waits on it.
  • A quantity of 0 is refused: the box returns to 1, so an order can't carry an empty line.
  • You never reach the next step carrying an incomplete order.
Result:
Scenario 4 · ~6 min SQL2-45

Confirm Order & Submit — the last look before it's real

Not run

What you're checking: the final screen is a complete, accurate recap — where it's going, what's in it, who's ordering and what it totals — with nothing you'd have to take on trust.

  1. Click Continue from Review to reach Shipping Address, leave the pre-selected default location as it is, and click Continue again.
  2. Read the Shipping Address card on the left of Confirm Order & Submit: the location name, the full street address, a DELIVERY INSTRUCTIONS box if that address has any, and an embedded map with a pin on it.
    Order wizard — Confirm Order & Submit
    Address, delivery instructions and map on the left; Ordering As and Order Summary on the right; Place Order top-right
  3. Check the Ordering As card on the right — Name, Email, Phone and Facility — and confirm it matches the contact you chose on Review.
  4. Check the Order Summary card: Products (how many lines) and Total Quantity (how many units), plus the note "By placing this order, you confirm all details are correct".
  5. Scroll down to Order Items and confirm every line repeats its supply number, name, quantity and unit, with the same supply-limit information you saw on Review.
  6. Click Back once to prove you can still change your mind, then Continue forward again — nothing is lost.
Expected result
  • Confirm shows a complete recap: address + map, delivery instructions where they exist, who's ordering, every line with its unit, and correct totals.
  • Everything matches what you entered on the earlier steps.
  • Back and Continue move you between steps without losing anything.
Result:
Scenario 5 · ~6 min SQL2-45

Place Order and read the confirmation

Not run

What you're checking: submitting gives you an order number you can quote, a status tracker showing where the order sits, and a full recap of what you just sent.

  1. Click Place Order on Confirm Order & Submit and give it a few seconds — the order is being checked against your supply allowance while you wait.
  2. Confirm you land on Submitted with a tick, the words "Order Submitted Successfully!" and an ORDER NUMBER badge. Write that number down in the comments box.
    Order wizard — Order Submitted Successfully!
    Order number badge with a copy icon, the status tracker underneath, and the four follow-on buttons
  3. Read the status tracker: Draft → In Progress → Approved → In Fulfillment → Shipped, with the stage your order reached highlighted. An order whose every line sits under its allowance — a handful of units each — normally lands on Approved straight away. If yours stops at In Progress it means a line went over that allowance and an account manager has to look at it first — that's correct behaviour, not a failure, and it has its own modules later.
  4. Confirm the four buttons are there: Place New Order, Reorder, View Order Details and Submit an Order Inquiry.
  5. Scroll down and check the recap: Order Items (each with QTY and UOM), Order Summary (Order Number, Order Date, Client, Status) and Shipping Details (address plus delivery instructions) — all matching what you submitted.
Expected result
  • A clear success screen with a prominent, copyable order number.
  • The tracker shows where the order stands, and the Status in Order Summary says the same thing.
  • Items, units, quantities, address and instructions all match what you sent.
Result:
Scenario 6 · ~3 min SQL2-45

Start a fresh order — nothing carries over

Not run

What you're checking: "Place New Order" really does start from scratch, so the next order can't accidentally inherit the last one's contents.

  1. From the Submitted screen, click Place New Order.
  2. Confirm you're back on Select Items with step 1 highlighted, nothing marked In Cart, and no cart panel at the bottom of the Filters column.
  3. Confirm Continue to Review is greyed out again with the empty cart.
  4. Go to My Order History — the back arrow, ‹ Order Supplies, then the My Order History tile — and confirm the order you just placed appears at the top of the All list with its number and status — and that no extra, empty order was created alongside it.
Expected result
  • The wizard resets to a genuinely empty Select Items — no products carried over.
  • Continue to Review stays disabled until something is added.
  • My Order History shows exactly one new order for what you submitted.
Result:
All modules PA4

Catalog deep-dive: search, images, data

Not started

Why you're testing this

Three tickets converge on one promise: the moment you open the wizard you are already looking at your practice's products — searchable, sortable, illustrated, and each one labelled with the unit it's ordered in. There is no catalog to choose and no price book to fill in. This module is where you push the catalog itself: search it, sort it, open a product, and check the data behind each row.

Full story & acceptance criteria

SQL2-60 — "As a Provider Portal User, I want to browse and search available supplies with descriptions and optional images, so that I find items quickly." Searching by name returns exact and partial matches; results show name and description clearly; I can move through a long list of results.

SQL2-34 — "As a Provider Portal User, I want to apply the correct product list automatically when I start an order." When I start an order, the correct product list is applied for my organization; I only see items my organization is allowed to order.

SQL2-36 — "As a Provider Portal User, I want the system to auto-associate my order with the right product catalog at initiation, so that ordering uses the correct catalog without extra steps." Starting an order sets the product catalog without manual selection. (Manual catalog switching was removed from the portal after the marketing review, so this module tests auto-load only.)

SQL2-198 — Your feedback: you couldn't tell what unit an item was ordered in. Every product now carries a unit chip — Each, Box, Case and the rest of the Workday unit list — with a plain-English tooltip.

Scenario 1 · ~5 min SQL2-34 SQL2-36

Your catalog loads itself — there is nothing to pick first

Not run

What you're checking: opening the wizard puts your practice's own product list on screen straight away, with no "Price Book" or "Product Catalog" field anywhere for you to fill in or get wrong.

  1. Click the Order Supplies tile on Client Supplies. The wizard opens directly on Select Items.
  2. Confirm the product list is already populated and the bold "n products found" counter is above it — you didn't choose anything to make that happen.
    Order wizard — Select Items
    CLIENT / FACILITY is pre-filled, the catalog is already loaded, and the only filters offered are Search Products and Category — no catalog picker
  3. Read the whole Filters panel top to bottom. The only fields are CLIENT / FACILITY (pre-filled with your practice), SEARCH PRODUCTS and CATEGORY. There is no Price Book field and no Product Catalog field.
  4. Add any item with Add to Cart and click Continue to Review — your item carries through untouched, still with the same supply number and unit.
  5. Click the Select Items step in the trail to come back.
Expected result
  • The catalog is scoped and loaded automatically — you never choose a price book or a catalog.
  • Only products your practice is allowed to order appear.
  • What you select survives the move to Review Order unchanged.
Result:
Scenario 2 · ~5 min SQL2-60

Search by name or code — including when nothing matches

Not run

What you're checking: the search box filters live on every keystroke, matches both names and supply codes, and gives you an honest zero when there's nothing to show.

  1. Note the "n products found" counter above the list before you start.
  2. Type a single letter into Search Products (the placeholder reads "Search name or supply #"). The counter reacts immediately — you don't have to type three letters first.
    Select Items — search filtered
    The counter above the list and the rows below always agree; matching is on the product name and its supply code
  3. Keep typing to spell out part of a product name you can see in the list, and confirm the rows narrow to matches only.
  4. Clear the box and type part of a supply code from any row instead — the same product comes back, so the search covers codes as well as names.
  5. Clear it again and type nonsense, e.g. xzq999.
    Select Items — no matches
    The counter drops to 0 products found and the panel below goes blank
    With zero matches the area under the counter simply goes empty — there's no "No products found" illustration yet. The 0 products found counter is the message. That's expected, not a broken page.
  6. Clear the search box — the full catalog comes back and the counter returns to where it started.
Expected result
  • The list filters after every keystroke, matching names and supply codes.
  • The counter always equals the number of rows on screen.
  • A search with no matches shows 0 products found and an empty panel; clearing it restores everything.
Result:
Scenario 3 · ~4 min SQL2-198

Every product says what unit it comes in

Updated from your feedback Not run

What you're checking: the answer to "a quantity of 1 gets me what, exactly?" — every row now carries a unit chip, and hovering it spells the unit out in words.

  1. Look along the top line of any product row: SUPPLY # and its code, then a small teal chip with its own icon — Each, Box, Case or another unit from the Sonora Quest unit list.
  2. Compare a few rows and confirm the chips differ product by product — they come from the item master, not from a single default.
  3. Hover over a chip and hold still for a second. A tooltip appears reading, for example, "Case — ordered by the case" or "Box — ordered by the box". It's a hover tooltip, so give it a moment and don't move the mouse. If a chip reads N/A, that product's unit hasn't been supplied by the item master yet — note the product name in your comments; it's a data gap on that item, not a fault in the chip.
  4. Add that product to your cart and confirm the same unit now appears in the row's UNIT column.
  5. Click Continue to Review and confirm the unit is still shown against the line there. It stays with the item all the way through Confirm, the Submitted screen and the finished order page.
Expected result
  • Every product row shows a unit chip beside its supply number, and units vary by product.
  • Hovering gives a plain-English explanation of the unit.
  • The unit follows the item into the cart, onto Review, and onward — you never have to guess what "1" means.
Result:
Scenario 4 · ~4 min SQL2-60

Open a product and read its details

Not run

What you're checking: each row carries a photo, a supply code and a description, and the photo opens full size with the product's details beside it.

  1. Check the anatomy of any row: a square photo on the left, then SUPPLY # with its code, the product name in bold, and a description line underneath. Some descriptions are richer than others and a few are still placeholder text — that's product data being loaded in, not a layout problem. You're checking that the name / code / description / photo layout is there on every row.
  2. Hover over a product's photo — a VIEW DETAILS overlay appears across it.
  3. Click the photo. A details window opens with the product name in the title bar.
    Select Items — product details window
    Full-size photo, then SUPPLY # and CATEGORY side by side, with the full DESCRIPTION underneath
  4. Confirm the window shows the photo full size, the SUPPLY #, the CATEGORY and the complete DESCRIPTION — not the truncated version from the row.
  5. Close the window with the × in its top-right corner and confirm you're back on the list exactly where you were, with your cart untouched.
Expected result
  • Every row has a photo, supply code, name and description.
  • Clicking a photo opens the details window with the full-size image and the product's supply number, category and full description.
  • Closing it returns you to the list with nothing changed.
Result:
Scenario 5 · ~4 min SQL2-60

Sort the list, and scroll it without losing the filters

Not run

What you're checking: the two sort buttons reorder the list instantly and toggle direction, and a long catalog scrolls inside its own panel instead of pushing the filters off the screen.

  1. Find Sort by: above the list, top-right. Two buttons: Name and Supply #. The active one is filled teal and carries a small direction arrow — by default that's Name ↑, alphabetical.
  2. Click Supply #. The list reorders by supply code, the teal fill moves to that button, and the arrow becomes Supply # ↑.
    Select Items — sorted by Supply #
    The active sort button is the filled teal one; the arrow beside its label shows the direction
  3. Click Supply # a second time. The arrow flips to Supply # ↓ and the order reverses — the item that was first is now last.
  4. Click Name to go back to alphabetical order.
  5. Scroll with your mouse over the product list itself. The list moves inside its own panel while the Filters column, the "products found" counter and the Sort buttons all stay exactly where they are.
  6. Type something into Search Products while a sort is active and confirm the results stay in the order you chose.
Expected result
  • Either sort button reorders the list immediately; clicking the active one again reverses it and flips the arrow.
  • The results panel scrolls on its own, so the filters and page header never move.
  • Sorting and searching work together rather than resetting each other.
Result:
All modules PA5

Shipping & delivery instructions

Not started

Why you're testing this

Every practice has a delivery quirk — a locked gate, a loading dock, a front desk that signs for everything. This module proves you can pick which of your addresses an order goes to, park a standing note on that address so the driver gets the same guidance every time, add a one-off comment for just this order, and watch both follow the order through to the end.

Full story & acceptance criteria

SQL2-31 — "As a Provider Admin, I want to save default delivery instructions per ship-to address, so that drivers receive consistent guidance." I can add default instructions to a ship-to address; orders to that address show the instructions on review; updating instructions affects new orders.

SQL2-44 — "As a Provider Portal User, I want to choose a saved shipping address, so that shipping information is accurate for delivery." I can select from saved addresses with clear guidance; the selected address shows in the final review; I have the option to override the default address.

Scenario 1 · ~5 min SQL2-44

Choose where this order is delivered

Not run

What you're checking: step 3 shows every address your practice has on file as a card, with one clearly marked as the default and pre-selected, and lets you send this particular order somewhere else.

  1. Start a new order: Order Supplies, add a product, Continue to Review, then Continue — your name is already set as the Ship To Contact.
  2. Confirm you're on Shipping Address — "Choose where you'd like your order delivered" — with your saved locations laid out as cards.
    Order wizard — Shipping Address
    One card per saved address; the default carries an amber DEFAULT tag and starts selected, and any standing delivery note shows in a grey strip under the address
  3. Check the pre-selected card: its radio button is filled, its border is teal, and it carries an amber DEFAULT tag. At the very bottom of the step, DELIVERING TO: names that same location.
  4. Check the three small icon buttons on the right of every card. Hover each to read its label: Set as default location (or "This is your default location" on the current default), Add delivery instructions / Edit delivery instructions, and View map.
  5. Click a different card to select it for this order, and confirm the teal outline and the DELIVERING TO: line both move to it — while the amber DEFAULT tag stays where it was.
  6. Click back onto the DEFAULT card so the rest of this module runs against it.
Expected result
  • Every saved address is shown as its own card, with one marked DEFAULT and selected for you.
  • Selecting a different card changes where this order goes without changing your default.
  • Each card offers the same three actions: set as default, edit instructions, view map.
Result:
Scenario 2 · ~4 min SQL2-44

Change which address is your default

Not run

What you're checking: you can move the DEFAULT tag to whichever address you use most, and doing so changes what's pre-selected next time — not where the order in front of you is going.

  1. Note which card currently carries the amber DEFAULT tag, and which card is currently selected for this order.
  2. Click the bookmark icon on a card that is not the default — the one whose tooltip reads Set as default location.
  3. Confirm the amber DEFAULT tag moves to the card you clicked, and the card that used to be the default now offers Set as default location itself.
  4. Confirm your order hasn't moved: the teal outline and the DELIVERING TO: line at the bottom still name the card you selected in Scenario 1. Changing the default only changes what's pre-picked on future orders.
  5. Cleanup — please do this: click the bookmark on the address that was the default when you started, to put it back. This is a shared test account and other testers rely on it.
Expected result
  • The DEFAULT tag moves to the card you bookmark, immediately.
  • The order you're currently building keeps shipping to whichever card you selected.
  • Putting the original default back works the same way.
Result:
Scenario 3 · ~3 min SQL2-44

Check an address on the map before you send anything to it

Not run

What you're checking: each saved address can be confirmed visually — the system has already looked it up and knows exactly where it is.

  1. Click the map-pin icon on any location card — the one whose tooltip reads View map.
  2. Confirm a Location Details window opens, titled with the location's name.
    Shipping Address — Location Details
    A pinned map of the address with Map and Satellite views, and Close to go back
  3. Check the map has a red pin on the address, and that you can switch between Map and Satellite.
  4. Check the pin sits on the address you expect. The window shows the map and nothing else: altitude and coordinates are kept for Sonora Quest's own staff, who use them to check that an address was placed correctly.
  5. Click Close and confirm you're back on the Shipping Address step with your selection unchanged.
Expected result
  • The Location Details window opens for any address and pins it correctly on the map.
  • The pin sits on the address itself — the address was successfully looked up when it was created.
  • Closing the window leaves your order untouched.
Result:
Scenario 4 · ~7 min SQL2-31

A standing note for the driver — and a one-off comment for this order

Not run

What you're checking: the two kinds of instruction are kept separate — one saved on the address for every future delivery, one attached to this order only — and both are written in the same window.

  1. Click the note icon on the location you're shipping to — its tooltip reads Add delivery instructions, or Edit delivery instructions if that address already has some. A note icon tinted teal means that address already has standing instructions, and you'll see them previewed in a grey strip on the card. That's fine — this is a shared test account. You're checking that you can add or change a note, not that it starts empty.
  2. Read the Delivery Instructions window: it names the address underneath the title and holds two separate boxes.
    Shipping Address — Delivery Instructions window
    Two boxes, each with its own badge: Delivery instructions — SAVED TO THIS LOCATION, and Comments for this order — THIS ORDER ONLY, with a character counter under each
  3. Type a standing note into the top box, Delivery instructions (badged SAVED TO THIS LOCATION) — for example "Ring the bell at the loading dock; leave with the front desk if closed." Watch the counter under the box tick up towards its limit.
  4. Type something different into the lower box, Comments for this order (badged THIS ORDER ONLY) — for example "Please deliver before noon this week."
  5. Click Save.
  6. Confirm the window closes and your standing note now shows in the grey strip on that location's card, without reloading the page.
    Shipping Address — note saved on the card
    The saved standing instruction appears straight away in the grey strip under the address, and the note icon stays tinted
  7. Reopen the same window and confirm your standing note is still in the top box — it was saved to the address, not just displayed.
Expected result
  • The window offers two clearly labelled boxes: one saved to the address, one attached to this order only.
  • Saving closes the window and the standing note appears on the card immediately.
  • Reopening the window shows the standing note still there.
Result:
Scenario 5 · ~5 min SQL2-31

The instructions follow the order all the way through

Not run

What you're checking: what you typed in Scenario 4 reaches the order itself — visible on the final review, on the confirmation, and on the order page afterwards — so nobody has to re-key it or phone it in.

  1. Continue from Shipping Address, with the location you added the note to still selected.
  2. On Confirm Order & Submit, look under the address in the Shipping Address card: a DELIVERY INSTRUCTIONS box repeats your standing note word for word, above the map.
    Confirm Order & Submit — delivery instructions
    The DELIVERY INSTRUCTIONS box sits between the street address and the map, repeating what you saved
  3. Click Place Order and wait for the Submitted screen.
  4. Scroll to the bottom of the Submitted screen and confirm Shipping Details shows the same address and a Delivery Instructions section with your wording.
  5. Go to My Order History — the back arrow, ‹ Order Supplies, then the My Order History tile — open the order you just placed, and confirm the Shipping card names the same location, address and ship-to contact.
  6. Cleanup: if you'd rather not leave your test wording on a shared address, reopen the Delivery Instructions window from any new order and set the standing note back to what it said before.
Expected result
  • Your standing note appears, unchanged, on Confirm and again on the Submitted screen.
  • The finished order's Shipping card carries the same location and address you chose.
  • You never had to retype the instructions at any point in the order.
Result:
All modules PA6

Reordering

Not started

Why you're testing this

Most supply orders are last month's order again. This module follows that path end to end: open a finished order, copy it into a fresh draft, then change your mind about it — bump a quantity, drop a line you don't need, send it somewhere else, add a note for the courier — and place it. You asked after the last round to be able to edit the comments, the location and the quantities on a reorder, and to be able to take a line off without starting over; both are in this module.

Full story & acceptance criteria

SQL2-81 — "As a Provider Portal User, I want to start a new order by cloning a past order and adjust items, so that I save time on common reorders." I can choose a past order to create a new draft with the same items; I can remove items and change quantities before submitting; I receive a confirmation after I submit the reorder.

SQL2-94 — the Marketing-feedback pass that shaped these screens: the order-entry step was removed, draft-resume logic added, the unit moved next to the quantity, the facility auto-selected from your portal login, and a Reorder action added with explicit save-as-draft controls.

SQL2-185 — "There was no way to remove an item once I reached the Review screen." A Remove control now sits on every line of the Review step, with a two-click confirm so nothing disappears by accident.

SQL2-195 — the old guide called the button "Recent Order". It never existed. The real labels are Reorder, Resume Order and View Order — this module uses those.

SQL2-197 — "I want to edit the comments, the location and the quantities when I reorder." All three are editable on the cloned draft before you place it.

Scenario 1 · ~5 min SQL2-195 SQL2-81

Find the way back into a finished order

Updated from your feedback Not run

What you're checking: that a finished order offers View Order and an unfinished one offers Resume Order — and that View Order is where the Reorder button lives. The old guide called this a "Recent Order" button; that wording was wrong and has been corrected.

  1. Open My Order History — the middle tile on Client Supplies.
  2. Click the Completed tab and pick any order in the list to open it. A completed order is one whose chip reads Approved, In Fulfillment or Shipped.
  3. Look below the Order Progress trail for the two buttons: View Order and Submit an Order Inquiry. On a finished order the first button says View Order — not Resume Order, and not "Recent Order".
  4. Go back to My Order History — the back arrow beside the order number — open the Drafts tab and open one that you started yourself. The same button now reads Resume Order, because that order is still yours to finish. A draft a colleague started shows a note where the button would be — "[their name] started this draft. Only they can finish it." If the Drafts tab is empty, make one: open Order Supplies from Client Supplies, add a single item, click Continue to Review and then Save Draft, then come back to My Order History and it will be waiting for you.
    Order page — a draft order
    The same slot carries Resume Order on a draft; on a finished order it reads View Order
  5. Return to the completed order and click View Order. A full-screen window opens over the page showing Order Submitted Successfully!, your order number, the status trail and a row of four buttons.
    View Order — the order's confirmation screen
    The four actions along the bottom: Place New Order, Reorder, View Order Details, Submit an Order Inquiry
  6. Confirm you can see the Reorder button in that row. That is the entry point for everything else in this module.
Expected result
  • A finished order offers View Order; a draft offers Resume Order. Neither is ever labelled "Recent Order".
  • View Order re-opens the order's own confirmation screen in a window over the order page.
  • That screen carries a Reorder button alongside Place New Order, View Order Details and Submit an Order Inquiry.
Result:
Scenario 2 · ~6 min SQL2-81

Copy a past order into a fresh draft

Not run

What you're checking: that the Reorder window shows you exactly what is about to be copied before it copies anything, and that saying yes produces a brand-new draft — leaving the original order untouched.

  1. From the View Order window you opened in Scenario 1, click Reorder.
  2. Read the window that opens: the heading is Reorder, with the line "Review the details below before creating your draft order".
    Reorder — the preview window
    ORDER OVERVIEW names the original order, the client and the shipping location; ORDER ITEMS lists every line with its quantity and unit
  3. Check the ORDER OVERVIEW block names three things: ORIGINAL ORDER (the number you came from), CLIENT and SHIPPING LOCATION.
  4. Check the ORDER ITEMS block: the count in the heading matches the number of rows, and each row shows the product photo, its name, its supply number, a Qty: and a UOM: — the unit the item is ordered in.
  5. Read the blue note near the bottom: "Reordering will create a new draft order with the same items and settings. You can modify it before submitting." That sentence is the promise the rest of this module tests.
  6. Click Cancel once, to prove nothing happens when you back out. Re-open Reorder.
  7. Click Create Draft Order and wait. The button is copying the order and its lines while you wait, so give it a few seconds.
  8. Read the window: it shows the original order's confirmation again, now with a teal Draft Order Created banner — "Your items were copied into a new draft order — it has not been submitted yet." — and a Review Draft Order button.
    Reorder — Draft Order Created
    The copy is made but not placed: the banner says so, and Review Draft Order is the way into the new draft
  9. Click Review Draft Order. The page changes to the new draft's own order page: its number in the heading, a yellow Draft tag and a Resume Order button. Note the new draft's number from that heading — you'll need it for the next scenarios. It is a different number from the order you copied; if you miss it, it is at the top of the Drafts tab in My Order History (newest first).
  10. Click Resume Order. The wizard opens on Review Order (step 2 of the trail) carrying the same items as the original, with Save Changes at the top-right — the sign that you are editing a draft that already exists.
  11. Confirm the original order is still sitting untouched in My Order History with its own number and status.
Expected result
  • The Reorder window previews the original order, the client, the shipping location and every line with quantity and unit before anything is created.
  • Cancel leaves everything as it was.
  • Create Draft Order produces a new draft with the same items — announced by the Draft Order Created banner — and Review Draft Order takes you to the new draft's order page, where Resume Order opens it on Review Order, ready to edit.
  • The original order is unchanged.
Result:
Scenario 3 · ~7 min SQL2-197 SQL2-185

Change a quantity and take a line off the order

Updated from your feedback Not run

What you're checking: the copied draft is genuinely editable — quantities can be changed and a whole line can be dropped without backing out to the catalogue. The Remove control is new since your last round, and it deliberately asks twice.

  1. Start on the Review Order step of the draft you created in Scenario 2. If you closed the window, open My Order History, find that draft, open it and click Resume Order — it comes straight back to the step you left.
  2. Look at one line: it shows the product, a UNIT chip, a QTY box, a red Remove, and a SUPPLY LIMIT panel with an ALLOWED number and a How is this calculated? link. That panel is badged Within Your Limit on the four supplies that carry usage history for this client, and Limit Estimated on any other supply. The ALLOWED figure is three times the client's recorded usage over the last 90 days, less what has already been ordered in that window — so it differs from line to line and shrinks as the client orders. Nothing else about the check changes.
  3. Change the QTY box on that line from 1 to 3 and click elsewhere on the page. Keep the number under the line's ALLOWED figure — this scenario is about editing a draft, not about supply limits, and a quantity over the allowance will ask you for a justification before you can go on.
  4. Watch the Order Summary panel on the right: Total Quantity goes up to match, without any page reload — and a green Auto-saved toast names the draft that just kept the change.
    Review Order — a reordered draft
    Each line carries UNIT, QTY, Remove and its own supply-limit panel; the Order Summary on the right keeps count
  5. Click Remove on a different line — one you want gone. Nothing is removed yet: the button changes to Confirm?.
    Review Order — Remove armed
    One click arms the control and it reads Confirm?; it disarms itself after about four seconds if you walk away
  6. Wait a few seconds without clicking. The button quietly goes back to Remove on its own — that's the safety catch, not a fault.
  7. Click Remove again, then click Confirm? while it is still armed.
  8. Confirm the line disappears, the Order Items count drops by one, and the Order Summary totals follow.
    Review Order — after removing a line
    The line is gone and both the Order Items count and the Order Summary totals have been recalculated
Expected result
  • Quantities can be edited straight on the Review step and the Order Summary keeps up live.
  • Remove takes two clicks: the first arms it as Confirm?, the second removes the line.
  • The armed state disarms itself after a few seconds if you do nothing.
  • Removing a line updates the item count and totals immediately, with no page reload.
Result:
Scenario 4 · ~3 min SQL2-185

The last line can't be removed

Updated from your feedback Not run

What you're checking: that Remove stops short of leaving you with an order that has nothing in it, and tells you what to do instead. Try to break it on purpose.

  1. Keep removing lines on the Review step until only one line is left. The Order Items heading should read 1 items.
  2. Click Remove on that final line.
  3. Read the red panel that appears in the top-right corner: Validation Error — "An order needs at least one item. If you no longer need this order, you can leave it as a draft; drafts are never sent."
    Review Order — removing the only line
    The last line is protected: a red Validation Error appears and the line stays where it is
  4. Confirm the line is still there and the button never went to Confirm? — the check happens before the control is even armed.
  5. Dismiss the message with the × on the red panel and carry on with your order.
Expected result
  • An order can never be emptied from the Review step.
  • The message names the rule and points at the right alternative (leave it as a draft — drafts are never sent) rather than just refusing.
  • The single remaining line is untouched.
Result:
Scenario 5 · ~7 min SQL2-197

Send it somewhere else, with a note for this delivery only

Updated from your feedback Not run

What you're checking: the copied order isn't locked to the original address. You can redirect it and attach a comment that belongs to this delivery alone — without changing the standing instructions the site keeps for that location.

  1. From the Review step, click Continue at the top-right to reach Shipping Address. If Continue is greyed out, it is not the contact — SHIP TO CONTACT on the right of the Review step is filled in with your name and locked. A line is over its allowance: the amber n item(s) need justification button beside Continue says so, and the quantity you raised in Scenario 3 is the usual cause. Lower it, or give a reason (module PA11).
  2. Read the DELIVERING TO: line — it names the location the order was copied with.
  3. Click a different location card in the list. The DELIVERING TO: line changes to the new one straight away.
    Shipping Address — a different location chosen
    Picking another card re-points the order; the DELIVERING TO: summary updates with it
  4. Click the middle of the three small icon buttons on that card — hovering it shows Add delivery instructions or Edit delivery instructions.
  5. Look at the two boxes in the window that opens. The top one, Delivery instructions, is tagged Saved to this location — it belongs to the address and every future order to it. The lower one, Comments for this order, is tagged This order only.
  6. Type into Comments for this order only, for example "Please deliver before noon and call the front desk on arrival." Watch the character counter beneath it — both boxes stop at 109 characters. Leave the top box alone.
  7. Click Save, then Continue to reach Confirm Order & Submit.
  8. Confirm the Shipping Address panel shows the new location, a map of it, and the two notes on separate lines: DELIVERY INSTRUCTIONS (the location's own) and ORDER COMMENTS (the one you just typed).
    Confirm Order & Submit
    The two notes stay separate: the location's standing DELIVERY INSTRUCTIONS and this order's ORDER COMMENTS
Expected result
  • A reordered draft can be redirected to any of your locations; the DELIVERING TO summary follows.
  • The instructions window offers two clearly-labelled boxes — one saved to the location, one for this order only.
  • Both boxes cap at 109 characters with a live counter.
  • The Confirm step shows the new address, its map, and the two notes separately.
Result:
Scenario 6 · ~4 min SQL2-81

Place the reorder and see your changes stuck

Not run

What you're checking: that everything you changed along the way — the quantity, the removed line, the new address, the comment — is what actually gets placed, and that you get a confirmation with its own order number.

  1. On the Confirm Order & Submit step, read the Order Summary on the right: Products should match the number of lines you kept, and Total Quantity should include the quantity you raised.
  2. Click Place Order and wait a few seconds.
  3. Confirm you land on Order Submitted Successfully! with a new order number — different from the one you copied.
    The reorder, placed
    The confirmation carries the new order number, the new shipping address, and both notes — Delivery Instructions and Order Comments
  4. Scroll the confirmation to the Order Summary block and check Shipping Details shows the location you switched to, with Delivery Instructions and Order Comments beneath it.
  5. Close the window and look at the order page behind it: the Items on this Order card lists only the lines you kept, at the quantities you set, and the Shipping card names the new location.
  6. Open My Order History — the back arrow beside the order number takes you there — and confirm the new order is at the top of the list, and the order you copied from is still there, unchanged, further down.
Expected result
  • The reorder is placed as its own order with its own number.
  • Every edit survives: quantity, removed line, shipping location, order comments.
  • The original order is untouched and both appear in My Order History.
Result:
All modules PA7

My Order History & the order page

Not started

Why you're testing this

This is the part of the portal that was rebuilt hardest after your last round. You told us the order list didn't show what was in an order, that recurring orders were a mystery box, and that you couldn't see items or quantities from the status screen. So: the list now searches, filters and pages; every row says what's in the order; recurring plans open up to show the deliveries they've produced; and the order page itself now carries the items with their photos and units, the shipping address on a map, and — where there was one — the reason a decision went the way it did.

Full story & acceptance criteria

SQL2-29 — "As a Provider Portal User, I want to see my order's current status and last updated time in the portal, so that I always know where my order stands." I can see the current status and when it was last updated; status changes from fulfilment appear within the agreed window; I cannot view orders from other organisations.

SQL2-30 — "As a Provider Portal User, I want to see a simple history of key order events, so that I understand how the order progressed." I can view a short history of key events such as submitted, approved and shipped; duplicate events are not shown twice; each event shows when it happened.

SQL2-196 — "I want to see the items and quantities on the Order Path screen." The whole order page and the My Order History list were reworked: item cards with photos, units and quantities, details, shipping with a map, order history, and a searchable, tabbed, paged list.

SQL2-199 — "Recurring orders are a mystery box." Recurring plans now have their own tab, show their schedule and next delivery, and expand to list every order they have generated.

SQL2-195 — the wording fix: finished orders show View Order, unfinished ones show Resume Order.

Scenario 1 · ~6 min SQL2-196

Read the list: what's in each order, at a glance

Updated from your feedback Not run

What you're checking: that a row tells you what the order actually contains without opening it, and that the tabs across the top slice the list the way you'd expect.

  1. Click the My Order History tile on Client Supplies. When a practice has more orders than the list holds, a line under the tabs says so — "Only your most recent orders are listed: n of n. To find an older order, type its number in the search box." — and typing the number finds it.
    My Order History
    Search at the top, six counted tabs beneath it, the line that says when only the most recent orders are listed, one row per order, and a right-hand rail with Create Order and an At a glance summary
  2. Read one row from left to right: Order and its number, a coloured status chip, then a plain-English line such as "2 items · 2 units — PIPET TRANSFER W/GRADUATIONS, FORM IRREPLACEABLE SPECIMEN LOG". Where an order has more products than fit, the line ends with +n more. The date it was created sits on the right.
  3. Find a row whose chip reads In Review. That's an order sitting with our team — in the system it's called "In Progress", and the list deliberately says In Review because that's what it means for you.
  4. Click each tab in turn — All, Drafts, In Review, Completed, Denied, Recurring — and confirm the number printed on the tab matches the number of rows you get. If a tab holds more than ten orders, its count is the total across all pages, not the ten you can see. Check the footer line — "Showing 1–10 of n orders" — to reconcile them.
  5. Compare the tab counts with the At a glance card in the right-hand rail: Awaiting review should match the In Review tab, and Drafts to finish should match the Drafts tab.
  6. Click anywhere on a row — the whole row is the link — and confirm it opens that order's page. Use the back arrow at the top-left, beside the order number, to come back.
Expected result
  • Every row states the order number, its status, how many items and units it holds, and which products, without being opened.
  • The six tabs each carry a live count and filter the list to match.
  • "In Review" is the client-facing wording for an order under our team's review.
  • Clicking a row opens the order; the back arrow beside the order number brings you back.
Result:
Scenario 2 · ~5 min SQL2-196

Find one order among hundreds

Updated from your feedback Not run

What you're checking: the search box and the page numbers, and that they behave sensibly together — including when a search finds nothing.

  1. On My Order History, note the footer line at the bottom-left: Showing 1–10 of n orders. Ten rows per page is the rule.
  2. Click the 2 in the page numbers at the bottom-right. The footer changes to Showing 11–20 and the rows change with it.
    My Order History — page two
    The footer counts you through the list; the arrows step one page at a time and grey out at either end
  3. Use the ‹ and › arrows either side of the numbers to step back and forward. On page one the left arrow is greyed out; on the last page the right one is.
  4. Copy an order number you can see, then type the last four digits of it into Search by order number… at the top.
  5. Confirm the list narrows as you type, with no button to press, and the footer becomes Showing 1–1 of 1 order. The search looks through all of your orders, not only the listed ones: a line reading "Searching all your orders…" may show for a moment, and when more orders match than can be shown it reads "More orders match than are shown here. Type more of the order number to narrow the search."
    My Order History — searching by order number
    Search matches on the order number and the footer recounts to match
  6. Type nonsense such as zzzz into the search box. The list empties and reads No orders match this filter. — not a blank panel.
  7. Clear the search box and confirm the full list and the page numbers come back.
  8. Try one combination: pick the Completed tab, then search for a draft's number. You should get the empty-state message, because the search only looks inside the tab you're on.
Expected result
  • Ten orders per page, with a footer that always states which slice you're looking at.
  • Page numbers and arrows move through the list; the arrows disable at the ends.
  • Search filters live on the order number and works inside the selected tab.
  • A search with no matches shows a written message, not an empty box.
Result:
Scenario 3 · ~7 min SQL2-199

Open the recurring mystery box

Updated from your feedback Not run

What you're checking: that a recurring plan now says what it contains, how often it runs, when it next runs, and — the part that was missing — which orders it has already produced for you.

  1. Open My Order History and click the Recurring tab. Every row here is a recurring plan, not a delivery.
    My Order History — the Recurring tab
    Each plan shows a Recurring · Active style chip, its item count and schedule, its next delivery date, and a pill counting the deliveries it has made
  2. Read a row: the chip pairs the word Recurring with the plan's own state — Active, Paused, Cancelled or Completed. Underneath sits "n items · Monthly" (or Weekly, Daily, Bi-Weekly) and, for a live plan, — next delivery and a date. Plans that are paused, were cancelled or have finished their run stay in this tab on purpose: it is not a list of live plans only. The tab holds your most recent plans, and an older one is found by typing its number in the search box. For the rest of this scenario pick one whose chip says Recurring · Active and whose delivery pill shows more than zero.
  3. Click the n deliveries pill on that row — the pill itself, not the row.
  4. Confirm a panel slides open underneath listing the orders the plan has generated: each one with its own order number, its own status chip and its own date.
    Recurring plan — deliveries expanded
    The plan's generated orders, newest first, each with its own number, status and date — and each one clickable
  5. Look at the mix of statuses in that panel. Deliveries created since the automatic-submission change go through the same review as an order you place yourself, so you may see Approved, In Review and Denied side by side. Older ones may sit at Draft.
  6. Click one of the deliveries. It opens as an ordinary order page.
  7. Go back to My Order History and switch to the All tab. Find that same delivery in the list and confirm it carries a small from 000… chip naming the plan it came from — so you can always trace a delivery back to its plan.
  8. Collapse the deliveries panel by clicking the pill again.
Expected result
  • The Recurring tab lists plans with their state, contents, schedule and next delivery date.
  • The deliveries pill expands to show every order the plan has produced, each with status and date.
  • A generated order opens like any other and carries a "from" chip naming its plan.
  • Nothing about a recurring plan is hidden any more.
Result:
Scenario 4 · ~7 min SQL2-29 SQL2-196

The order page: items, units, address and a map

Updated from your feedback Not run

What you're checking: that one screen answers every ordinary question about an order — what's on it, in what unit, where it's going and where it's got to. This is the screen you asked to have the items and quantities added to.

  1. Open any completed order from My Order History.
  2. Read the top: the order number, a status chip beside it, your practice's name underneath, and an Order Progress card showing the whole path — Draft, In Progress, Approved, In Fulfillment, Shipped, Denied, Canceled — with the current step filled in and a Last Updated stamp on the right.
    Order page — a completed order
    Order Progress with the current step filled and a Last Updated stamp, then Items on this Order with photos, supply numbers, unit chips and quantities
  3. Check the Items on this Order card. Its subtitle counts the order ("2 items · 2 units"), and each line carries the product photo, its name, its # supply number, a small unit chip such as Case or Box, and a Qty pill.
  4. Compare those quantities against the confirmation you were given when the order was placed — they must agree.
  5. Scroll down to the Details card (Client, Order Date, Created, Status) and then the Shipping card.
  6. Confirm Shipping names the Location, spells out the full Address, names the Ship To Contact, and draws a map with a pin on that address.
    Order page — Details and Shipping
    The Shipping card puts the address on a map; Order History keeps the event log in the right-hand rail
  7. Look at the Order History card in the right-hand rail: a short, dated list of what happened — Created, then each status change written as Draft → Approved. Confirm no event is listed twice.
  8. Open one of your own Draft orders from the Drafts tab and compare. The Items card there adds the words "draft contents, may change until the order is placed" — an honest warning that nothing is final yet — and the button at the top reads Resume Order instead of View Order.
    Order page — a draft
    A draft says so: Resume Order at the top and "draft contents, may change until the order is placed" on the items card
Expected result
  • The order page shows status, last-updated time and the full progress path.
  • Items are listed with photo, supply number, unit and quantity — matching what was placed.
  • Shipping gives the location, full address, ship-to contact and a map.
  • Order History lists key events with times and no duplicates.
  • Drafts are clearly marked as provisional and offer Resume Order.
Result:
Scenario 5 · ~4 min SQL2-196

Why an order was turned down

Updated from your feedback Not run

What you're checking: that an order which didn't go straight through explains itself on its own page, in words rather than codes.

  1. Open My Order History and find an order whose chip reads Denied. The Recurring tab is a good hunting ground: expand a plan's deliveries and pick a denied one. Denied orders are scarcer than they were. An order only reaches review when a line is over its allowance, and it only becomes Denied once the reviewer turns it down. If nothing in your list reads Denied, make one rather than skipping the scenario: place an order for PIPET TRANSFER W/GRADUATIONS (supply 900010) with a quantity of more than double what ALLOWED reads for it on the Review step, write any sentence when it asks you to justify the overage, and place it. It will sit at In Review; ask the account manager who owns this client's record to deny it, and come straight back with that order. Whoever runs the internal track can tell you who that is — in Salesforce it is Client Owner on the client's Details tab. They have an hour to act before the order releases itself.
  2. Open it and look for the Review Decision panel, sitting between the items and the details. On a denied order it is outlined in red.
    Order page — a denied order
    The red Review Decision panel gives one standard message and points to View Order for the supplies that were over your limit
  3. Read the message. It should be a sentence you can act on, not a code or a status name. On a denied order it reads: "This order exceeds the agreed monthly allocation for this site. Please raise a separate request with your Account Manager if the volume is permanent." When the reviewer wrote a comment of their own, it appears under the message as Comment from your Account Manager (orders reviewed before 23 September have none). The last line points to View Order, which shows each supply's allowance and how far over it was.
  4. Confirm the status chip at the top, the Status row in Details, and the last entry in Order History all agree that the order was denied, and that the history shows when.
  5. Open an order that went straight through instead. If every line stayed within its allowance there is no panel at all — there was nothing to explain. If it carries an amber panel reading "New client — no utilization history to evaluate against", the supply had no usage history for this client and the engine used the standard 50 — the panel reporting that honestly, which is not a claim that we don't know your practice, and not a failure. The panel reports the decision for the order as a whole. How each individual line was judged, and the supply-allowance maths behind it, are covered in the compliance modules.
  6. Note in your comments the exact wording of any reason you see — the phrasing is being reviewed and yours is the vote that counts.
Expected result
  • Any order that was reviewed shows a Review Decision panel with one plain-English message (red when nothing shipped, amber when part of the order changed or it is still in review, green when it was approved in full), plus the reviewer's comment when they wrote one.
  • The reason, the status chip, the Details status and the Order History all agree.
  • An order that was reviewed, denied, or fell back to the standard 50 carries the panel; an order that stayed within its allowance does not.
Result:
Scenario 6 · ~4 min SQL2-199

The recurring reminder inside the wizard

Not run

What you're checking: that while you're building a new order the portal reminds you what is already scheduled to arrive, so you don't order it twice — and that the reminder agrees with what the Recurring tab shows.

  1. Open Order Supplies from Client Supplies and wait for the product list to appear.
  2. Read the teal band near the top: ACTIVE RECURRING ORDERS — You have n active recurring orders scheduled. Click to view details.
  3. Write down that number, then open My Order History → Recurring in another look and count the rows whose chip says Recurring · Active. The two numbers measure different things and will usually differ. The banner counts only the plans that are Active and not paused. The Recurring tab lists your plans whatever their state — Active, Paused, Cancelled and Completed together — so its tab count is normally the larger of the two. What you're checking is that the banner's number matches the Active ones specifically.
  4. Click the banner (or the View details & items link on it) and confirm a panel headed Active Recurring Orders opens. Each plan in it is listed with its number, its schedule, SHIPPING TO, NEXT GENERATION DATE, start and end dates, and SCHEDULED ITEMS with quantities and units.
    Order Supplies — Active Recurring Orders panel
    Every active plan, what it ships, where and when — opened from the banner without leaving the order you're building
  5. Close the panel, add an item and click Continue to Review. The same banner follows you onto the Review step — the reminder is there at the last moment before you commit.
  6. Look for a second, amber band on Review reading "You may have already ordered some of these items recently (n recent orders). Click to review." If it appears, click it and check the orders it lists really do contain what you're about to order again. This amber band only appears when the same items were ordered in the last 7 days. If your practice hasn't ordered them inside that window there is nothing to warn you about and no band — that's correct behaviour, not a miss.
Expected result
  • The wizard states how many active recurring plans your practice has, on both Select Items and Review.
  • That number counts active, unpaused plans — matching the Active rows in the Recurring tab.
  • The banner opens a panel naming those plans and the items they deliver.
  • Where the cart repeats a recent order, a second warning offers those orders for review.
Result:
All modules PA8

Support requests & notifications

Not started

Why you're testing this

When something about an order isn't right, you should be able to ask about it from the order itself and then watch the answer arrive in the same place — no phone tag, no wondering whether anyone picked it up. Two things you raised last round are fixed here: the request is now firmly attached to the order it came from, and the portal now tells you where the request stands — Inquiry open while we're on it, Inquiry answered once there's a reply waiting, with the reply printed on the order page.

Full story & acceptance criteria

SQL2-27 — "As a Provider Portal User, I want to create a support request from an order and track it in the portal, so that issues are handled quickly and transparently." From an order I can raise a request and the form already knows my order details; I get a confirmation that it was received; I can see the request's current status.

SQL2-66 — "As a Provider Portal User, I want to receive email and portal notifications on key order changes, so that I stay informed without constant checking." Messages include the order number, the status and simple next steps.

SQL2-182 — "The case wasn't linked to the order." Raising an inquiry now stamps the related order, the practice and the contact onto the case automatically, and types it as a supply-order inquiry — so there's no category for you to guess at.

SQL2-202 — "Where do I see the status of my case?" Orders now carry an Inquiry open or Inquiry answered tag in My Order History, a Support case card on the order page, and the team's reply printed under Response from our team.

Scenario 1 · ~6 min SQL2-27 SQL2-182

Ask a question about an order

Updated from your feedback Not run

What you're checking: that raising a query takes two fields and no guesswork — the form already knows which order you're on, and there is no category for you to choose. You reported last round that a request came through unattached to its order; this is where that fix is proved.

  1. Open My Order History and open any order you want to ask about. Note its number.
  2. Click Submit an Order Inquiry — it sits beside View Order (or Resume Order) under the Order Progress card.
  3. Read the form that opens. The heading is Submit Order Inquiry and the line beneath it names your order: "Please fill out a brief bit of information about the issue you are facing with Order 000…".
    Submit Order Inquiry
    Two required fields and nothing else — Subject arrives pre-filled with your order number and there is no category to pick
  4. Check the Subject box: it is already filled in for you, reading "Supply Order 000… Inquiry". You can edit it — try adding a few words of your own, such as "— question about my delivery".
  5. Confirm there is no Type, Reason or Category picker anywhere on the form. Choosing one used to be your job; the system now types the request itself.
  6. Type a real-sounding question into Description, for example "When will this order arrive? I need the tubes before Friday."
  7. Click Next and wait a few seconds.
  8. Read the confirmation: "Case 015… has been created. Please reference this number if you contact us about this inquiry." Write that case number down — you'll match it in the next scenarios.
    Inquiry submitted
    The confirmation hands you the case number straight away, with a Close button to get back to the order
  9. Click Close to return to the order.
Expected result
  • The inquiry form is reachable from the order itself and names that order in its opening line.
  • Subject arrives pre-filled with the order number; Description is yours to write.
  • There is no category, type or reason for you to choose.
  • Submitting returns a case number immediately.
Result:
Scenario 2 · ~5 min SQL2-202

See that we've got it, without phoning anyone

Updated from your feedback Not run

What you're checking: that the request you just raised is visible from three places in the portal — the order page, the order list, and the summary card in the rail. This is the answer to "where is the status of my case?".

  1. Stay on the order you raised the inquiry from and reload the page.
  2. Look in the right-hand column for a Support case card. It shows a status chip, Case 015… matching the number you wrote down, the subject you typed, and the date it was Opened.
    Order page — Support case card, open
    Case number, your subject and the date it was opened, with the note "Our support team will reach out by email with any updates."
  3. Read the note at the bottom of the card: "Our support team will reach out by email with any updates." That's the promise while the case is open.
  4. Confirm the case number on the card is exactly the one the confirmation gave you, and that the subject names your order number — the request is attached to this order, not floating loose.
  5. Go back to My Order History — the back arrow beside the order number — and find that order's row — page through the list, or type its number into the search box, if it is not on the first page. It now carries a copper Inquiry open tag next to its status chip, followed by the case number (Inquiry open · Case …), so the order and its case are easy to match.
    My Order History — Inquiry open
    The copper Inquiry open tag rides alongside the status chip, so an outstanding question is visible from the list
  6. Check the At a glance card in the right-hand rail: Open inquiries counts the listed orders that have a question waiting, each order once, and should have gone up by one. It stays as it was when the order already had an open inquiry, or when the order is older than the list holds — the line under the tabs says when the list is not complete.
  7. Read the Question about an order? card below it — it explains the two tags in the same words this scenario just used.
  8. Scan the other rows in the list and confirm none of them picked up a tag. The tag belongs to one order only.
Expected result
  • The order page gains a Support case card naming the case, its subject and when it was opened.
  • The My Order History row for that order gains an Inquiry open tag.
  • The At a glance card counts open inquiries.
  • No other order is tagged.
Result:
Scenario 3 · ~6 min SQL2-202

Read the answer when it comes back

Updated from your feedback Not run

What you're checking: the other half of the loop — that once someone at Sonora Quest writes a reply, the portal switches the order from "we're on it" to "there's an answer waiting", and prints the answer where you'll find it.

  1. Ask whoever is running the internal half of this test to answer your case — they open it in Salesforce and fill in the Client Response field. The internal steps are in the Manage orders, cases & notifications module. Give them the case number you wrote down. It is the Client Response field that flips the portal — not closing the case, and not a note or an email. A case that is closed with no response written shows no tag at all.
  2. Go back to your order's page in the portal and reload it. Portal pages hold on to what they last loaded, so a reload is what makes the change appear.
  3. Confirm the Support case card has changed: the chip now reads Answered, and a second date row, Answered, has joined Opened.
    Order page — Support case card, answered
    The chip flips to Answered, an Answered date appears, and the reply is printed under Response from our team
  4. Read the block headed Response from our team. The reply is printed in full on the order page — you don't need an email to read it.
  5. Confirm the line "Our support team will reach out by email with any updates." has gone. It belongs to the waiting state only.
  6. Go back to My Order History and confirm the row's tag has changed colour and wording: the copper Inquiry open is now a green Inquiry answered.
    My Order History — Inquiry answered
    The tag is green and reads Inquiry answered once a reply is waiting on the order page
  7. Check At a glance once more: Open inquiries has gone down by one and Answered inquiries has appeared or gone up. Both count listed orders, each order once, so an order that still has another question open stays under Open inquiries.
Expected result
  • Writing the client response flips the order's tag from Inquiry open to Inquiry answered.
  • The Support case card shows an Answered chip, an Answered date and the reply in full.
  • The waiting-state note disappears once there's an answer.
  • The At a glance counts move to match.
Result:
Scenario 4 · ~5 min SQL2-66 SQL2-27

The other ways in, and the emails

Not run

What you're checking: that the inquiry route is available from wherever you happen to be, and that the portal's promise about emailing you actually holds. Have your email open before you start.

  1. Open a completed order and click View Order to bring up its confirmation screen.
  2. Confirm Submit an Order Inquiry is one of the four buttons on that screen too, alongside Place New Order, Reorder and View Order Details. Raising a question never means hunting for the right page.
  3. Raise a second inquiry from here about a different order, using the same two fields, and note its case number.
  4. Go to My Order History and confirm both orders now carry their own tag, each pointing at its own case — nothing has bled between them.
  5. Go back to Client Supplies and click the Knowledge Center tile to see the difference. It opens Sonora Quest's Support page: a general Contact customer support form — Subject, Description, your details and an Inquiry Type you have to choose yourself — for questions that aren't about a particular order. Confirm it is not the route you used above: an order question raised from the order itself needs no Inquiry Type and arrives already attached. That page belongs to Sonora Quest's own portal, not to the supply pages, so it keeps their header and a menu of its own; use your browser's Back button to come back to Client Supplies.
  6. Check the inbox for the email address shown on your Confirm screen under Ordering As. Order emails are sent when an order is received, when it goes under review and when a recurring order is turned down. Emails go to the address on your contact record, which is not always the address you log in with. If nothing arrives, check that address first, then your junk folder, then record what you found in the comments — the exact address and the time you placed the order — that detail is what lets us trace it.
  7. Note in your comments which emails arrived, how quickly, and whether the order number and status in them matched the portal.
Expected result
  • Submit an Order Inquiry is available from the order page and from the View Order confirmation screen.
  • Two inquiries on two orders stay separate, each with its own case and tag.
  • Order emails arrive at the address on your contact record and name the order and its status.
Result:
All modules PA9

The full journey — place a real order

Not started

Why you're testing this

Every other portal module takes one piece of the ordering flow apart. This one puts it back together and drives it once, properly, from an empty cart to an order sitting in your list with a number on it. Do this module last. Do it slowly, the way a practice manager would on a Monday morning — and if anything here feels awkward, this is the module to say so in, because this is the journey every single client will make.

Full story & acceptance criteria

SQL2-24 — "As a Provider Portal User, I want a step-based order wizard framework and navigation design, so that I move through ordering with clear progress." The wizard shows clear steps; I can move forward and back without losing progress; empty, loading and error states are easy to understand.

SQL2-25 — "As a Provider Portal User, I want a product selection and cart experience, so that I can add multiple items and adjust quantities easily." I can add and remove items and see totals update immediately; my selections are remembered between steps.

SQL2-29 — "As a Provider Portal User, I want to see my order's current status and last updated time in the portal, so that I always know where my order stands."

SQL2-66 — "As a Provider Portal User, I want to receive email and portal notifications on key order changes, so that I stay informed without constant checking." Messages include the order number, the status and simple next steps.

Scenario 1 · ~8 min SQL2-25 SQL2-24

Build a real order

Not run

What you're checking: that you can walk into the portal cold and put together a genuine week's supply order without help, a manual, or a phone call.

  1. Click the Order Supplies tile on Client Supplies and wait for the catalogue to appear. The step trail across the top reads 1 Select Items → 2 Review Order → 3 Shipping Address → 4 Confirm → 5 Submitted.
    Order Supplies — Select Items
    Your practice is already chosen under CLIENT / FACILITY; the count above the list tells you how many products you can order
  2. Check the CLIENT / FACILITY box in the Filters panel — it already names your practice. You never have to pick it.
  3. Order like it's real: use Search Products and the Category list to find three or four supplies you would genuinely order, and add each with Add to Cart.
  4. Set a sensible quantity on each — a fortnight's worth, not 1 — using the QTY box on the row. Note the UNIT chip beside it: a quantity of 2 means two of that unit, whether that's two boxes or two cases. Keep each one inside what the next screen says your practice is ALLOWED: the four supplies with usage history carry their own live figure — large for the Zebra labels (supply 10750), small for 40274, 900005 and 900010, and down to 0 once earlier orders have used it up (the table under Before you start shows how to read it) — and every other supply gets the standard 50. Anything already ordered in the last 90 days comes off the same number. Above what is left you will trip the supply limit on the next screen and be asked for a justification, which modules PA10 and PA11 cover deliberately.
  5. Watch the Your Cart panel at the bottom of the left-hand column and the Items in Cart counter at the top keep up as you go.
    Select Items — items in the cart
    Added rows carry an In Cart badge and swap Add to Cart for a UNIT chip, a QTY box and Remove
  6. Change your mind once: remove one of the products with Remove and add a different one instead. The counter and the cart follow immediately.
  7. Click Continue to Review.
Expected result
  • The catalogue opens already scoped to your practice.
  • Products can be found, added, re-quantified and removed with the cart keeping count throughout.
  • Each row states the unit the quantity is counted in.
  • Continue to Review is available as soon as there is something in the cart.
Result:
Scenario 2 · ~7 min SQL2-24

Review, address, and one last look

Not run

What you're checking: the three screens between "I've chosen things" and "I've committed" — that each one asks for exactly what it needs and shows you everything before the point of no return.

  1. On Review Your Order, read each line: the product, its UNIT, its QTY, a Remove, and a SUPPLY LIMIT panel showing what your practice is ALLOWED, with a How is this calculated? link if you want the reasoning. On the four feed-backed supplies the chip reads Within Your Limit and the number comes from your practice's real usage; a supply with no history reads Limit Estimated and falls back to 50. Modules PA10 and PA11 go into it properly.
    Review Your Order
    Every line carries its own supply-limit panel; the right-hand column holds Shipping Contact and a running Order Summary
  2. Read SHIP TO CONTACT in the right-hand column — it is marked with a red asterisk because it's required, and as a portal user it is already filled in with your own name and locked. There is nothing to choose. If Continue is greyed out, it is not the contact — that is set for you. A line is over its allowance, and the amber n item(s) need justification button beside Continue is telling you so; module PA11 covers what to do.
  3. Read the Order Summary panel in the right-hand column: it holds Total Items and Total Quantity. With every quantity inside your allowance that is all it holds — and there is nothing beside Continue but the button itself. A justification prompt only appears once a line goes over, which modules PA10 and PA11 cover deliberately.
  4. Click Continue to reach Shipping Address. Confirm the DELIVERING TO: summary names a location and that your usual one is marked Default.
    Shipping Address
    One card per location, each with its address, its standing delivery note and three small buttons — set as default, edit instructions, view map
  5. Click Continue again to reach Confirm Order & Submit.
  6. Check every panel on the Confirm screen against what you intended: the Shipping Address with its map, the Order Items with quantities and units, Ordering As with your name, email, phone and facility, and the Order Summary counting products and total quantity.
    Confirm Order & Submit
    The last screen before you commit shows the address on a map, every line, who is ordering and the totals
  7. Use Back to step to Review and then forward again, and confirm nothing was lost or reset on the way.
Expected result
  • Review shows each line with its unit, quantity and supply allowance, plus a running summary.
  • Ship-to contact is required and offers your own name.
  • Shipping Address defaults sensibly and shows all your locations.
  • Confirm restates the address, the items, the person ordering and the totals before you commit.
  • Going back and forward changes nothing.
Result:
Scenario 3 · ~5 min SQL2-24 SQL2-29

Place it

Not run

What you're checking: the moment that matters — that pressing the button leaves you in no doubt the order is placed, and tells you what happens next.

  1. Read the line beneath the Order Summary: "By placing this order, you confirm all details are correct."
  2. Click Place Order and wait. The order is being checked against your practice's supply allowance while you wait, so give it a few seconds.
  3. Confirm you land on Order Submitted Successfully! with "Your order has been received and is being processed." and your new ORDER NUMBER in a teal chip. Write the number down.
    Order Submitted Successfully
    The order number, the status trail showing where the order has landed, and four things you can do next
  4. Click the small copy icon inside the order-number chip and paste it somewhere to check it copied the number cleanly.
  5. Read the status trail beneath the number — Draft, In Progress, Approved, In Fulfillment, Shipped — and note which step is filled in. An order within your allowance lands on Approved; one that needs a look from our team stops at In Progress. Either outcome is a pass for this scenario — you're testing that the portal states clearly which one happened, not which one you got. The supply-allowance rules behind it have their own modules.
  6. Scroll the confirmation and check the Order Summary block: order number, order date, client and status, then Shipping Details with the address and any delivery instructions.
  7. Confirm the four buttons are there — Place New Order, Reorder, View Order Details, Submit an Order Inquiry — and the closing line "Need help with your order? Contact Support".
Expected result
  • Place Order produces an unambiguous confirmation with a new order number.
  • The order number can be copied with one click.
  • The status trail states where the order has landed and what it's waiting for.
  • The confirmation repeats the items, the totals and the shipping details, and offers the obvious next actions.
Result:
Scenario 4 · ~6 min SQL2-66 SQL2-29

Follow the order you just placed

Not run

What you're checking: that the order you just created behaves like a real record afterwards — findable, readable, and consistent with the confirmation you were given. Have your email open for this one.

  1. Leave the confirmation — click the back arrow, ‹ Order Supplies, at the top-left — and open My Order History from Client Supplies.
  2. Find your new order at the top of the list. Its row should carry today's date, the status you saw on the trail, and a summary line naming what you ordered.
    My Order History — the new order at the top
    Newest first: each row spells out its status and its contents, so the order you just placed is easy to find at the top
  3. Search for your order number in the search box to prove it can be found on purpose, not just by being recent. The search looks through all of your orders, so the same number still finds this order once it is too old to be listed.
  4. Open it and check the page against the confirmation you wrote down: same number, same status, same items at the same quantities and units, same shipping address on the map.
    The order's own page
    Everything the confirmation told you, now living on the order itself — with an Order History log building up in the rail
  5. Read the Order History card in the right-hand rail: it should show Created and the status change from Draft → whatever it landed on, each with a time.
  6. Check the inbox of the email address the Confirm screen showed you under Ordering As. You should receive an order notification naming the order number and its status — a received notice for an order that went straight through, or an under-review notice for one waiting on our team. Give it a few minutes and check the junk folder before recording a Fail — and note the exact address you checked and the time you placed the order, because that's what lets us trace a missing one. If the logo in the email looks broken but the words are all there, note it and pass the scenario; that's a known display quirk in some desktop mail clients, not a fault in the message.
  7. Finish by writing, in your own words, how the whole journey felt: anything you had to read twice, anything you expected to be able to do and couldn't, anything that would slow a busy practice down. This is the comment the team most wants.
Expected result
  • The order appears at the top of My Order History and can be found by searching its number.
  • Its page matches the confirmation exactly — number, status, items, quantities, units, address.
  • Order History logs the creation and the status change with times.
  • An email naming the order and its status arrives at the contact's address.
Result:
All modules PA10

An order inside the allowance

Not started

Why you're testing this

You have spent this whole track placing orders — from here on, the compliance engine is switched on around them. This is what Phase 2 adds to the same journey: every order is measured against a quantity the client is actually entitled to before it is allowed anywhere near Workday. Start with the case that should be invisible: an order that stays inside the allowance. The client should see their limit, see that they are under it, and get an approved order with nobody's day interrupted. If this module is noisy or confusing, the ones after it will be worse — so read the wording as a practice manager would and tell us what does not land.

Full story & acceptance criteria

SQL2-124 — Client Gate Logic. Every order line is measured against the client it belongs to. The client's Client Segment (POL, IOP or Global) and Client Number decide which allowance multiplier applies, and a client marked Compliance Exclusion skips the engine entirely.

SQL2-125 — Container-Based Entitlement Formula. The allowed quantity comes from the client's real lab usage over a lookback window, converted into orderable units and multiplied by their segment's allowance ratio.

SQL2-127 — Already-Issued Deduction Logic. "As a SonoraQuest team member, I want supplies that have already been shipped to a client to be automatically subtracted from their entitlement so the system prevents over-provisioning and reflects the real supply balance."

SQL2-142 — Real-Time Credit Balance Display (LWC). The client sees the allowance on the Review step while they are still editing quantities, not after they submit — with a plain-language breakdown of how it was worked out.

SQL2-144 — Server-Side Re-evaluation at Submit. Whatever the screen said, the engine runs again on the server at the moment of submission. That result is the one that counts and is what gets stamped on the order.

Scenario 1 · ~8 min SQL2-142 SQL2-127

See the supply limit while you are still choosing quantities

Not run

What you're checking: that the client is told what they are allowed before they commit — on the Review step, per product, in units they understand — and that the explanation behind the number holds up.

  1. Open Client Supplies, click the Order Supplies tile, and add one product to the cart with Add to Cart. Use LABEL ZEBRA FIELD ACCESSIONING (supply 10750) — its allowance is by far the largest of the four feed-backed supplies, so nothing you have ordered so far will get in the way.
  2. Click Continue to Review.
  3. Read the SUPPLY LIMIT block under the product. It carries a status chip, the word ALLOWED: and a number. With a small quantity in the box the chip should read Within Your Limit and there should be no warning. The portal reads the same usage feed as the internal view. For as long as your quantity stays inside the allowance the chip reads Within Your Limit. (Push a quantity past it and the chip changes to Overage — Needs Approval — that is module PA11's job, not this one.) The allowance is three times the client's recorded usage over the last 90 days, less whatever has already been ordered in that window. A supply with no usage history for the client falls back to a flat 50 units and shows Limit Estimated instead — that is the estimate at work, not a broken sum.
    Client Supplies — Review Order, inside the allowance
    Requesting 5 of LABEL ZEBRA FIELD ACCESSIONING against an allowance built from real usage, less what was already ordered — it read 2,987 on the day of this picture. The chip reads Within Your Limit, the SUPPLY LIMIT block sits with the product, not in a separate screen, and Continue is enabled
  4. Set the quantity in the QTY box to something comfortably below the allowed number and wait a moment. The limit block re-checks itself every time you change a quantity — it should stay quiet.
  5. Click How is this calculated? to open the breakdown.
    How Your Supply Limit Was Calculated
    Usage period, recorded usage, the segment's allowed portion, Already ordered deducted, and the resulting allowance — the whole formula in plain words
  6. Read every row of the breakdown and check it makes sense to you: Usage period (the lookback window, currently 90 days), Recorded usage, Converted to units, Allowed portion with a percentage, Already ordered shown as a deduction, Your allowance, and Your request. For 10750 the Recorded usage row is large — hundreds of draws a month — and Your allowance is three times that, less what has already been ordered. Only a supply with no history for this client shows 0 usage and the flat 50. The Allowed portion percentage is the client's segment ratio. Right now every segment — POL, IOP and Global — is set to 3.0 — three times measured usage (shown as 300% in the breakdown), a deliberately permissive cushion for go-live that Sonora Quest will dial down as real usage history builds up. It is set centrally, not per client, and internal admins can read the live values on the Compliance Configuration tab.
  7. Note what the Already ordered row does. It is the last 90 days of this client's orders for that product, subtracted in real time. Order the same product twice in a session and the allowance visibly shrinks the second time. Plan your testing around this — it is the single most confusing thing in Phase 2. The allowance is a balance, not a per-order cap. If you test the same product repeatedly its allowance drops toward zero and even a quantity of 1 will start reporting an overage. That is the deduction working correctly, not a bug. Use a different product for each scenario, and if a product's allowance has run down, say so in your comments rather than marking a Fail.
Expected result
  • Every product on the Review step shows a SUPPLY LIMIT block with an ALLOWED number.
  • A quantity below the allowance produces no warning and does not block Continue.
  • The breakdown explains the number in language a practice manager can follow, including the deduction for what has already been ordered.
  • Changing the quantity re-checks the limit without leaving the page.
Result:
Scenario 2 · ~7 min SQL2-144 SQL2-135

Place it — approved on the spot, no approval step

Not run

What you're checking: the happy path end to end. An order inside the allowance should be approved by the engine at the moment of submission, with no waiting, no reviewer and no interruption for the client.

  1. Carry on from Scenario 1: click Continue through the Shipping Address and Confirm steps.
  2. Click Place Order and wait for the Submitted screen.
  3. Read the Submitted screen. The status should read APPROVED and the order should carry its supply-limit chip and quantity. There should be no Pending Approval banner.
    Client Supplies — Submitted, approved immediately
    Status APPROVED straight away. Compare this with the same screen in module PA11, where an over-limit order lands on a Pending Approval banner instead
  4. Write down the order number. You need it for the email check below — and if your team also covers the internal track, the reviewers there will reuse it.
  5. Click View Order Details and check the order page. The Order Progress bar should show Approved, and there should be no Review Decision panel — every line stayed within its allowance, so there was nothing to explain. That panel appears only when the engine or a reviewer had something to say: an overage, a denial, or a supply with no usage history.
    Client Supplies — order page for an approved order
    Order Progress on Approved, the items you ordered, and no Review Decision panel — a within-allowance order needs no explanation. Compare this with the amber and red panels in modules PA7 and PA11
    If a Review Decision panel does appear here reading "New client — no utilization history to evaluate against", that is a normal, healthy answer, not an error. It means the supply had no measured usage for this client, so the engine used the standard allowance of 50 units per window, minus whatever had already been ordered. You will only see it on a supply outside the four feed-backed ones.
  6. Check the inbox of the ship-to contact within a few minutes. An order confirmation should arrive naming the order number. Order emails are sent without leaving an activity record behind, so a real inbox is the only place to see them — there is nothing to find inside Salesforce. Ask us to point your test contact at an address you can read before you start, and check the junk folder too.
  7. Look at the order internally. In Salesforce open the same order, go to the Details tab and scroll to the Compliance Status section. Compliance Status should read OK, Compliance Requires Approval should be unticked, and Last Compliance Evaluation should carry the time you pressed Place Order.
Expected result
  • The order is submitted without any approval step and lands on status Approved.
  • The portal order page shows Approved with no Review Decision panel (only the “New client” note if a supply has no usage history).
  • A confirmation email reaches the ship-to contact naming the order.
  • Internally the order carries Compliance Status OK and a timestamped evaluation.
Result:
Scenario 3 · ~5 min SQL2-124

Check the three client settings the engine reads

Not run

What you're checking: that the client record carries the settings the engine depends on, and that you can find them. Every allowance in this whole track is decided by these three fields — if they are wrong on a real client, every order for that client will be wrong.

  1. Open your test client record in Salesforce and go to the Details tab.
  2. Find the Compliance Information section and read the three fields in it: Client Number, Client Segment and Compliance Exclusion.
  3. Hover the help icon beside each one and confirm the help text explains what it does in language you could repeat to a colleague. Tell us if any of it is jargon.
  4. Check the segment matches the practice type. POL, IOP and Global each carry their own allowance cushion, and this is the field that decides which one applies. All three are currently set to the same 3.0, so changing the segment will not move an allowance in this environment — the field still has to be right, because the ratios will diverge once Sonora Quest tunes them. Note in your comments whether the segment on your test client is the one you would expect. These three fields can also be set on an individual ship-to location, and the location's value wins over the client's when both are filled in. That is deliberate — a single site can be given its own segment or be excluded without changing the whole practice.
  5. Note what Compliance Exclusion does: ticked, that client's orders skip the engine entirely and are never held for approval. Confirm it is unticked on your test client — if it is ticked, none of the rest of this track will produce an approval and you should tell us before continuing.
Expected result
  • Client Number, Client Segment and Compliance Exclusion are all visible on the client record with usable help text.
  • Compliance Exclusion is unticked on your test client, so the engine applies.
  • You can say which segment your test client is on, and that all three segments currently carry the same 3.0 cushion.
Result:
All modules PA11

Asking for more than the allowance

Not started

Why you're testing this

Practices will ask for more than their allowance, and they will usually have a good reason. The design decision here was to let them — but to make the overage visible, make them say why, and route the order to their account manager rather than bouncing it. This module is the client's half of that: what they see, what they are asked for, and what they are told happens next. It is also the place where a bad sentence does the most damage, so read the wording carefully.

Full story & acceptance criteria

SQL2-142 — Real-Time Credit Balance Display (LWC). The allowance, the overage and the cost of the overage are shown against the product on the Review step, live, as quantities change.

SQL2-143 — Justification Prompt and Capture (LWC). "Every line the engine flagged for justification must have one before the order can move on." The client picks a reason category, and a free-text box appears when they choose Other. The reason is stored on the order line and shown to the approver.

SQL2-128 — Cost-Delta / Cut-Percentage Decision Ladder. Not every overage is treated the same. The engine walks a five-rung ladder — inside the allowance, tiny-and-cheap, over the per-line cost ceiling, a shallow cut, a deep cut — and the first rung that matches decides the line.

SQL2-135 — Order-Level Status Aggregation. One problematic line sets the status of the whole order; orders are never split.

SQL2-144 — Server-Side Re-evaluation at Submit. The engine re-runs on the server at submission, and its answer is what gets stamped.

Scenario 1 · ~8 min SQL2-142 SQL2-128

Push a quantity over the limit and watch the panel change

Not run

What you're checking: that going over is unmistakable — the chip changes, the size of the overage is spelled out in units, and the client is told what will happen rather than just being stopped.

  1. Start a new order from Client Supplies, add PIPET TRANSFER W/GRADUATIONS (supply 900010) — one of the four feed-backed supplies — and click Continue to Review. Note the ALLOWED number. It is built from this client's real usage: three times what was recorded over the last 90 days, less anything already ordered in that time, and badged Within Your Limit while your quantity is inside it. Work from the number on your screen, whatever it is — if it reads 0, use another of the four supplies listed under Before you start, so that you can come back under the limit later in this scenario.
  2. Type a quantity of more than double the allowance into the QTY box and click away from it. Give the page a few seconds — it re-checks with the engine on every change.
  3. Read the SUPPLY LIMIT block now. Three things should have changed at once: the chip reads Overage — Needs Approval, the allowed number is joined by +n over, and an amber note says Justification required — use the button above to add one.
    Client Supplies — Review Order, over the allowance
    The three things to look for, all at once: the chip reads Overage — Needs Approval, the allowed figure is followed by +n over, and an amber Justification required note sits underneath. Continue is greyed out and an amber 1 item(s) need justification button has appeared beside it. Here 40 of PIPET TRANSFER W/GRADUATIONS were asked for against an allowance that read 18 that day — your figures will differ by whatever has already been ordered, so read the numbers on your own screen
  4. Look at the top-right of the panel. Continue should be disabled, and an amber button reading n item(s) need justification should have taken its place in your eye-line. Try clicking Continue and confirm nothing happens.
  5. Open How is this calculated? again. The breakdown now ends with an Overage row, and it opens with a sentence telling the client what the overage means for them.
    Breakdown for an over-limit line
    "This overage requires approval. Use the button in the header above to enter a justification — your order cannot be submitted until one is provided," then the arithmetic that produced it The Order Items card scrolls — drag or wheel inside it to reach the Overage row at the bottom
  6. Now reduce the quantity back below the allowance and confirm everything reverses: the chip goes quiet, the amber note disappears and Continue comes back. The client is never trapped.
  7. Confirm no dollar amount appears anywhere in the block or in the breakdown. The portal states an overage in units only; what it costs is shown to account managers and to Sonora Quest's own teams, not to the client.
Expected result
  • An over-limit quantity is flagged immediately, in units, against the product it belongs to — and no dollar amount is shown to the client.
  • Continue is disabled and replaced in prominence by a justification prompt.
  • The breakdown explains what happens next, not just the numbers.
  • Reducing the quantity clears the warning without leaving the page.
Result:
Scenario 2 · ~7 min SQL2-143

Give a reason for the overage

Not run

What you're checking: the justification prompt — that it names the product and the numbers, offers the client the easy way out first, and will not let the order past until every flagged line has a reason.

  1. Click the amber n item(s) need justification button.
  2. Read the panel header. It reads Justifications Required with a running count underneath — n of n still need a reason.
    Justifications Required
    One card per flagged product, with Requested against Allowed, the suggested reduction, and the reason picker. The footer counts what is still missing
  3. Read the card for your product. It restates Requested and Allowed, then offers the alternative first: Reduce to n to stay within your limit — or provide a reason below if you need the full amount. Note whether that reads as helpful or as a nudge you resent.
  4. Open the Select a reason... picker and read the choices.
    Reason categories
    Clinical Volume Increase · Provider Request · Temporary Demand Spike · New Patient Onboarding · Research Project · Scheduled Patients · New Provider · Expired Supplies · Test Conversion · Seasonal Demand (Flu, RSV, etc.) · Hosting a Special Event · Other
    These twelve categories are the ones that will be reported on. The six just before Other were added from testers' suggestions, so if a reason your practices actually give is still missing, tell us now. It is a cheap change now and an expensive one after go-live.
  5. Pick Other and confirm a free-text Additional Details box appears underneath. Type a sentence into it.
  6. Change the picker to one of the named categories and confirm the free-text box disappears again — the categories stand on their own.
  7. Watch the footer. As soon as the last flagged line has a reason, the amber n still missing changes to All justifications provided. Click Done.
    Client Supplies — Submitted, pending approval
    The over-limit order does not stop at Approved. It lands on Pending Approval: the banner says the order is under review and that an email will confirm exactly what shipped
  8. Confirm the button beside Continue has changed to a quiet All justifications provided badge and that Continue is now enabled.
Expected result
  • The prompt names the product, the requested quantity and the allowed quantity.
  • It offers reducing the quantity as the first option before asking for a reason.
  • Choosing Other reveals a free-text box; choosing a named category hides it.
  • Continue stays disabled until every flagged line has a reason, then becomes available.
Result:
Scenario 3 · ~7 min SQL2-135 SQL2-144

Submit it — the order goes into review, not into Workday

Not run

What you're checking: the handover. An over-limit order must stop short of fulfilment, tell the client honestly that it is under review and what they will hear next, and be recorded internally as needing a decision — deadline included. Keep this order — it is exactly what the account managers' review desk (the internal track) works through; if your team covers both tracks, hand the number over.

  1. Carry on from Scenario 2 through Shipping Address and Confirm, then click Place Order.
  2. Read the Submitted screen carefully — this is the sentence that matters most in Phase 2. It should be headed Pending Approval and read: "One or more items in this order exceed your allowed amount and are under review. You'll receive an email confirming exactly what shipped." The approver is whoever owns the client record at the moment you press Place Order. To see who that is for the shared test client 77777, open the client in Salesforce and read Client Owner on its Details tab, or ask whoever runs the internal track. There is no backup approver configured, so an order placed for a client somebody else owns will sit with that person and nobody will action it during testing. Stay on your assigned test client.
  3. Confirm there is no countdown on this screen. The review window is still real: a deadline is stamped on the order when you pressed Place Order, and if nobody reviews the order before it passes, the system acts on it by itself — Scenario 4 shows you what that looks like. The client is simply not shown a clock; you will read the deadline itself in the last step, inside Salesforce. The window is currently set to 1 hour for testing. The production window will be agreed with Sonora Quest and is changed in one admin field.
  4. Check the status. The Order Summary should read IN PROGRESS, not Approved. That status is what holds the order back from Workday.
  5. Write down the order number and the time. Everything that happens next — a reviewer's decision, or the automatic release — hangs off that clock, and Scenario 4 comes back to it.
  6. Open View Order Details. The order page shows the Order Progress bar on In Progress and a Review Decision panel saying some supplies are over the agreed monthly allocation for this site (or the approved maximum cost) and your Account Manager is reviewing it. Under Items on this Order, each supply that is being looked at says Under review on its own row.
  7. Check My Order History. The order should appear under the In Review tab, and the right-hand At a glance panel's Awaiting review count should have gone up by one.
  8. Look at it internally. In Salesforce, open the order and check the Compliance Status section: Compliance Status reads Over Allowed - Requires Approval, Compliance Requires Approval is ticked, and Compliance Justification holds the reason you gave, prefixed with the product name. In the same section, Approval Release At holds the deadline: the time you pressed Place Order plus the review window (1 hour in this environment).
Expected result
  • The order is accepted but lands on In Progress, never straight to Approved.
  • The client is told the order is under review and that an email will confirm exactly what shipped.
  • The deadline is stored on the order (Approval Release At); the client's screen shows no countdown.
  • Internally the order records that approval is required and carries the client's stated reason.
Result:
Scenario 4 · ~10 min (plus the wait) SQL2-147 SQL2-163

Come back after the decision — what the practice actually sees

Not run

What you're checking: the other end of the review window. Whether a person decided your order or the clock ran out, the practice should be able to open the order and understand exactly what changed, what was removed, and why — without phoning anyone.

  1. Wait out the window. The review window in this environment is 1 hour, on purpose, so you can test this in a single sitting. Place your over-limit order from Scenario 3, note the time, and go do another module — then come back once the hour has passed.
  2. Reopen the order from My Order History and read the top of the page first. The status has moved off In Progress. It reads Approved whether the account manager approved it or the clock simply ran out — or Denied if a reviewer turned the order down, or Canceled in the rare case where no line had any allowance left to ship. Any of those is a pass here; note in your comments which one you got. The Review Decision panel sums it up in one sentence, for example "Your supply was over the agreed monthly allocation for this site and was reduced.", and points to Items on this Order, where each supply the review changed says so on its own row, with what you asked for — "Reduced to 1 (3 requested)" — and a supply that was removed stays listed, last, under Removed from this order. On a denied order the panel points to View Order instead.
  3. Read each order line. The order page shows each supply’s approved quantity. A line the review changed says what happened in a small label — Reduced to 1 (3 requested), or Approved in full when the reviewer kept your quantity — with the reviewer’s reason under it. Click View Order for the full detail: a line that was cut back to the allowance shows its new quantity with a Reduced to Your Limit chip, and keeps the quantity you originally asked for alongside it — the practice should never wonder whether their request was misread.
    Client Supplies — the order after the window closed
    Approved, but not as requested: the Review Decision panel sums up what happened to the supplies, the reduced line says Reduced to 1 (3 requested) with the account manager’s reason printed right on the item, and the removed supply stays listed under Removed from this order
  4. Find the removed items. In View Order, a line the engine had no allowance for at all is not silently deleted — it moves to a Removed from this order card with the product, the quantity you asked for, and a plain-language reason ("no remaining allowance for this item this period").
  5. Read the reason wording as a practice manager. Each adjusted or removed line carries the reviewer's comment (if a person decided) or the standard wording (if the window expired). If any sentence would confuse the person reordering supplies for a clinic, quote it in your comments. Which outcome you get depends on whether anyone touched it. If an internal reviewer approved or trimmed your order inside the hour, you are looking at their decision; if nobody did, the system released it by itself, trimming every over-limit line to its allowance. Both are correct behaviour — say which one you observed in your comments.
  6. Check the inbox of the ship-to contact. The follow-up email lists the supplies with their final quantities — adjusted lines flagged, removed lines shown as Removed with the reason — and matches the order page exactly.
    Email — the decision, line by line
    The supplies table tells the same story as the order page: what was approved, what was reduced, what was removed, and why
Expected result
  • After the window closes the order leaves In Progress without anyone at the practice doing anything.
  • Reduced lines show the new quantity, the original request, and a readable reason.
  • Fully removed lines appear in a Removed card with the quantity asked for and why it went.
  • The email matches the order page line for line.
Result:
All modules PB1

Order on behalf of a client

Not started

Why you're testing this

Sonora Quest staff place orders for clients all day — a practice rings up, faxes a list, or emails one over. This module proves that path end to end from inside Salesforce, and it carries two things you asked for last round: Create Order is now the first button on the client record instead of being buried among a dozen others, and the Orders related list is back so you can find what you just placed. It also settles how client search behaves, because the string printed at the top of a client record is not the string you should type into search.

Full story & acceptance criteria

SQL2-24 — Supply Order Wizard framework. "As a Provider Portal User, I want a step-based order wizard framework and navigation design, so that I move through ordering with clear progress." The wizard shows clear steps; you can move forward and back without losing progress; empty, loading and error states are easy to understand. The internal launch path — open a client record and use the header's Create Order action — is called out in the ticket's own testing steps.

SQL2-94 — Marketing Phase 1 Feedback. Streamlines the wizard to Select Items, Review Order, Shipping Address, Confirm; auto-selects the client and the price book so nobody hand-picks a catalog; moves the unit of measure next to the quantity; hides internal fields such as Order Status and Price Book from the Review and Confirm steps.

SQL2-200 — "Can the Create Order button be bolded? It took a while to find it, too many buttons on the same screen." Create Order is now the first action on the client record header.

SQL2-194 — "The order cannot be found in Related > Orders." The Orders related list is back on the client layout: it has its own link in the related-list strip under the highlights, and its own card on the Related tab.

SQL2-186 — "Client can be found by ID number or name. Both at the same time do not work together." Correct, and now written down: search by the ID or by the name, never the combined "ID-Name" string the record header displays.

Scenario 1 · ~5 min SQL2-186

Find the client: ID or name, never the pasted heading

Updated from your feedback Not run

What you're checking: that searching for a client works the way you found it working — the ID on its own, or the name on its own — and that you now know why the combined string printed at the top of the record finds nothing. This scenario exists because of your note last round, and getting it written down correctly is the point of it.

  1. Click the Search... box at the very top of Salesforce and type your test client's ID number on its own — for the QA test client that is 77777. Press Enter.
  2. Confirm the results page opens with your client as the first row under Clients — the one whose ClientID reads exactly 77777. The Clients count in the left rail reads 4 in this sandbox, not 1, because search also returns the three clients whose ID merely contains those digits (D77777, 77777A and C77777).
    Search results — client ID only
    The ID on its own finds the client and lists it first; the left rail shows Clients 4 because three other client IDs contain the same digits
  3. Clear the search box and try the name on its own this time — Sonora Quest Laboratories. Press Enter. The same client is among the results.
  4. Now try the combination. Open the client record and look at the title at the top of the page: it reads 77777-Sonora Quest Laboratories. Copy that whole string, paste it into the search box and press Enter.
  5. Confirm you get the "Don't give up yet!" empty result — "We searched the objects you use most and didn't find any matches".
    Search results — the combined ID-Name string
    Pasting the combined heading straight off the record finds nothing — every count in the left rail reads 0 and the page says Don't give up yet!
    This is expected, and it is worth knowing why. The heading "77777-Sonora Quest Laboratories" is a display-only label built by joining two fields together. Search reads the two underlying fields, not the joined label, so the joined text matches nothing. Search the ID, or search the name. Never paste the heading.
  6. Search the ID on its own once more, open your client from the results and leave the record open — the next scenario starts here.
Expected result
  • The client ID on its own finds the client — it is the first row under Clients.
  • The client name on its own returns the same client.
  • The combined "ID-Name" heading finds nothing, and the empty-result page says so plainly rather than failing silently.
Result:
Scenario 2 · ~4 min SQL2-200 SQL2-194

Create Order is the first button, and the Orders list is back

Updated from your feedback Not run

What you're checking: the two placement fixes you asked for. You said it took a while to find Create Order among all the buttons, and that you had to add Orders to your favourites bar because the related list had gone missing. Both are addressed on the client layout — this scenario is a two-minute look.

  1. Open your test client record and look at the row of buttons on the right of the header.
  2. Confirm Create Order is the first action in that row, immediately after Follow. Everything else — Plan a Sales Call, Schedule DermTech Kick-Off, Request Interface, Transfer Client, Fillable Templates — now sits to its right.
    Client record — header and related-list strip
    Create Order leads the button row, and Orders (10+) closes the first row of the related-list strip below the highlights
  3. Look at the strip of related-list links under the highlights panel. Orders is in it, right after Client History, with a count beside it — on a wide screen that puts it at the end of the first row, as in the screenshot.
  4. Click Orders. The full Orders list for this client opens with Order Number, Status, Order Start Date, Contract Number and Order Amount, sorted by Order Number. It starts with the oldest order on top — click the Order Number column heading once to flip it so the newest leads, and note that top number for step 6.
  5. Use the browser's back arrow (or the breadcrumb at the top-left) to return to the client, then click the Related tab and confirm Orders appears there too — that is the route you had to work around last round.
  6. Write the newest order number you noted in step 4 in your comments. You will place an order in Scenario 4 and expect to find its number above this one.
Expected result
  • Create Order is the first action button on the client header — no hunting.
  • Orders has its own link in the related-list strip and is present on the Related tab.
  • The Orders list opens and shows this client's orders with their statuses.
Result:
Scenario 3 · ~8 min SQL2-24 SQL2-94

Build the order: catalog, cart, and the two internal-only fields

Not run

What you're checking: that the same ordering screens a client sees open inside Salesforce as a full-screen window over the client record, already pointed at the right client and the right catalog — plus the two things only internal staff get: choosing which of the client's contacts the supplies ship to, and recording how the order came in.

  1. Click Create Order on the client record. Wait a few seconds — a full-screen window opens over the record with a five-step bar across the top: Select Items · Review Order · Shipping Address · Confirm · Submitted.
    Create Order — step 1, Select Items
    The wizard opens over the client record. CLIENT / FACILITY is already filled in on the left, and the product count above the list is this client's catalog
  2. Check the Filters panel on the left. CLIENT / FACILITY already names the client whose record you came from — you never pick it, and you never pick a price book either.
  3. Note the line above the product list — "n products found". Write that number down; the next module explains where it comes from.
  4. Add one product with Add to Cart. The button changes to In Cart and the row gains UNIT and QTY boxes with a Remove link.
  5. Click Continue to Review at the top right.
  6. On Review Order, find the Shipping Contact card on the right. Open SHIP TO CONTACT — it is marked required with a red asterisk — and pick a contact. This is the internal-only capability: a portal user is pinned to their own contact and cannot choose.
    Review Order — internal view
    Ship To Contact and Order Source sit in the right-hand card. The teal band counts the client's standing recurring orders. The amber 1 item(s) need justification button beside Continue is not the duplicate band from step 8 — it means this line runs past its supply limit, which the compliance modules cover
    The contact list is deliberately short. It offers only the client's portal-associated contacts, not every contact on the account, so you cannot ship to someone who has no business receiving supplies.
  7. Open ORDER SOURCE underneath it and confirm it offers exactly three choices — Phone, Fax, Email — and nothing else. Pick the one that matches how this order reached you.
    Order Source — the three manual channels
    Only the three ways a person can hand you an order. Portal, Reorder and Recurring are stamped by the system and are not offered here
    Order Source is internal-only by design — a client never sees it and never sets it. Orders raised in the portal, from a Reorder, or by a recurring schedule are labelled automatically.
  8. Read the two coloured bands above the items while you are here. The teal one counts the client's standing recurring orders and opens a panel listing them. The amber one appears when this client and this delivery address have ordered these same items recently — it exists so you do not send a duplicate off a phone call.
  9. Click Continue.
Expected result
  • The wizard opens over the client record with the client and catalog already chosen.
  • Adding an item works and the cart shows unit and quantity per line.
  • Ship To Contact is required and lists only the client's portal-associated contacts.
  • Order Source offers Phone, Fax and Email only.
  • The recurring-orders band and, where relevant, the duplicate-order band both appear on Review.
Result:
Scenario 4 · ~7 min SQL2-24

Ship it, place it, and find the order you just made

Not run

What you're checking: the last three steps of the wizard and the record they produce — that the address, the delivery note and the contact you chose all survive the trip, and that the finished order lands in the client's Orders list where you can find it again.

  1. On Shipping Address, read the location cards. The client's default address is marked DEFAULT, and hovering the greyed-out bookmark icon on that card shows "This is your default location"; any standing delivery note for that address is printed on the card.
    Step 3 — Shipping Address
    One card per ship-to location, the default flagged, standing delivery notes shown, and three small tools per card — set as default, edit delivery instructions, view map and altitude
  2. Click the card you want to ship to (the default is already selected) and then Continue.
  3. On Confirm, check the four blocks: Shipping Address with the delivery instructions underneath it, Order Items with the quantity, Ordering As naming the contact and facility you picked, and Order Summary with the totals.
    Step 4 — Confirm Order & Submit
    Everything you chose, on one screen, above the line "By placing this order, you confirm all details are correct"
  4. Click Place Order and wait — this takes a few seconds while the order is checked against the client's supply allowance.
  5. Read the confirmation: "Order Submitted Successfully!", the order number in a large badge, and a progress bar showing where the order has landed. Write the order number down.
    Step 5 — Submitted
    The order number with a copy icon beside it, the progress bar, and five follow-on actions including Set Up Recurring Order and Reorder
    The progress bar may stop at Approved or at In Progress. Both are correct: In Progress means the order needs an account manager's review before it goes anywhere. Which one you get, and why, is the subject of the compliance modules.
  6. Click View Order Details, or close the window and open the order from the client's Orders related list — flip it to newest first as you did in Scenario 2 and your new order sits above the number you noted there.
  7. On the order record, check the Path bar under the highlights and then the Details tab. Confirm Shipping Location, Shipping Address and Ship To Contact match what you chose, and that Order Memo carries the delivery instructions from the address.
    Order record — internal
    The Path across the top, then the order's own fields: shipping location and address, ship-to contact, price book, and the delivery note copied into Order Memo
  8. Click the Related tab and confirm Order Products lists the line you ordered and Order History logs the order being created and its status change, each with a name and a timestamp.
Expected result
  • Shipping, Confirm and Submitted all run through without an error, and the order number is issued on screen.
  • The new order appears in the client's Orders related list.
  • The order record carries the shipping location, address, ship-to contact and delivery note you chose.
  • Order Products and Order History both hold real, timestamped data.
Result:
Scenario 5 · ~5 min SQL2-94

Save a draft and pick it up again

Not run

What you're checking: that a half-built order survives being walked away from — the client rings off mid-list, you save, and you come back to it later without retyping anything.

  1. Start a fresh order from the client record with Create Order, add two different products and set a quantity you will recognise later, such as 3 and 5.
  2. Click Continue to Review, then click Save Draft at the top right rather than continuing.
  3. Close the window with the X at the top right.
  4. Open the client's Orders related list and find the newest order — click the Order Number heading if the oldest is on top. Its status reads Draft.
  5. Open that draft. Under the highlights, the button reads Resume Order — not View Order. An order that has already been placed shows View Order instead, and opens read-only. The guide used to call this "Recent Order" — that wording was wrong and has been corrected.
  6. Click Resume Order. The wizard reopens on the step you left, with both products and both quantities exactly as you set them.
  7. Change one quantity, finish the order through Shipping and Confirm, and confirm the changed quantity is what appears on the confirmation.
Expected result
  • Save Draft creates an order with status Draft on the client record.
  • A draft offers Resume Order; a placed order offers View Order.
  • Resuming returns every item and quantity untouched, and the order can be finished from there.
Result:
All modules PB2

Catalog management

Not started

Why you're testing this

Every client sees its own list of supplies, and nobody hand-picks it. A switch on the client record decides which catalog applies, the system points the client at the matching price book, and the ordering screens then show exactly that list. Last round you could not see either field and reported them missing — they were always there, but the permission set that reveals them had not been assigned to you. It has been, so this module is about proving the chain holds: switch on the client record, price book behind it, product list in the wizard.

Before you start: access to these fields comes from the Provider Order Management permission set, not from your profile. If a field named below is genuinely absent for you, that is a permission-set assignment to raise rather than a missing feature — say so in your comments and we will check the assignment.

Full story & acceptance criteria

SQL2-33 — "As a Provider Portal User, I want to apply the correct product list automatically when I start an order." When an order starts, the correct product list is applied for that organisation, and only items the organisation is allowed to order are shown.

SQL2-35 — "As a Provider Portal User, I want the system to auto-associate my order with the right product catalog at initiation, so that ordering uses the correct catalog without extra steps." Starting an order sets the catalog with no manual selection; if the client's attributes change, the next order uses the right list.

SQL2-187 — the gate ticket for six "field is not displayed" findings. Field visibility on the custom Order, Client, Case, Location and Product fields comes only from the Provider Order Management permission sets, and no profile grants it — including System Administrator. All UAT testers have now been assigned them.

SQL2-188 — "The Price Book and Exclusive Product Access are not visible under Account Detail. Also the Price Book list is empty after clicking in App Launcher." Both fields are on the client layout; the empty list is the Price Books tab opening on its Recently Viewed view.

SQL2-189 — "Related Price Book and Exclusive Supply Product Access cannot be found under the client." Same root cause as SQL2-188 — retested here on a client record end to end.

Scenario 1 · ~5 min SQL2-188 SQL2-189

The two catalog fields on the client record

Updated from your feedback Not run

What you're checking: the exact two fields you reported as missing — Exclusive Supply Product Access? and Related Price Book — and where they live on the client record. They are inside a section that is collapsed by default, which is why they are easy to miss even when your permissions are right.

  1. Open your test client record and stay on the Details tab.
  2. Scroll past Compliance Information until you reach the grey bar headed Budgetary Responsibility (Admin Only). It has a chevron pointing right, which means it is closed.
  3. Click that grey bar once. The section opens and its fields appear.
    Client record — Budgetary Responsibility expanded
    Exclusive Supply Product Access? and Related Price Book sit near the bottom of the section's left column, each with a help icon
  4. Find Exclusive Supply Product Access? near the bottom of the left column. It is a Yes/No field with a small information icon — hover it and the help reads "Does this Client account have access to exclusive supply items?". Note the current value.
  5. Find Related Price Book immediately beneath it. It is a link to a price book record; its help reads "The Pricebook related to this Client Account". Note which price book is named.
  6. Click the Related Price Book link to open that price book. Check its Details: the name, Active ticked, and a field called Exclusive Product Catalog?.
    Price Book record
    A price book knows whether it is the exclusive one — that is the flag the assignment rule looks for
  7. Click the Related tab on the price book. Price Book Entries lists the products it contains — the first six, with View All for the rest — each with a Product Code, a List Price and an Active tick.
    Price Book — Related
    The catalog's contents: product, code, list price and whether each entry is active
Expected result
  • Both fields are present on the client's Details tab, inside the Budgetary Responsibility (Admin Only) section.
  • Each field carries help text explaining what it does.
  • Related Price Book opens a real price book record with its entries.
Result:
Scenario 2 · ~3 min SQL2-188

The Price Books tab that looked empty

Updated from your feedback Not run

What you're checking: the second half of your report — "Price book is empty after clicking in App Launcher". The tab is not empty; it opens on a view that only lists records you have opened before.

  1. Click the App Launcher (the grid of nine dots, top left), type Price Books and open it.
  2. Look at the view name under the tab heading. On a fresh login it reads Recently Viewed, and it will be empty or nearly empty — that is what you saw last round.
  3. Click the small arrow beside Recently Viewed to open the list-view picker, and choose All Price Books.
  4. Confirm the list now shows the org's price books with an Active tick beside each. Recently Viewed is a Salesforce-wide default on every object's tab, not something specific to price books. If a list looks empty anywhere in Salesforce, check the view name first — it is the single most common cause.
  5. Pin the view if you like — the pin icon beside the view name makes All Price Books your default next time.
  6. Open each price book in turn and note, from its Details, whether Exclusive Product Catalog? is Yes or No. You will use both in the next scenario.
Expected result
  • The Price Books tab opens on Recently Viewed and can be switched to All Price Books.
  • The full list shows the org's price books, each marked Active.
  • One of them is flagged as the exclusive catalog.
Result:
Scenario 3 · ~6 min SQL2-33 SQL2-35

The catalog the wizard actually loads

Not run

What you're checking: that the price book named on the client record is the list the ordering screens hand you — and that nobody is ever asked to choose one.

  1. Open the price book named in the client's Related Price Book field, click Related, then View All on Price Book Entries, and count the rows that carry an Active tick. Write that number down. The wizard also drops any entry whose product has been retired, so its count can come in under your tally — for the QA test client's Standard Price Book, 16 active entries show as 12 products because four of those products are inactive. If the wizard's number is lower than yours, open a few of the entries you counted and check the product record's Active box before calling it a Fail.
  2. Go back to the client record and click Create Order.
  3. Read the line above the product list: "n products found". It should match the number of active entries you just counted, less any whose product is retired.
    Create Order — the client's catalog
    The product count is the client's price book, loaded without anyone choosing it. The Filters panel offers client, search and category — no price-book picker
  4. Confirm the Filters panel on the left has CLIENT / FACILITY, SEARCH PRODUCTS and CATEGORY — and no price book or catalog control anywhere on the screen. Choosing one is not your job.
  5. Search for a product you know is not in this client's price book. It does not appear — the list is limited to the client's own catalog.
  6. Close the window with the X.
  7. Open a different client that uses a different price book, click Create Order, and confirm the product count changes to match that client's catalog instead.
Expected result
  • The wizard's product count matches the client's active price book entries on active products.
  • There is no price-book or catalog picker on any wizard screen.
  • A different client with a different price book gets a different product list.
Result:
Scenario 4 · ~7 min SQL2-189 SQL2-35

Flip the exclusive switch and watch the catalog change

Updated from your feedback Not run

What you're checking: the scenario you could not complete last round. Changing one Yes/No field on the client should re-point its price book automatically, and the very next order should offer a different set of products. Nobody edits a price book link by hand.

Use a client that nobody else is testing against, and set the switch back to its original value at the end — step 8. Write the starting value in your comments before you change anything.
  1. Open your test client, expand Budgetary Responsibility (Admin Only) and write down the current values of Exclusive Supply Product Access? and Related Price Book.
  2. Click Create Order, note the "n products found" count for the current catalog, then close the window.
  3. Click the pencil beside Exclusive Supply Product Access?, change it from No (or blank, which counts as No) to Yes, and click Save. Clicking one pencil opens the whole record as a single edit form with Cancel and Save at the bottom — that is normal Salesforce behaviour, not a fault.
  4. Refresh the record and look at Related Price Book. It has changed on its own to the catalog flagged Exclusive Product Catalog? = Yes. You did not touch it.
  5. Click Create Order again and read the product count. It is now the exclusive catalog's count, not the standard one.
    Create Order — after switching to the exclusive catalog
    Same client, same button, a shorter list. The switch on the client record is the only thing that changed
  6. Compare the two lists. Products that are only in the standard catalog are gone. In this sandbox the exclusive catalog is a shorter cut of the standard one — 4 of its 12 products — so nothing new appears; a product that existed only in the exclusive price book would show up here.
  7. Close the window without placing an order.
  8. Set Exclusive Supply Product Access? back to its original value and Save. Refresh and confirm Related Price Book has followed it back, then reopen Create Order one last time and confirm the original product count has returned.
Expected result
  • Changing the exclusive switch re-points Related Price Book automatically, in both directions.
  • The wizard's product list changes to match, with no other action taken.
  • Setting the switch back restores the original catalog and the original product count.
Result:
Scenario 5 · ~5 min SQL2-33 SQL2-194

The finished order remembers which catalog it used

Updated from your feedback Not run

What you're checking: that the catalog decision is recorded on the order itself, so months later you can still tell which price list a client was on when they ordered. This is the scenario where you had to hunt for the order last round — the Orders related list is back, so start there.

  1. Place a small order for your test client using Create Order (one item is enough), and note the order number from the confirmation.
  2. Close the window and open the client's Orders related list — its link sits in the strip under the highlights, right after Client History.
  3. Find your new order — click the Order Number heading if the oldest order is on top — and open it.
  4. On the Details tab, find the Price Book field and confirm it names the same price book as the client's Related Price Book.
  5. Click the Related tab and open Order Products. Every line should be a product from that catalog.
  6. Open one order product and confirm the price it recorded matches the price on that catalog's price book entry.
Expected result
  • The order is easy to find from the client's Orders related list.
  • The order's Price Book field names the client's catalog.
  • Every ordered line and its price comes from that catalog.
Result:
All modules PB3

Locations, geocoding & delivery defaults

Not started

Why you're testing this

A ship-to location is where the supplies actually go, so it has to be right: a proper address, coordinates a driver can route to, an altitude for the courier planning, and any standing instruction the client keeps repeating on the phone. Last round four of your findings were about this screen — the record type picker, the address field, the status field and the Workday identifier all appeared to be missing. They were not missing; the permission set that reveals them had not reached you. This module walks the whole location life from creation to the map, and it is the module where the geocoding pays off in front of you.

Before you start: visibility of these fields comes from the Provider Order Management permission set, not from any profile. If something named below is genuinely absent, note it in your comments and we will check the assignment rather than the build.

Full story & acceptance criteria

SQL2-78 — Geocoding for Supply Location. "As a Logistics Coordinator, I want to store latitude and longitude for each facility for routing, so that drivers reach precise delivery points." Saving a valid address stores the latitude, longitude and altitude of the location; I can view the coordinates or a small map preview; if an address cannot be matched I see a clear message.

SQL2-32 — Default Delivery Instructions. "As a Provider Admin, I want to save default delivery instructions per ship-to address, so that drivers receive consistent guidance." Instructions can be saved against a ship-to address, orders to that address show them on review, and updating them affects new orders.

SQL2-190 — "Address field is not displayed." Permission-set visibility; the address is on the location layout and on the create form.

SQL2-191 — "Record Type is not displayed in New Facility Location and no address can be added." Record type assignment plus the same permission set — the record type chooser now appears before the form.

SQL2-192 — "Status feature along with the address are not available" when reactivating a location. Same fix; Status is an editable field on the location record.

SQL2-193 — "The Workday WID is not displayed in Salesforce, but it is visible in the Provider Portal under the same order." Internal users see everything, including the Workday identifiers — that was the ruling and this is where it is proved.

Scenario 1 · ~8 min SQL2-191 SQL2-190

Create a facility location: record type, address and all

Updated from your feedback Not run

What you're checking: the screen that stopped you last round. Creating a location should ask which kind it is, then give you a form with a real address on it. Both halves of your finding are covered here, in order.

  1. Open your test client record, click the Related tab and open Locations. The list shows the client's ship-to locations with their Receiving Type and address.
    Client record — Locations related list
    Every ship-to location for this client, with a New button top-right
  2. Click New. A small window headed New Facility Location opens first, asking you to Select a record type.
    New Facility Location — record type chooser
    Four record types, where you pick Courier + Supplies (Courier is the default, so change it) — this is the step you reported as missing
  3. Confirm the four choices are listed — Courier (the default), Courier + Supplies, Quest Only PU, Supplies — select Courier + Supplies and click Next.
  4. Read the form that opens. Its heading names the record type you picked, for example "New Facility Location: Courier + Supplies", and Client is already filled in with the client you came from.
    New Facility Location form — top half
    Three fields carry the red asterisk: Client, Facility Location ID and Effective Date. Status defaults to Active, Receiving Type is pre-set from the record type you picked, and the four Workday fields are already on the form
  5. Fill in the required fields: Facility Location ID (a short code that is not already in use — the client ID plus your initials, such as 77777-KP) and Effective Date = today. Leave Status on Active and Receiving Type as it was pre-set. There is no name to type: once you save, the location names itself from the Facility Location ID and the street, e.g. 77777M 2600 N Central Ave.
  6. Scroll down the form to the Address block. It has an Address Search box and then separate Country/Territory, Street, City, State/Province and ZIP/Postal Code fields.
    New Facility Location form — the Address block
    The address you reported as missing, with its own search box and the five separate parts beneath it
  7. Type a real, findable street address — a Phoenix-area one is ideal, for example 2600 N Central Ave, Phoenix, Arizona, 85004, United States. A real address matters: the next scenario looks it up on a map.
  8. Click Save and wait for the record to open.
Expected result
  • Clicking New asks for a record type before opening the form.
  • The form names the record type, pre-fills the client, and marks its required fields.
  • A full Address block is present and accepts a street, city, state and ZIP.
  • The location saves without an error and its record opens.
Result:
Scenario 2 · ~5 min SQL2-78

The address turns into coordinates and an altitude

Not run

What you're checking: that saving a good address quietly does the geography for you. Nobody types coordinates; the system looks the address up and stores where it is and how high it is, so a courier can route to it.

  1. Stay on the location you just created — or reopen it from the client's Locations list — and give it a moment, then refresh the page.
  2. Find the Altitude field on the Details tab. It now holds a number you never typed, in feet, and its help text reads "Location Altitude (Feet)".
    Location record — after saving the address
    Altitude filled itself in from the address. Phoenix-area addresses land around a thousand feet; a Colorado one would be five thousand plus
  3. Sanity-check the number against the place. An address in the Phoenix valley should be roughly 1,000–1,200 feet. If you used a mountain-state address expect thousands more. A zero or a blank would be the failure.
  4. Check the Address field on the same tab prints the street, the city, the state and the ZIP you typed.
  5. Now see it on a map. Go back to the client record, click Create Order, add any item, click Continue to Review, pick a Ship To Contact, and click Continue to reach Shipping Address.
    Shipping Address — one card per location
    Each card carries three small tools on its right: set as default, add or edit delivery instructions, and view map and altitude
  6. Find your new location's card and click its third small icon, View map and altitude.
  7. Confirm the Location Details window shows a map with a pin on your address, an ALTITUDE in feet, and a COORDINATES pair of latitude and longitude.
    Location Details — map, altitude, coordinates
    The payoff: the pin is on the address, the altitude is in feet and the latitude/longitude pair is stored on the record
  8. Close the window and close the wizard without placing an order.
Expected result
  • Altitude is populated automatically after the address is saved, and the number is plausible for that place.
  • The Location Details window draws a map with the pin in the right spot.
  • Latitude and longitude are stored and shown, without anyone entering them.
Result:
Scenario 3 · ~5 min SQL2-193

The Workday identifiers, visible on the inside

Updated from your feedback Not run

What you're checking: your finding that the Workday WID showed in the portal but not in Salesforce. Internal staff are meant to see everything, so all four Workday fields are on the location record — and this scenario is also how you confirm a location has been handed to Workday at all.

  1. Open a location that has existed long enough to have synced — pick one from the client's Locations list other than the one you just made.
  2. On the Details tab, find these four fields and read the help text on each:
    Workday WID — "Workday Location Record Identifier (WID)"
    WD Location ID — "Initial Workday Location ID returned in PUT call (Salesforce to Workday)"
    Workday Location Integration Submittal — the date and time the location was last sent
    Workday Error — empty when all is well
    Location record — Workday fields
    All four Workday fields sit on the internal location layout. This location has synced: a real Workday WID and a submittal timestamp, and nothing in Workday Error
  3. Confirm the Workday WID holds a long identifier — 32 letters and digits. WD Location ID may be blank: it is only filled on locations that Workday answered with its own ID, and in this sandbox most synced locations, including the QA test client's, show the WID alone. Some older locations were created before the Workday link existed and will have these fields empty. That is history, not a fault — pick one whose Workday WID is filled; on the QA test client, 55555-12 1116 Black Diamond Drive is one. A submittal date on its own only proves the location was sent, not that Workday has answered yet.
  4. Open the location you created in Scenario 1 and check Workday Location Integration Submittal there too. Creating a location queues it for Workday, so a timestamp should appear within a few minutes of saving.
  5. Confirm Workday Error is empty on both. If it holds text, copy that text into your comments — it is the integration telling you exactly what it rejected.
  6. Compare against the portal if you have a portal session open: the same identifier appears there. Internal is not meant to show less than the client sees.
Expected result
  • Workday WID, WD Location ID, Integration Submittal and Workday Error are all visible on the location record.
  • A synced location shows a real Workday WID and a submittal timestamp; WD Location ID may stay blank.
  • Nothing that the portal shows is hidden from the internal view.
Result:
Scenario 4 · ~5 min SQL2-192

Take a location out of service and bring it back

Updated from your feedback Not run

What you're checking: the reactivation path you could not reach last round, because Status and the address were not visible to you. A location that is out of service should stop being offered as a delivery address, and turning it back on should put it back.

Do this on the location you created in Scenario 1, never on a client's real ship-to address, and set it back to Active at the end.
  1. Open your Scenario 1 location and find Status on the Details tab. Its help text reads "Only use Active - Temp Facility when a location is using an alternate location for a short period."
  2. Click the pencil beside Status and open the list. Three values are offered: Active, Inactive, Active - Temp Facility.
  3. Choose Inactive and click Save. Confirm the record saves with no error and Status now reads Inactive.
  4. Check the separate Inactive field on the same layout and note what it says — it is the flag the Workday feed reads, and it is deliberately distinct from Status.
  5. Confirm the effect. Go to the client record, click Create Order, work through to Shipping Address and confirm your inactive location is no longer offered as a card.
  6. Close the wizard, reopen the location, set Status back to Active and Save.
  7. Confirm the address is still intact — street, city, state, ZIP and the altitude all survive the round trip — and that the location is offered again on Shipping Address next time you open the wizard.
Expected result
  • Status is visible and editable with its three values.
  • Setting it to Inactive saves cleanly and the location stops being offered as a delivery address.
  • Setting it back to Active restores it, with its address and coordinates untouched.
Result:
Scenario 5 · ~6 min SQL2-32

Standing delivery instructions and the default address

Not run

What you're checking: that a delivery note said once is remembered — it prints on the address card, it rides along on every order to that address, and it reaches the order record where fulfilment can read it. Plus the small convenience of marking one address as the client's default.

  1. Open the client record, click Create Order, add an item, Continue to Review, choose a Ship To Contact, then Continue to reach Shipping Address.
  2. Find your Scenario 1 location's card and click its second small icon, Add delivery instructions (it reads Edit delivery instructions once a note exists).
  3. Type a standing instruction that belongs to the address rather than to one order — for example "Deliver to the rear loading bay; gate code 4417" — and save it. The window offers two boxes and they mean different things. The first is the standing instruction kept against the address for every future order. The second is a comment for this order only. Use the first one here.
  4. Confirm the note now prints on the location's card, under the address, without opening anything.
  5. Select that card, click Continue, and check the Confirm screen: the note appears under DELIVERY INSTRUCTIONS beneath the shipping address.
  6. Click Place Order, then open the resulting order from the client's Orders list.
  7. On the order's Details tab, find Order Memo. It reads "Delivery Instructions:" followed by your note — that is how the instruction reaches fulfilment.
  8. Optional, and reversible: back on Shipping Address, click the first small icon on a card, Set as default location. That card gains a DEFAULT badge and the words "This is your default location", and it is preselected next time. Set the client's original default back afterwards.
Expected result
  • A delivery instruction saved against a location prints on its card straight away.
  • The same text appears on the Confirm screen for any order shipping there.
  • The finished order carries the instruction in Order Memo.
  • Marking a different address as default moves the DEFAULT badge and preselects it.
Result:
All modules PB4

Recurring orders (internal)

Not started

Why you're testing this

A recurring order is a standing instruction: turn one order into a schedule and the same supplies keep arriving without anyone re-typing them. This module covers setting one up, running it, pausing it and cancelling it — and the two small defects you found while doing exactly that last round, both of which are fixed. There is also a genuine change of behaviour to look at: deliveries a schedule produces now go through the same supply-allowance review as an order you place by hand, so they come out Approved, In Progress or Denied instead of sitting as drafts for someone to notice.

Full story & acceptance criteria

SQL2-63 — Subscription Services Ordering. "As a SQL internal Salesforce user, I want to set up recurring template orders at chosen intervals for eligible items, so that critical supplies arrive on schedule." I can pick items and choose a schedule such as bi-weekly or monthly; at the next interval an order is created; if I pause or cancel, no new order is created. A recurring order cannot be set up by a portal user — it is an internal-only capability.

SQL2-183 — "Review Template doesn't open after clicking View Template. No notice about a blocked popup window." Correct — the template link was being generated in a way that could not work inside the ordering window, so nothing happened at all. It now opens the template record directly in a new browser tab.

SQL2-184 — "Copy order number shows copied but is not populating." Also correct — the old code copied from an element the browser never actually put on the page, so it reported success while the clipboard kept its previous contents. It now copies the number that is on screen.

Scenario 1 · ~4 min SQL2-184

Copy the order number — and prove it really copied

Updated from your feedback Not run

What you're checking: your finding that the copy control said "Copied!" while the clipboard kept whatever was in it before. The check below deliberately puts something else on your clipboard first, so a false success cannot slip past.

  1. Before you start, put a marker on your clipboard: open any text box — the search bar will do — type the word MARKER, select it, and press Ctrl+C (Cmd+C on a Mac). Clear the box afterwards.
  2. Place a small order for your test client from Create Order — one item, any contact — and continue through to the Submitted screen.
  3. Find the order number in the large badge under the words ORDER NUMBER. There is a small copy icon inside the badge, and hovering it shows the tooltip "Click to copy".
  4. Click the badge. A small Copied! message appears just under it.
    Submitted — order number copied
    The badge doubles as the copy control, and confirms with Copied! just under it
  5. Prove it. Click into any text box and press Ctrl+V (Cmd+V). The order number should paste — not the word MARKER.
  6. Compare what pasted against the number on screen, digit for digit. Some locked-down browsers refuse clipboard access to any web page. If yours does, the message changes to tell you which keys to press instead, and the number is left highlighted so a single keystroke copies it. Either outcome is a pass; silently pasting the wrong thing is not.
  7. Keep this order open on the Submitted screen — the next scenario starts from here.
Expected result
  • Clicking the order-number badge confirms with "Copied!".
  • Pasting produces the order number, replacing whatever was on the clipboard before.
  • No false success: the message and the clipboard agree.
Result:
Scenario 2 · ~8 min SQL2-63 SQL2-183

Turn an order into a schedule, then open the template

Updated from your feedback Not run

What you're checking: setting up a recurring order from the order you just placed, and then the button that did nothing last round — View Template. It now opens the template record in a new browser tab.

  1. On the Submitted screen from Scenario 1, find the row of five actions and click Set Up Recurring Order.
  2. Read the window that opens: Recurring Order Settings — Configure how often this order should be automatically generated.
    Recurring Order Settings
    Frequency, start and end dates, and a live Schedule Preview that recalculates the next order date as you change them
  3. Set the Frequency. Open the list and confirm it offers Monthly and Bi-Weekly. Leave it on Monthly.
  4. Set a Start Date of today. Leave End Date empty — it is optional and means "keep going".
  5. Watch the SCHEDULE PREVIEW panel underneath. NEXT ORDER DATE recalculates as you change the frequency or the start date — try switching to Bi-Weekly and back and confirm the date moves.
  6. Click Create Recurring Order and wait a few seconds.
  7. Confirm a teal banner appears above the progress bar: Recurring Order Template Created! — "Your recurring order has been set up. Orders will be generated automatically based on your schedule." It carries a View Template button and an X to dismiss it.
    Recurring Order Template Created
    The confirmation banner with View Template — the button that did nothing at all last round
  8. Click View Template. A new browser tab opens on the template record. Switch to it and confirm it is a real order record with a number of its own. If your browser is set to block pop-ups it may hold the tab back and show a small blocked-pop-up icon at the right of the address bar. Click it, allow pop-ups for this site, and click View Template again. That is the browser talking, not the application — but do note it in your comments if it happens, because we want to know how often it does.
  9. Write down the template's order number and keep the tab open — Scenarios 3 and 4 use it.
Expected result
  • The recurring window opens with frequency, start and end dates and a live next-order-date preview.
  • Creating the schedule confirms with a banner naming what happened.
  • View Template opens the template record in a new tab — no silent nothing.
Result:
Scenario 3 · ~6 min SQL2-63

Read the template record

Not run

What you're checking: that the template is a proper record with its own schedule, its own run history and its own list of what it has produced — not a hidden setting on the original order.

  1. Open the template record from Scenario 2 (or from the client's Orders related list — templates appear there too).
  2. Check the top of the record. Status reads Draft and Order Amount is $0.00. Draft on a template is correct and permanent. A template is a pattern, never a shipment — it is not something anyone approves or fulfils. The orders it produces are the real ones, and they carry real statuses.
  3. On the Details tab, read the Order Template Information section: Order Record Type reads Template Order, and beside it sit Schedule Type, Template Status, Order Start Date, Order End Date, Next Run Date and Remaining Occurrences.
    Template order record
    A template has its own record type, its own schedule fields and its own run log — and an Edit Recurring Order Settings button in the highlights
  4. Confirm Template Status reads Active and Next Run Date matches the date the preview showed you when you set the schedule up.
  5. Read the Order Template Logs section below it: Last Run Date, Last Run Status and Last Run Error. On a brand-new template these are empty; on one that has run they carry a date and the word Success.
  6. Click the Related tab and confirm Order Products lists the items the schedule will send each time.
  7. Find the Generated Orders tab in the right-hand panel (beside Activity) and open it. On a new template it is empty; the next scenario uses one that is not.
Expected result
  • The template is its own record, typed as Template Order, and stays at status Draft.
  • Schedule Type, Template Status and Next Run Date all match what you set.
  • The template lists the products it will send and has a Generated Orders panel.
Result:
Scenario 4 · ~7 min SQL2-63

Pause it, restart it, cancel it

Not run

What you're checking: that a standing order can be stopped and started from one place, and that the record tells you plainly which state it is in. Do all of this on the template you created in Scenario 2, never on a client's live schedule.

  1. Open your template record and click Edit Recurring Order Settings in the highlights panel.
  2. Read the window: Edit Recurring Order Settings — Update the schedule for this recurring order template. It repeats the schedule fields, the schedule preview, and adds a CURRENT STATUS block with STATUS, LAST RUN and LAST RESULT.
    Edit Recurring Order Settings
    Everything about the schedule in one window, including Pause Recurring Order and Cancel Recurring Order
  3. Change the frequency from Monthly to Bi-Weekly, watch the preview date move, and click Update Recurring Order. Reopen the record and confirm Schedule Type and Next Run Date have both changed.
  4. Reopen the window and click Pause Recurring Order.
  5. Confirm the record now shows the paused state, and that reopening the window offers Resume Recurring Order where the pause button was. A paused schedule produces nothing until it is resumed.
  6. Click Resume Recurring Order and confirm it returns to Active with its next run date intact.
  7. Now cancel it. Reopen the window and click Cancel Recurring Order. Confirm Template Status on the record becomes Cancelled.
  8. Reopen the window one last time and confirm the buttons have changed again — a cancelled schedule offers Activate Recurring Order, so a client who changes their mind does not need a new template built from scratch.
Expected result
  • The schedule can be edited, and the record reflects the change.
  • Pause, Resume, Cancel and Activate are all offered at the right moments and never all at once.
  • Template Status on the record always matches the state you last set.
Result:
Scenario 5 · ~8 min SQL2-63

What the schedule produces — and the new automatic review

Updated from your feedback Not run

What you're checking: the biggest change in this module. A delivery a schedule produces used to appear as a draft and wait for someone to notice it. It now goes through the same supply-allowance review as an order placed by hand, and comes out approved, under review, or declined — with the client emailed either way.

  1. Open a recurring template that has been running for a while — ask us for one if your client has none, or use the client's Orders list to find an order whose record type is Template Order.
  2. Open the Generated Orders panel on the right of the template record. Its heading reads Generated Order History — Review all historical orders from this template.
    Generated Orders — the template's own history
    Newest first: order number, status chip, the date it was generated, how many items and the total quantity
  3. Read the list from the top. Each row gives the order number, a status chip, the date it was generated, the item count and the total quantity.
  4. Look at the pattern. Recent deliveries carry real decisions — APPROVED, IN PROGRESS or DENIED. Older ones, generated before this change, are still DRAFT. Both are correct. Deliveries created before the automatic-review change were left at Draft on purpose rather than being retro-fitted, so a mixed list is exactly what you should see. Judge the behaviour by the recent rows.
  5. Open one of the recent deliveries. On its Details tab, check the Compliance Status section: it names the decision and the reason the engine reached it.
  6. Check the same order's Order History on the Related tab — it logs the order being created and then its status change, timestamped, with no human in between.
  7. Open a delivery that came out Denied if the list has one, and read its decision reason. That same wording is what the client sees on their order in the portal — the portal modules cover the client side of it.
  8. See it happen for yourself, if you have the time. Open your own template from Scenario 2, click Edit Recurring Order Settings, and set the schedule so the Next Run Date is today. Deliveries are generated overnight, so check the Generated Orders panel again on your next testing day — a new order should be listed, carrying a real status rather than Draft.
Expected result
  • The template lists every order it has produced, with status, date, item count and quantity.
  • Recent deliveries carry a real decision — Approved, In Progress or Denied — not Draft.
  • Each delivery records the compliance decision and the reason behind it.
  • The order history shows the review happening automatically.
Result:
All modules PB5

Manage orders, cases & notifications

Not started

Why you're testing this

This is the support desk's half of the story. A client raises a question from an order in the portal; it has to arrive here as a findable case, attached to the right order, the right practice and the right person — and the answer has to get back to them. Both ends of that were reported last round: you could not find the case unless you searched the last eight digits, and it was not connected to the order. Both are fixed, and there is now a proper way to reply: one field on the case, and the client's own order page starts saying Inquiry answered.

Full story & acceptance criteria

SQL2-29 — Order Tracking & Status. "As a Provider Portal User, I want to see my order's current status and last updated time, so that I always know where my order stands." Covered here from the internal side: the client's Orders list, the order's own Path and Status, and the Order History audit trail.

SQL2-27 / SQL2-28 — Supply Order Support Requests. "As a Provider Portal User, I want to create a support request from an order and track it in the portal" / "As a Support Manager, I want requests routed to the right queues, so that issues reach the right team promptly."

SQL2-182 — "Unable to find the case in Salesforce unless the last 8 digits are searched. The submitted order inquiry case number is not displayed or connected to the order number." Inquiry cases now stamp the related order, the client and the contact, and are typed as a supply order inquiry.

SQL2-202 — "Where can the case status be seen in the Provider Portal?" It became an enhancement: the client's order page now carries a Support case card, their order list carries an Inquiry open or Inquiry answered tag, and whatever you write in Client Response is printed for them under "Response from our team".

SQL2-66 — Status Updates & Notifications. Order emails are sent on the key changes. They are sent without leaving an activity record behind, so they are checked in a real inbox rather than on the record.

Scenario 1 · ~6 min SQL2-182 SQL2-28

Find the inquiry from the order it came from

Updated from your feedback Not run

What you're checking: the fix for your finding. An order inquiry should be reachable from the order, not only by searching a case number you had to be told. Two routes are tested here: from the order, and from the case number the client quotes.

  1. Have an inquiry to work with. Either ask a colleague on the portal side to raise one from an order and give you the number, or raise one yourself: place an order from Create Order and, on the Submitted screen, click Submit an Order Inquiry, fill in the description and click Next.
    Inquiry submitted
    The client is handed the case number straight away: "Case 01556435 has been created. Please reference this number if you contact us about this inquiry."
  2. Open the order the inquiry was raised against, from the client's Orders related list.
  3. Click the order's Related tab and find the Cases related list. Your inquiry is listed there with its case number, subject, the date it was opened and its priority.
    Order record — Related tab
    Further down the Related tab, the Cases list connects the inquiry to its order — the link that was missing last round
  4. Open the case from that list and read the top of the record. Case Number in the highlights is the eight-digit number the client was given.
  5. Note the second form of the number. On the Details tab the Case Number field shows a longer, date-stamped version — the date, then the same eight digits. This is why searching had to be done on the last eight digits. The long date-stamped string is a display field; the number Salesforce actually stores and searches is the eight-digit one. Search the eight digits, or — better — reach the case from the order as you just did.
  6. Check the rest of the Details tab: Client Name is the practice, Client ID is their number, Type reads Supply Order Inquiry, Related Supply Order links back to the order you came from, and — further down, under System Information — Contact Name is the portal user who raised it.
    Case record — internal
    Client, Client ID, Type and Related Supply Order — all stamped automatically when the inquiry was raised; the contact sits lower down, under System Information
  7. Confirm Case Owner reads Supply Order Support — the queue, not a person. That is the routing working.
  8. Click the Related Supply Order link and confirm it takes you back to the right order. The link works in both directions.
Expected result
  • The inquiry appears in the order's Cases related list without any searching.
  • The case carries the client, the client ID, the contact, the type and a working link to the order.
  • It is owned by the Supply Order Support queue.
  • The eight-digit case number matches what the client was shown.
Result:
Scenario 2 · ~8 min SQL2-202 SQL2-27

Answer the client — one field, and the portal changes

Updated from your feedback Not run

What you're checking: the reply route that answers your question "where can the case status be seen in the portal?". Writing into Client Response on the case is what turns the client's order from "we're on it" into "there's an answer waiting", and prints your words on their order page.

  1. Open the case from Scenario 1 and go to the Details tab.
  2. Scroll to the Additional Information section. Client Response sits in the right-hand column, just below Case Resolution and beside Close Case Comments. It carries a help icon. Client Response is the only field on the case the client ever reads. Internal Comments and Close Case Comments stay inside Salesforce — write anything you would not say to the client's face in one of those instead.
  3. Click the pencil beside Client Response and type a real answer, for example "Thanks for checking. Your order left our Phoenix depot this morning and the courier is scheduled to deliver it tomorrow before noon."
    Case record — writing the reply
    Clicking one pencil opens the whole case as an edit form. Client Response is highlighted amber while it holds an unsaved change
  4. Click Save at the bottom of the form. Editing one field opens the whole case, so Salesforce also checks the other fields this case type requires. If Save stops with "We hit a snag" and points at Case Origin, set Case Origin to Email - Client Services - Web Inquiries and Save again — an inquiry raised in the portal arrives with PORTAL in that field, which is not one of the choices the edit form offers, and this is the value for requests that reach Client Services through the web. Please note in your comments whether this happened to you.
  5. Confirm the case saves and Client Response now shows your text on the record.
  6. Now look at the client's side. Ask your portal colleague to reload the order — or use a portal session yourself — and open the order the inquiry came from.
  7. Confirm the order page carries a Support case card marked Answered, holding the case number, the subject, an Opened date, an Answered date, and your words under Response from our team.
    Portal order page — after the reply
    The client sees the case flip to Answered and reads the reply in place, with no email to dig out
  8. Check the portal's My Order History list too: that order's row now carries an Inquiry answered tag where it previously said Inquiry open — type the order number into the list's search box if the order is not on the first page; the search finds it however old the order is.
    Portal My Order History — the answered tag
    The tag on the row is the at-a-glance answer to "where can I see the status of my case?"
  9. Read your own words back as a client would and note in your comments whether the wording and the placement work for a practice manager. This is the part where your judgement matters more than the mechanics.
Expected result
  • Client Response is on the case, editable, and saves.
  • The client's order page shows the Support case card as Answered with your reply under "Response from our team".
  • Their order list row changes from Inquiry open to Inquiry answered.
  • Nothing internal-only leaks to the client.
Result:
Scenario 3 · ~6 min SQL2-28

Take ownership and close the case properly

Not run

What you're checking: the rest of an agent's day — claiming a case out of the queue and closing it once the client has their answer, including the one thing the system will not let you skip.

  1. Open the case you answered in Scenario 2. Case Owner still reads Supply Order Support.
  2. Click Take Ownership in the header and confirm. Case Owner becomes your name — that is how a queue case becomes somebody's job.
  3. Click Close Case in the header.
  4. Try to close it without a comment first. Leave Close Case Comments empty and save.
  5. Confirm you are stopped with the message "Before Closing the Case need to enter value in Close Case Comment", pointing at that field. Nothing is lost — the form stays open. This is deliberate, and it is a rule for the whole business, not just supply orders — no case gets closed without someone writing down why. Close Case Comments stays internal; the client never sees it.
  6. Type a closing note — "Delivery date confirmed to client, no further action" — and save.
  7. Confirm Status is now Closed and a Date/Time Closed has been stamped.
  8. Check the Case History panel on the right: it lists the creation, the status changes, and who made each one, with times.
  9. Check the client's side once more. The order still shows the Support case card with the reply — closing the case internally does not take the answer away from them.
Expected result
  • Take Ownership moves the case from the queue to you.
  • Closing without a comment is refused with a message naming the field.
  • With a comment, the case closes and stamps a closed date.
  • Case History logs every step, and the client keeps their answer.
Result:
Scenario 4 · ~7 min SQL2-29

Move an order's status and watch the trail

Not run

What you're checking: the internal half of order tracking — that a status change saves cleanly, the Path bar keeps up, and the audit trail records who did what and when. It is also how you check the client's "Last Updated" is telling them the truth.

Use In Fulfillment or Shipped for this test, and use an order you placed yourself. Moving an order to Approved hands it to Workday for real.
  1. Open one of the orders you placed earlier from the client's Orders related list.
  2. Look at the Path bar under the highlights. Its stages are Draft · In Progress · Approved · In Fulfillment · Shipped · Denied · Canceled, with the current one picked out.
  3. Click the In Fulfillment stage on the Path and then Mark Status as Complete.
  4. Confirm the save completes with no error banner and the Path moves on. The Status field on the Details tab agrees with it.
  5. Open the Related tab and read Order History. A new row logs the status change — old value, new value, your name and the time.
  6. Check Order Products on the same tab: the line items and quantities, unchanged by the status move.
  7. Compare with the client's view. On the portal the same order's Order Progress card should show the new stage and a fresh Last Updated time, and its Order History should list the same change in plain words.
  8. Note in your comments how long the portal took to catch up. It should be immediate on reload.
Expected result
  • A status change saves cleanly and the Path highlights the new stage.
  • Order History logs the change with old value, new value, user and timestamp.
  • The client's order page shows the same stage and a matching Last Updated time.
Result:
Scenario 5 · ~5 min SQL2-66

The emails a client receives

Not run

What you're checking: that the notifications actually arrive and read well. This one needs a real inbox, so set it up before you start.

Order emails are sent without leaving a record behind on the order, so there is nothing to check inside Salesforce — an inbox is the only place to see them. Ask us to point a test contact at an address you can read before you begin, and check the junk folder as well as the inbox.
  1. Confirm which contact the notifications will go to: open the order and read Ship To Contact, then open that contact and note the email address on it.
  2. Place a fresh order for that client from Create Order, choosing that contact as the Ship To Contact.
  3. Check the inbox within a few minutes. A confirmation should arrive naming the order number.
  4. Read it as a client would: does the subject say which order it is about? Is the status stated in words a practice manager understands? Is the Sonora Quest logo showing?
  5. Now change that order's status as you did in Scenario 4 and check whether a second message arrives for the change.
  6. Note in your comments exactly which messages arrived, how long each took, and anything about the wording you would change. Wording feedback here is genuinely useful — it is easier to change than anything else in this guide.
Expected result
  • An order confirmation reaches the ship-to contact's inbox, naming the order.
  • The message identifies the order and its status in plain language, and renders with the Sonora Quest branding.
  • Your notes capture anything that reads badly, so it can be fixed before go-live.
Result:
All modules PB6

The account manager's review

Not started

Why you're testing this

This screen is where Phase 2 either saves the account managers time or costs them time. An order arrives over the allowance; the reviewer has to understand it in a few seconds and either let it through, trim it to something sensible, or send it back. Everything they need — what was asked for, what the client is entitled to, what the extra costs, and why the practice says they need it — is meant to be on one screen with no drilling. Test it as the person who has fifteen of these on a Monday morning.

Full story & acceptance criteria

SQL2-146 — Compliance Approval Process. An over-allowance order is routed to a named approver, held out of fulfilment while it waits, and resolved by an explicit decision that is recorded. Approving, adjusting and rejecting are all part of this one orchestration.

SQL2-163 — Proactive Notification System for Compliance Approvals. The reviewer is told an order is waiting rather than having to go looking, and the review itself gives them requested-versus-allowed, the cost impact and the provider's stated reason in one view — with a per-line note back to the client.

SQL2-149 — Override Tracking. "As a SonoraQuest compliance officer, I want to see exactly who approved an override, when they did it, and what they overrode so I can conduct retrospective compliance reviews." Every decision made on this screen is written to the audit trail you will read in module PB11.

Scenario 1 · ~6 min SQL2-146

Find the order that is waiting for you

Not run

What you're checking: that the review reaches the right person by itself. Nobody should have to run a report to discover an order is sitting on their desk.

Set this up before you start. The review is routed to the owner of the client record — the account manager, in other words. No backup approver is configured, so an order placed while somebody else owns the client lands on that person's desk and will sit there untouched. Open your test client and read Client Owner on the Details tab. If it is you, you are ready. If it is not, click Change Owner and make it you before you place anything — and say so to the group, because only one tester can hold the client at a time. Then place the over-limit order yourself: open the client, click Create Order and add PIPET TRANSFER W/GRADUATIONS (supply 900010). On the Review step read its ALLOWED number — three times the laboratory usage recorded in the last 90 days, less anything already ordered for this client in that time — and ask for more than double it. If you place the order first and change the owner afterwards it will not move — the approver is decided at the moment of submission.
  1. Confirm you own the client. Open the client record, go to the Details tab and check Client Owner reads your name.
  2. Place an over-limit order for that client — internally with Create Order from the client record, using the supply above and more than double its allowance. If you place it from the Client Supplies site instead, because you also test Track A, the allowance is the same one the internal view shows, so the same supply and quantity work. Note the order number.
  3. Check the bell. Within a minute or two a notification headed Approval Required should appear under the bell icon in the Salesforce header, naming the order and the client. Click it — it takes you to the order.
  4. Check your email. A message subject Action Required — Order 000… Pending Approval should also arrive, telling you the order requires your review and how long the window is. The email goes to the address on your Salesforce user record. If nothing arrives, check the address is one you can read and look in junk — and either way carry on with the bell notification, which is the primary route.
  5. Open the order record and look for the panel headed Order Items Waiting for Approval. It holds the review screen. This panel is deliberately invisible to everybody except the approver it belongs to, and it disappears the moment the order is decided. If you open somebody else's pending order, or an order that has already been resolved, you will not see it — that is correct behaviour, not a missing component.
  6. Check the order's own status while it waits: Status is In Progress and the Path bar sits on In Progress. Nothing has gone to Workday.
Expected result
  • The client's owner is notified by bell and by email, without going looking.
  • The notification leads to the order, and the order carries the review panel for that person.
  • The order sits on In Progress while it waits.
  • Other users do not see the review panel on the same order.
Result:
Scenario 2 · ~8 min SQL2-163

Read the review screen as an account manager would

Not run

What you're checking: whether the screen answers the reviewer's four questions — who asked, for how much over, what does it cost, and why — without them opening anything else.

  1. Open the review panel on your pending order.
    Compliance approval review
    The whole decision on one screen: who submitted it, how many lines, the total cost impact, then each line with requested against allowed and the reason it was flagged
  2. Read the three facts across the top: SUBMITTED BY, ITEMS TO REVIEW and TOTAL COST IMPACT. The cost figure is the money value of the extra units — not the order total.
  3. Read the line row. It carries the product name, a status chip, the unit of measure, and REQUESTED n → ALLOWED n. A bar underneath fills to the proportion the client is entitled to.
  4. Read the two explanations under the bar. One is arithmetic — n% over the allowed amount · $n cost impact. The other is FLAGGED FOR REVIEW followed by the rung of the ladder that escalated it — on the PIPET TRANSFER W/GRADUATIONS line above, "A requested quantity exceeds the client's allowed amount". A line can also be escalated on cost rather than quantity, and then reads "The order total exceeds the approved maximum cost". A line chipped No entitlement instead of Requires approval means the client's allowance for that product is zero — usually because they have already ordered their whole balance in the last 90 days. Approving it is still your call; the chip is telling you there is nothing left to draw on.
  5. Find the provider's reason. The category the practice chose in the portal (and any free text they added) is printed on the line as Provider's reason. Confirm it matches what was entered when the order was placed.
  6. Check the sentence above the lines: "Each line below is over the client's allowed amount. For every line, set the quantity you want to approve, or remove the line. If you remove every line, the order is denied." Note whether that is clear enough on a first read.
  7. Note what is not listed. If the order also contained lines that were within the allowance, or overages small enough to pass on their own, they are not shown here — a note at the bottom says how many were auto-approved and will ship as requested. Only what needs a human is on the screen.
Expected result
  • Submitter, line count and total cost impact are all visible without scrolling.
  • Each line shows requested against allowed, the percentage over, the cost impact and why it was flagged.
  • The provider's stated reason is on the line, not hidden on another record.
  • Lines that did not need a decision are summarised, not listed.
Result:
Scenario 3 · ~10 min SQL2-146 SQL2-149

Trim a line, write a note to the client, approve

Not run

What you're checking: the middle path, which is the one that will actually be used most — not a flat yes or no, but "you can have some of it, and here is why". Including whether the client ever finds out what you decided and on what grounds.

  1. Type a smaller number into Quantity to approve — the allowed figure beside it is a sensible choice, and it is the same figure whether you placed the order internally or from the portal. The box will not accept more than was requested, and it will not accept a fraction.
  2. Watch the recap above the buttons. It should change from Approving 1 of 1 line to Approving 1 of 1 line · 1 trimmed, and the green button should relabel itself from Approve order to Approve with changes. The screen tells you what you are about to do before you do it.
    Review screen with an adjusted quantity
    Quantity to approve dropped to the allowed figure. The recap now reads 1 trimmed and the button has become Approve with changes
  3. Fill in Reason for this line (shown to the client) with a sentence you would be happy for the practice to read — this text is printed on their order.
  4. Try the Remove from order switch on the line and watch the recap change to 1 removed, then switch it back off. If you removed every line the recap would tell you nothing will ship and steer you to Deny instead.
  5. Add a line into Comments — optional for an approval, required for a denial.
  6. Click Approve with changes and wait for the screen to finish.
  7. Check the order record. Status should now be Approved, the Path bar should have moved on, and in the Compliance Status section Compliance Locked should be ticked. The line's quantity should be the number you approved, not the number requested.
  8. Check the client's side. On the Client Supplies site, their order page should show the new quantity, the Approved stage, and your per-line note against the item.
    Client Supplies — the client's view after your decision
    Approved with changes: the order has moved to Approved, the Review Decision panel sums up what happened to the supplies, the reduced line says Reduced to 1 (3 requested) with your note printed right on the item, and a supply you removed stays listed under Removed from this order
  9. Check the email. The submitter should receive a message listing the supplies with the requested quantity, the approved quantity, and a status of Adjusted against anything you changed — with your reason in the last column.
Expected result
  • The quantity box will not accept more than was requested, or a fraction.
  • The recap and the button label change to describe the decision before it is made.
  • Approving moves the order to Approved and locks it, with the trimmed quantity saved.
  • The client sees the approved quantity and the reason you gave, on their own order page and in the email.
Result:
All modules PB7

Saying no, and saying why

Not started

Why you're testing this

A denial is the one outcome that will generate a phone call, so the system's job is to make sure the practice already knows the answer and the reason before they pick up the phone. Two things are being tested here: that the reviewer cannot deny an order silently, and that the reason travels all the way to the client's own order page rather than living in a Salesforce field nobody outside the building can see. Judge the tone of what the client ends up reading — that is the part only you can assess.

Full story & acceptance criteria

SQL2-146 — Compliance Approval Process. Rejection is a first-class outcome of the same orchestration as approval: the order is set to Denied, locked, the decision is logged, and the client is notified.

SQL2-148 — Post-Approval Locking Flow. Rejected orders are locked as well as approved ones — a decided order does not get quietly edited afterwards.

SQL2-163 — The reviewer records a reason per line and a comment for the order, and those words are what the client is shown.

Scenario 1 · ~8 min SQL2-146

Deny an order — and try to do it without a reason first

Not run

What you're checking: that a denial takes two deliberate actions and cannot be done without writing down why. This is the guard that stops an order being killed by a mis-click.

You need a second over-limit order in review — the one from module PB6 has already been approved. Place another the same way you did in PB6, on the client you own, but pick a different supply so you are not drawing on a balance you have just spent — APTIMA SPECIMEN TRANSFER KIT PRINTABLE 100T/KT (supply 40274), for example. Read its ALLOWED number on the Review step and ask for more than double it; if it reads 0 the balance is used up and any quantity is over. The Client Supplies site shows the same allowance, so the same order works from either side. The review window is 1 hour, so place the order and deny it in the same sitting — leave it longer and it releases itself, which is module PB8.
  1. Open the review panel on your second pending order.
  2. Leave Comments empty and click Deny entire order.
  3. Read the confirmation. A dialog appears headed Deny this entire order? and warns "Denying cancels every line on this order. To reduce or remove individual items instead, close this and adjust the lines above."
    Deny confirmation
    Denial takes two clicks and offers the gentler option first. Back to review returns to the lines with nothing lost
  4. Click Confirm deny with the comment box still empty. You should be stopped by a message headed Reason required asking you to add a comment explaining the denial. Nothing is saved.
  5. Click Back to review, then type a real reason into Comments — something the client could be told, such as "Your practice has already received this month's allocation of these supplies; please reorder after the 1st."
  6. Optionally add a per-line note in Reason for this line (shown to the client) as well. The order comment explains the decision; the line note explains the item.
  7. Click Deny entire order again, then Confirm deny.
  8. Check the order record. Status should read Denied, the Path bar should sit on Denied, and in the Compliance Status section Compliance Locked should be ticked.
    Order record — denied
    Status Denied, the Path bar moved to Denied, and the order still carries its full compliance history on the Compliance Log tab
Expected result
  • Denying requires a confirmation dialog, and the dialog offers the alternative of adjusting lines.
  • Confirming without a comment is refused with a message naming what is missing.
  • With a comment, the order moves to Denied and is locked.
  • Nothing about the order is lost — the lines, quantities and reasons all remain readable.
Result:
Scenario 2 · ~7 min SQL2-163

What the practice sees when the answer is no

Not run

What you're checking: that the client is told, in their own portal, that the order was declined and why — and that they have an obvious way to ask a follow-up question without ringing anyone.

  1. Open the Client Supplies site as the client (or ask your portal colleague to) and open My Order History from Client Supplies. The denied order's row should carry a Denied status.
  2. Open the order. The header carries a red Denied chip beside the order number, and the Order Progress bar sits on Denied.
    Client Supplies — a denied order
    The Review Decision panel turns red with one standard message and points to View Order for the supplies that were over the limit. Submit an Order Inquiry is right there for the follow-up question
  3. Read the Review Decision panel. On a denied order it is outlined in red and gives one standard message: "This order exceeds the agreed monthly allocation for this site. Please raise a separate request with your Account Manager if the volume is permanent." Under it, Comment from your Account Manager shows the comment you typed into Comments in Scenario 1 (a comment that only repeats the standard message is shown once), and the last line points to View Order, where each supply shows its allowance and how far over it was.
  4. Check the items card. Any per-line note the reviewer wrote appears against the item it belongs to. Anything the reviewer removed from the order is shown as removed rather than silently vanishing.
  5. Judge the wording as a practice manager. Does the client know what to do next? Is the reason specific enough to act on, or does it only make sense to someone who knows the engine? Write your answer in the comments — this is the most useful feedback in the module.
  6. Check that only View Order is offered — not Resume Order. A denied order is read-only to the client; they cannot edit it and resubmit.
  7. Click Submit an Order Inquiry and confirm the follow-up route works from a denied order exactly as it does from any other (the portal track walks through the inquiry itself).
  8. Check the email. The submitter should receive a message telling them the order was not approved, listing the supplies with a status of Unfulfilled and the reviewer's reason. As everywhere else in this guide, order emails leave no record inside Salesforce — a real inbox is the only place to check them.
Expected result
  • The client's order page shows Denied with a red Review Decision panel: the standard message, the comment the reviewer typed, and a pointer to View Order.
  • Per-line notes and removed lines are visible to the client, not only internally.
  • The order is read-only — View Order, never Resume Order.
  • An inquiry can be raised from the denied order, and a denial email reaches the submitter.
Result:
Scenario 3 · ~5 min SQL2-148

Confirm a denied order is finished with

Not run

What you're checking: that a denial is final and tidy — the review disappears, nothing goes to Workday, and the decision is on the record for anyone who asks later.

  1. Reload the denied order record. The Order Items Waiting for Approval panel should be gone — the decision has been made, so there is nothing to review.
  2. Check the Workday fields on the Details tab: Workday Order ID and Workday Order Integration Submittal should both be empty. A denied order is never handed to Workday.
  3. Open the Compliance Log tab on the order. The audit trail should end with a decision entry recording the rejection, the reason and who made it.
  4. Check Order History in the right-hand column: it should show the status moving to Denied, with your name and the time.
  5. Confirm the order still reads properly. Client, items, quantities, shipping and the client's original justification are all still there. A denial is a decision, not a deletion.
Expected result
  • The review panel is gone once the order is decided.
  • No Workday identifiers are stamped on a denied order.
  • The Compliance Log records the rejection with its reason and actor.
  • The order record remains complete and readable.
Result:
All modules PB8

When nobody reviews it in time

Not started

Why you're testing this

Account managers take holidays. The rule Sonora Quest chose is that a client should never be left waiting on a silent inbox: if nobody reviews an over-limit order inside the window, the system releases it by itself — at the quantity the client is entitled to, not the quantity they asked for. Nothing is ever auto-denied. This module is the safety net, and it is the one place in the guide where you have to wait for the clock, so start it early and do another module while it runs.

Full story & acceptance criteria

SQL2-147 — Approval Timeout Auto-Response. If no approver acts within the configured window, the order must resolve automatically rather than sitting indefinitely. Over-allowed lines are trimmed to the allowed quantity and the order is released; a line whose allowance is zero is removed; and if nothing survives, the order is cancelled rather than shipped empty. Either way the client is emailed the outcome.

SQL2-163 — The deadline is stamped on the order at the moment of submission, and the automatic release runs to that same stamp. The client is told the order is under review and that an email will confirm what shipped; the deadline itself is read on the order in Salesforce.

Scenario 1 · ~5 min, then a 1-hour wait SQL2-163

Start the clock and read what the client is promised

Not run

What you're checking: that the deadline is real — stamped on the order the moment it is placed — and that the client is told plainly the order is under review. Do this scenario first thing, then go and test another module while the hour runs — Scenario 2 picks the same order back up.

The review window is set to 1 hour in this environment so it can be tested in a single session. Confirm the current value for yourself in Compliance Configuration → Timing Windows → Approval Timeout Hours (module PB11) and note it in your comments, because the production figure is a decision Sonora Quest still has to make.
  1. Place an over-limit order exactly as you did in PB6, and this time do not review it. Leave it alone. Use a third supply so you are not drawing on a balance the earlier modules have spent — FORM IRREPLACEABLE SPECIMEN LOG (supply 900005), for example. On the Review step read its ALLOWED number and write it down: Scenario 2 checks the order is released at that quantity. It has to be 1 or more — with an allowance of 0 nothing is left to ship and the order ends the way Scenario 3 describes, so pick another of the four feed-backed supplies if that is what you see. Then ask for more than double the number. The Client Supplies site shows the same allowance, so the same order works from there too.
  2. Note the exact time you clicked Place Order, and the order number.
  3. Read the Submitted screen. It should be headed Pending Approval and read: "One or more items in this order exceed your allowed amount and are under review. You'll receive an email confirming exactly what shipped." There should be no countdown on the client's screen — the deadline is kept on the order, and you read it in the next step.
    Client Supplies — Submitted, pending approval
    The client is told the order is under review and that an email will confirm exactly what shipped. No clock is shown: the deadline is on the order in Salesforce
  4. Check the deadline internally. Open the order in Salesforce; the Approval Release At field holds the absolute deadline. Confirm it is the time you submitted plus 1 hour.
  5. Now go and do another module. Come back to Scenario 2 once the window has passed — give it a few minutes' grace, since the release runs on a scheduled sweep rather than to the exact second.
Expected result
  • The client is told the order is under review and that an email will confirm exactly what shipped.
  • Approval Release At on the order matches submission time plus the configured window.
Result:
Scenario 2 · ~8 min (after the window has passed) SQL2-147

Come back after the window — the order released itself

Not run

What you're checking: the auto-release. The order should have moved on by itself, at the entitled quantity, and the client should be able to see exactly what changed.

  1. Open your Scenario 1 order in Salesforce.
  2. Check the status. Status should now be Approved — released, not denied. The order is on its way.
  3. Check the Compliance Status section. Compliance Status reads Auto Released, Compliance Locked is ticked, and Max Line Compliance Status still records what the line was flagged as before the release. The order remembers that it was over the limit.
  4. Check the quantity — this is the point of the whole module. Open Related → Order Products. The line's quantity should now be the allowed figure you wrote down in Scenario 1, not the figure the client asked for — the same whether you placed the order internally or on the portal, and lower only if another order for the same supply was approved for this client in the meantime. The engine shipped what they were entitled to. Nothing is auto-denied, ever. An unreviewed order is trimmed to the entitlement and released. The only case that ends in a cancellation is Scenario 3, where trimming leaves nothing at all to ship.
  5. Open the Compliance Log tab. The trail should end with an Auto-Released entry whose source is the timeout path and whose reason says, in words, that no action was taken inside the window so the client's entitlement was shipped.
    Order — Compliance Log after the auto-release
    The whole life of the order in one trail: Submitted, Evaluated with 120 → 50 and the cut percentage, Requires Approval, then Auto-Released with the reason spelled out
  6. Look at the client's side. On the Client Supplies site the order now shows Approved, the item quantity is the trimmed figure, the item itself says so (for example Reduced to 1 (3 requested)), and the Review Decision panel says how many supplies were reduced and why, for example "1 of your 3 supplies was over the agreed monthly allocation for this site and was reduced."
    Client Supplies — after the auto-release
    One supply was cut from 70 to 50, the client's allowance, and the panel says so in one sentence. View Order only: the order is locked
  7. Check My Order History: the row should have moved out of In Review and now reads the trimmed quantity.
  8. Check the inbox. An email should confirm the outcome and list what actually shipped against what was requested.
  9. Judge it. Would a practice manager understand, from the portal alone, that they received less than they asked for and why? Say so in your comments — this is the scenario most likely to generate a phone call at go-live.
Expected result
  • The order released itself to Approved without anybody touching it.
  • The line quantity is the allowed figure, not the requested figure.
  • The order is locked and the Compliance Log records the auto-release with its reason.
  • The client can see the new quantity and why, and receives an email saying so.
Result:
Scenario 3 · ~6 min SQL2-147

The other ending: nothing left to ship

Not run

What you're checking: the second half of the timeout rule. If every line on an unreviewed order trims to zero there is nothing to send, and the order is cancelled rather than shipped empty. You are reading an order this already happened to.

Ask us for the order number before you start. Producing this outcome to order means driving a client's allowance to exactly zero and then waiting out the window again, which is not a good use of your session — so we will point you at an order that already timed out with nothing surviving. Reading it proves the same rule.
  1. Open the order we give you and check Status reads Canceled, not Denied. The distinction matters: nobody rejected this order, there was simply nothing left to send.
  2. Check the Compliance Status section. Compliance Status reads Auto Released — the same timeout path — while Compliance Locked is ticked.
  3. Open the Compliance Log tab and read the trail. It should record the lines being removed and then the cancellation, each with its own reason, so an auditor can see the order was emptied by the rule rather than by a person.
  4. Check the Workday fields on the Details tab: Workday Order ID and Workday Order Integration Submittal should be empty. A cancelled order is never handed over.
  5. Compare the two endings side by side with your Scenario 2 order and confirm you can explain the difference in one sentence: lines survived, so it shipped; nothing survived, so it was cancelled.
  6. Consider the client's experience. Note in your comments whether "Canceled" with the reason shown is enough for a practice whose order simply evaporated, or whether that case needs a dedicated message.
Expected result
  • An unreviewed order with no surviving lines ends as Canceled, not Denied.
  • It carries the same Auto Released compliance status and is locked.
  • The Compliance Log shows the line removals and the cancellation with reasons.
  • Nothing is handed to Workday.
Result:
All modules PB9

Locking a decided order

Not started

Why you're testing this

Once a decision has been made, the order it was made about must stop moving. Otherwise the audit trail says one thing and the shipment says another — which is exactly the problem the compliance engine exists to solve. This module checks the lock is applied to every kind of decided order, that the client cannot get back in and change it, and that the reason the practice gave for the overage survives the whole journey and is still there for anyone reviewing it later.

Full story & acceptance criteria

SQL2-148 — Post-Approval Locking Flow. An order that has been through a compliance decision is locked. Approved, adjusted, rejected and auto-released orders are all locked — the lock records that the order is settled, not that it was successful.

SQL2-143 — Justification Prompt and Capture (LWC). "Every line the engine flagged for justification must have one before the order can move on." The reason is stored on the order line, rolled up to the order header, and is what the approver and the auditor both read.

SQL2-149 — Override Tracking. Who decided, when, and what they overrode has to be answerable after the fact.

Scenario 1 · ~7 min SQL2-148

Every decided order carries the lock

Not run

What you're checking: that the lock is applied consistently, whatever the answer was — and that the record still says what the decision was, so the lock is not hiding anything.

  1. Collect the three orders you have made so far: the one you approved in module PB6, the one you denied in module PB7, and the one that auto-released in module PB8.
  2. Open each one in Salesforce and scroll the Details tab to the Compliance Status section.
    Order record — the Compliance Status section
    Everything the engine decided, in one block: status, the reason, whether approval was required, the client's justification, the configuration version used — and Compliance Locked ticked
  3. Confirm Compliance Locked is ticked on all three. Approval, denial and auto-release all lock the order. The lock means "settled", not "successful".
  4. Read the rest of the block on each and confirm it still tells the story: Compliance Status (the outcome), Compliance Decision Reason (which rung of the ladder decided it), Max Line Compliance Status (the worst any single line reached), Compliance Requires Approval, and Last Compliance Evaluation.
  5. Note Compliance Config Version. It records which version of the compliance rules was in force when this order was judged — so a decision made last quarter can still be explained after the thresholds change. This is the field that answers "why was that allowed in June but not now?" without anyone having to remember. It should match the version shown at the bottom of the Compliance Configuration page (module PB11).
  6. Check a Draft order for contrast. Open any order still in Draft and confirm Compliance Locked is unticked and Compliance Status reads Not Evaluated. Orders are only locked once the engine has finished with them.
Expected result
  • Approved, denied and auto-released orders are all Compliance Locked.
  • The compliance block still records the outcome, the reason and the evaluation time after locking.
  • Compliance Config Version is stamped so a past decision can be explained later.
  • A Draft order is neither evaluated nor locked.
Result:
Scenario 2 · ~7 min SQL2-148

The client cannot reopen a decided order

Not run

What you're checking: the half of the lock that a practice will actually meet. Once a decision is made, the client's order becomes something to read, not something to edit.

  1. Open the Client Supplies site and open My Order History from Client Supplies.
  2. Find a Draft order first — its row offers Resume Order, which reopens the wizard so the client can carry on editing.
  3. Now open your approved, denied and auto-released orders. Each should offer View Order and not Resume Order.
    Client Supplies — a decided order is read-only
    View Order and Submit an Order Inquiry, and nothing else. There is no route back into the wizard for an order that has been decided
  4. Click View Order on the auto-released one and confirm the quantities are shown as text with no editable boxes, no Remove control and no Save.
  5. Confirm the released quantity is the one displayed — the trimmed figure, not what was originally requested. The client's view agrees with what will actually ship.
  6. Confirm the follow-up route still works. Submit an Order Inquiry should still be available: locked means the client cannot change the order, not that they cannot ask about it.
  7. Try the reorder route. Reorder should create a brand-new draft rather than reopening the locked one. Check the new draft has its own order number and that the original is untouched.
Expected result
  • Drafts offer Resume Order; decided orders offer View Order only.
  • A decided order shows quantities as read-only text with no editing controls.
  • The client can still raise an inquiry and still reorder into a new draft.
  • The original locked order is never modified by either action.
Result:
Scenario 3 · ~7 min SQL2-143 SQL2-149

The justification survives the whole journey

Not run

What you're checking: that the reason a practice typed on the Review step is still findable weeks later, on the order, on the line, and in the audit trail — and that nothing could have got past the gate without one.

  1. Open one of your over-limit orders in Salesforce and go to the Compliance Status section.
  2. Find Compliance Justification on the order header. It should hold the reason the client gave, prefixed with the product it belonged to — for example "LABEL ZEBRA FIELD ACCESSIONING: New Patient Onboarding". Where several lines were flagged, all their reasons are rolled up here.
  3. Confirm Compliance Justification Required is ticked on the same order. That is the engine recording that this order was not allowed to be submitted without one.
  4. Go to the line. Open Related → Order Products and open the flagged line. Its own Decision Reason Code holds the category the client picked and Compliance Justification holds the text. The line also keeps Allowed Quantity, Cut Percentage, Cost Delta and Already Issued Qty — the numbers the decision was made on, frozen at the time.
  5. Prove the gate. Start a new over-limit order in the portal and, without filling in a justification, try to move past Review Order. Continue stays disabled and the amber n item(s) need justification button stays in its place. There is no route past it — abandon that draft when you have satisfied yourself.
  6. Check the approver's copy. Whatever the client wrote is printed on the review screen as Provider's reason (module PB6), so the person deciding sees the practice's own words rather than a code.
  7. Check the auditor's copy. Open the Compliance Log tab on the order — the evaluation entry records the requested and allowed quantities and the reason the line was flagged, and any decision entry records who acted and what they changed.
Expected result
  • The client's justification is on the order header and on the flagged line.
  • The line keeps the numbers the decision was based on, not just the outcome.
  • An over-limit order cannot be advanced past Review without a justification.
  • The same reason is visible to the approver and in the audit trail.
Result:
All modules PB10

Recurring orders meet the engine

Not started

Why you're testing this

A recurring order is placed by a schedule at two in the morning, with nobody at the keyboard to answer a justification prompt. Until now those deliveries were created as drafts and sat there. They now go through exactly the same compliance engine as a hand-placed order and come out the other side approved, sent for review, or declined — and if a delivery is declined, both the practice and their account manager are told, because nobody is watching the portal at that hour. This module pairs with module PB4, which covers the templates themselves.

Full story & acceptance criteria

SQL2-146 — Compliance Approval Process. The same routing applies whatever created the order. A scheduled delivery that breaches the allowance is held for the account manager just as a portal order would be.

SQL2-135 — Order-Level Status Aggregation. One problematic line sets the outcome for the whole delivery; deliveries are never split.

SQL2-179 — UAT feedback round. Recurring deliveries running through compliance automatically is new since the last round of testing. Anything you saw in the previous build about recurring orders arriving as drafts no longer applies.

Scenario 1 · ~8 min SQL2-146 Updated from your feedback

A scheduled delivery arrives already judged

Not run

What you're checking: that a delivery created by the schedule is a real submitted order, not a draft waiting for someone to press a button — and that you can tell at a glance which ones need attention.

The schedule runs once a day, in the small hours. To see a delivery appear you either wait for the overnight run, or use the time-travel trick from module PB4: set your template's next run date to today, then come back tomorrow morning. For today, work with deliveries that already exist — every template has a Generated Orders list. If you are building your own template to watch this happen, put PIPET TRANSFER W/GRADUATIONS (supply 900010) on it at more than double the ALLOWED number the Review step shows for it. That is one of only four supplies with real laboratory history behind it for test client 77777, so its allowance comes from usage — three times what was recorded in the last 90 days, less what has already been ordered — which makes it an easy one to push over. Every other supply falls back to an allowance of 50.
  1. Open your recurring template (module PB4 covers creating one) and click the Generated Orders tab in the right-hand column. Every delivery the schedule has produced is listed there.
  2. Open one of the deliveries created since compliance went live and look at its Status. It should be Approved, In Progress or Denied — never Draft. Deliveries generated before this change are still sitting at Draft with a compliance status of Not Evaluated. Those are historical and are not a Fail — check the created date before you judge a Draft.
  3. Check Order Source on the Details tab. A scheduled delivery reads Recurring, which is how you tell it apart from a portal order or one placed on the phone.
    Order record — a recurring delivery the engine flagged
    Status In Progress, Order Source: Recurring, and the Path bar sitting on In Progress. Nobody placed this order — the schedule created it, the engine evaluated it, and because it was over the allowance it went straight to the account manager for review
  4. Read the Compliance Status section and confirm the delivery carries a real decision: a compliance status, a decision reason and an evaluation timestamp. It went through the same engine as everything else.
  5. Compare several deliveries. Different quantities against the same allowance produce different outcomes on the same template — an early delivery may be Approved and a later one held, because each delivery deducts from the balance the next one draws on.
  6. Check the client's list. On the Client Supplies site, My Order History shows the deliveries alongside hand-placed orders, with the same statuses and tabs.
    Client Supplies — My Order History
    Deliveries appear in the client's own list with the outcome already decided. The At a glance panel counts how many are awaiting review
Expected result
  • Deliveries created since this change are submitted orders, not drafts.
  • Each carries Order Source Recurring and a real compliance decision.
  • Outcomes differ between deliveries on the same template as the allowance is drawn down.
  • The client sees the deliveries and their outcomes in My Order History.
Result:
Scenario 2 · ~7 min SQL2-179 Updated from your feedback

A declined delivery tells two people, not none

Not run

What you're checking: the case that worried us most — a delivery the practice was counting on quietly not happening. When the engine declines a scheduled delivery, both the client and the account manager get an email, because no one is at the screen to notice.

  1. Find a flagged delivery — one with Order Source = Recurring that the engine sent to review (In Progress) or that the account manager has since denied (Denied). Ask us for one if your own template has not produced one yet.
  2. Read the Compliance Decision Reason and satisfy yourself you can explain, in one sentence, why the engine declined this delivery.
  3. Check the client's inbox. A message should have gone to the ship-to contact telling them the delivery was not approved, naming the order.
  4. Check the account manager's inbox. A second message goes to the internal side — that is the point of the change. The practice's manager finds out at the same time the practice does. Both messages are sent without leaving a record on the order, so an inbox is the only place to check. Ask us to point the ship-to contact and your own user record at addresses you can read before you begin. If your test data is not set up that way, say so in your comments rather than marking a Fail.
  5. Look at the client's order page on the Client Supplies site. It should carry the Denied chip and a red Review Decision panel with the reason, exactly as a hand-placed denial does (module PB7).
  6. Check the template is unharmed. Go back to the template record: a declined delivery must not pause or cancel the schedule. Next Run Date should still be set and the template still Active.
  7. Judge the wording. A practice reading this email may have been relying on that delivery. Is it clear enough about what they should do next? Write your answer in the comments.
Expected result
  • A declined delivery emails both the client and the account manager.
  • The client's order page shows Denied with a readable reason.
  • The template keeps running — one declined delivery does not stop the schedule.
Result:
Scenario 3 · ~6 min SQL2-135

A delivery that needs a human goes into the same queue

Not run

What you're checking: that a scheduled delivery over the allowance is treated as a real approval, not a special case — same reviewer, same screen, same window, same audit trail.

  1. Find a delivery sitting at In Progress with Order Source Recurring. Ask us for one if you have none.
  2. Open the Compliance Log tab on it. You should see the submission and the evaluation recorded exactly as they are on a portal order — with the actor recorded as the automated process rather than a person.
  3. Check who it is with. The reviewer is the client's account manager, the same as in module PB6. If that is you, the review panel is on the record and you can decide it now.
  4. Note the difference in the justification. A scheduled delivery has no one to type a reason, so there is no provider justification on the line — the reviewer decides on the numbers alone. Note in your comments whether that is enough context for a real decision.
  5. Check the timeout applies too. The delivery carries an Approval Release At deadline like any other order, set to one hour after submission in this environment. If nobody reviews it, it releases at the allowed quantity (module PB8) rather than being lost.
  6. Look at the client's view. The delivery appears under In Review in My Order History with the engine's reason on the order page — the practice can see it is being looked at without ringing anyone.
Expected result
  • An over-allowance delivery is routed to the client's account manager like any other order.
  • Its Compliance Log records the submission and evaluation with the automated process as the actor.
  • The same review window and auto-release apply.
  • The client can see it is in review from their own order list.
Result:
All modules PB11

Running the engine day to day

Not started

Why you're testing this

Everything so far has been one order at a time. This module is the operational view: the audit trail that answers "why did that happen", the two dashboards that answer "what is happening across all clients", the page where the thresholds themselves are changed, and the fields that carry an approved order across to Workday. If you are going to own this engine after go-live, this is your module — and the wording, the labels and the defaults are all still changeable.

Full story & acceptance criteria

SQL2-145 — Evaluation Log Persistence Logic. "As a SonoraQuest compliance officer, I want every compliance evaluation automatically logged with complete details so I have a reliable audit trail of all decisions the system has made."

SQL2-149 — Override Tracking. "As a SonoraQuest compliance officer, I want to see exactly who approved an override, when they did it, and what they overrode so I can conduct retrospective compliance reviews."

SQL2-151 — Approval Queue Dashboard. "As a SonoraQuest operations manager, I want a dashboard showing how many orders are waiting for approval, how long they have been waiting, and how quickly approvers are responding so I can manage the team's workload and avoid bottlenecks."

SQL2-150 — Operational Compliance Dashboards. Decision volume, the clients most often over their allowance, the trend between automatic and manual routing, and cost exposure by status.

SQL2-180 / SQL2-181 / SQL2-193 / SQL2-201 — the Workday items from the last round of feedback: item and unit-of-measure mapping, the sync that stopped after a stale integration handshake, the Workday identifier not being visible to internal staff, and the question of whether a portal order number can be searched in Workday.

Scenario 1 · ~8 min SQL2-145 SQL2-149

Read the audit trail of a single order

Not run

What you're checking: that every order can answer "what happened to me and why" without anyone needing access to a developer. This is the record a compliance review would be conducted from.

  1. Open the order that auto-released in module PB8 — it has the longest story — and click the Compliance Log tab.
  2. Read the header. It is titled Compliance Audit Log and subtitled Immutable transaction trace · Order. Nothing here can be edited by anyone.
    Order — Compliance Log tab
    Counts across the top, filter chips underneath, then the trail: time, event, the item and scope, requested against allowed, where it came from, why, and who
  3. Read the counts across the top: TOTAL EVENTS, COMPLIANT, FLAGGED, LINE REMOVED and DECISIONS. Check they agree with what you know happened to this order.
  4. Read the trail from the bottom up — it runs newest first. You should be able to follow: the order was submitted, each line was evaluated with its requested and allowed quantities, the order was routed for approval, and finally what resolved it.
  5. Read one evaluation row in full. The REQUESTED → ALLOWED column shows both numbers and the cut percentage; SOURCE names what triggered the evaluation; REASON gives it in a sentence; ACTOR names the person or the automated process.
  6. Use the filter chips — Lifecycle, Evaluation, Decisions, Line Changes — and confirm each narrows the list and that the counts on the chips are right.
  7. Use the search box to find an entry by product name or reason.
  8. Now widen out. Open the client record and click its own Compliance Log tab — the same trail across every order for that practice.
    Client record — Compliance Log tab
    The same audit view scoped to the whole practice, which is where a "why does this client keep going over?" conversation starts
Expected result
  • Every order has a Compliance Log tab with a complete, readable trail.
  • Evaluations show requested against allowed with a reason and an actor.
  • Filters and search narrow the list correctly.
  • The same view exists on the client record across all their orders.
Result:
Scenario 2 · ~8 min SQL2-151 SQL2-150

The two dashboards

Not run

What you're checking: the management view. One dashboard answers "what is on my desk right now", the other answers "how is this engine behaving across the business". Both need to be useful on a Monday morning without anyone explaining them.

Click Refresh on each dashboard before you judge it. Salesforce dashboards show a cached snapshot until somebody refreshes them, and a banner at the top will tell you how old it is — often months. Tables in particular say "To view this table, refresh the dashboard" until you do. An out-of-date dashboard is not a Fail; an out-of-date dashboard after you refresh it is.
  1. Click Compliance Engine Dashboard in the app's top navigation bar.
  2. Click Refresh and wait for the components to fill in.
    Compliance Engine Dashboard
    My Orders Waiting for Approval as a number and as a list, Auto-Released Orders, an auto-approval gauge and the approval timeline. The Refresh button re-runs every tile on demand
  3. Read My Orders Waiting for Approval — the big number and the table beside it. It is scoped to you, so if you have a pending order from module PB6 or PB7 it should be counted here. Click View Report under it and confirm the report opens with the same orders.
  4. Read Auto-Released Orders — how many orders nobody reviewed in time. In a live business this is the number that tells you the approval process is not being staffed.
  5. Read the auto-approval gauge and the Approval Timeline chart. Note in your comments whether the split between what the engine handled by itself and what needed a person is the figure you would want on a management report.
  6. Now open the second dashboard. Go to Dashboards, find the Compliance Engine Monitoring folder and open Compliance Engine Monitoring. Refresh it.
    Compliance Engine Monitoring
    Decision volume, the clients most often over their allowance, the routing trend, and cost exposure by status — the business-wide view
  7. Read its four charts: Compliance Decision Volume, Top At-Risk Clients (the practices with the most over-allowance orders), Routing Trend Over Time and Cost Exposure by Status.
  8. Say what is missing. Between them these two dashboards are the whole management view of Phase 2. Note in your comments any question you would expect to answer from a dashboard and cannot.
Expected result
  • Both dashboards open and populate after a refresh.
  • My Orders Waiting for Approval reflects the orders actually assigned to you.
  • Every component's View Report link opens a matching report.
  • Your notes capture anything a manager would need and cannot get.
Result:
Scenario 3 · ~9 min SQL2-150

Where the rules themselves live

Not run

What you're checking: the page that decides everything you have tested in this track. Sonora Quest owns these numbers after go-live, so the question is whether this page explains them well enough for someone to change one on purpose. Read only — do not change a value.

Please do not save a change here during UAT. These settings apply to every client and every order immediately, and altering one mid-session will change what other testers see. Read the page, note what you would change, and tell us — do not press Save.
  1. Click Compliance Configuration in the app's top navigation bar. The page is headed Review & edit rules with the active record named beside it.
  2. Expand Thresholds & Limits. It lays out the engine as a numbered ladder, and its subtitle tells you the rule that matters: evaluated top-down — the first rung that matches decides each order line.
    Compliance Configuration — the decision ladder
    Each rung states what it does, what it produces, the live value, and a worked example. This page is the plain-English specification of the whole engine
  3. Read the ladder and match each rung to what you have seen in this track — the fallback allowance for a client with no history, orders that pass untouched, tiny cheap overages that are auto-approved silently, a per-line cost ceiling that always escalates, and the cut check that either auto-approves with a justification or sends the order for review. Today those numbers read: fallback allowance 50 units, low-dollar threshold $5, maximum cost $200 per line, cut threshold 20% and an overage factor of 2.0.
  4. Read the worked example under each rung. Check the arithmetic against an order you actually placed and confirm the engine behaved the way the page says it will.
  5. Expand Timing Windows and read the three values: how many days of usage history feed the allowance (90 days), how many days of recent orders are deducted from it (90 days), and how many hours a pending approval waits before releasing itself (1 hour, deliberately short so the timeout can be tested in one session). Confirm the last one matches the gap between the time you placed the order and its Approval Release At in module PB8.
  6. Expand Admin Ratios and note the three multipliers for POL, IOP and Global — the "allowed portion" the client sees in their own breakdown on the portal's Review step. All three currently read 3.0 — three times measured usage, shown to the client as 300%. Their being identical is deliberate rather than a data error: it is a permissive cushion for go-live that Sonora Quest will dial down as real usage history builds up.
  7. Expand Activation & Behavior. It holds two fields: Is Active — exactly one configuration record is live at a time — and Utilization DMO API Name, the Data Cloud object the allowances are read from. Note what is not here: there is no switch that turns the usage feed off. Data Cloud is the only source, and an outage blocks orders rather than falling back to guessed data. That is a deliberate choice and worth confirming Sonora Quest agrees with it. Portal and internal orders read the same usage feed. Until September 29 this section carried two switches, Use Data Cloud and Allow External DMO Access. Both were removed, so no setting can send an order — from the portal or from Salesforce — to estimated figures. The 50-unit estimate and the Limit Estimated chip belong only to a supply the client has no usage history for.
  8. Expand Duplicate Detection and read the two settings behind the duplicate-order warning testers saw on the Review step: the window is 168 hours (seven days) and the match mode is exact.
  9. Check the footer. It shows when the configuration was last changed and its Config version — the same string stamped on every order the engine judges (module PB9). It currently reads 2026.09.v4-UAT. An order judged before the settings were last changed keeps the older version string, which is the whole point of stamping it.
Expected result
  • The configuration page opens from the navigation bar and shows the live values.
  • The ladder explains, in order, how a line is decided, with a worked example per rung.
  • The values on the page match the behaviour you saw across the compliance modules of both tracks.
  • The footer names the configuration version stamped on orders.
Result:
Scenario 4 · ~7 min SQL2-193 SQL2-201

What crosses over to Workday, and what does not

Updated from your feedback Not run

What you're checking: the handover at the end of the chain, and the three things you raised about it last round — the Workday identifier you could not see, the sync that stopped, and whether a portal order number can be used to find an order in Workday.

  1. Open an approved order and scroll the Details tab to the Workday fields.
    Order record — the Workday fields
    Workday Order ID, Workday Order Integration Submittal, WD Location Reference ID and Workday Error — all visible to internal staff, which is the SQL2-193 fix
  2. Confirm you can see all four: Workday Order ID, Workday Order Integration Submittal (the time it was handed over), WD Location Reference ID and Workday Error. Last round these were visible in the portal but not to you internally; that has been corrected.
  3. Compare a decided order with a pending one. The Workday Order Integration Submittal timestamp appears only once an order reaches Approved — the whole point of holding over-limit orders at In Progress is that nothing crosses over until somebody has said yes.
  4. Check a denied order. Its Workday fields should be empty. Nothing declined is ever handed over.
  5. Check Workday Error. If a hand-off fails, the reason is written here. Note in your comments whether an empty field is enough to tell you a hand-off succeeded, or whether you would want a positive confirmation instead. Your SQL2-180 finding — only one item made it across — was an item-mapping problem, not a Salesforce one. Each product has to carry a Workday item identifier and a stocking unit of measure, and a single unmapped line rejects the whole order at the Workday end. If a hand-off fails during your testing, tell us the order number and the product rather than retrying.
  6. Look at the line level. Open Related → Order Products, open a line, and find its Workday item identifier. That is the value Workday matches on.
  7. Settle the SQL2-201 question for yourself. The Salesforce order number — the 000… you have been quoting all through this guide — is not sent to Workday and cannot be searched there. The link between the two systems is the Workday Order ID stamped back onto this record. Confirm that is what you see, and tell us if you need the order number carried across in the order memo instead.
  8. If nothing has synced at all during your session, say so with a time — a stale integration handshake was the cause of your SQL2-181 finding and it is fixed by restarting the integration at our end, not by anything you can do.
Expected result
  • All four Workday fields are visible to internal staff on the order.
  • Only approved orders carry a hand-off timestamp; denied and pending orders do not.
  • Order lines carry the Workday item identifier used for matching.
  • You can state whether the Workday Order ID alone is enough for your team to reconcile the two systems.
Result:
All modules PHASE 1

Phase 1 fixes

Why this page exists

Round one produced 23 items — failures, questions and suggestions. Every one of them was investigated, and every one is answered below: what you reported, what we found, what we did, and exactly where to check it this time.

Two things worth knowing before you read on. First, most of the "field is not displayed" failures were the same single cause — the tester account was missing the permission set that grants visibility of the ordering fields. Nothing was broken; it was invisible. Second, seven of your items were suggestions rather than faults ("it is a PASS, but…"), and we built all of them.

Fixed a genuine defect, corrected Access the feature worked; the account could not see it Built your suggestion, now part of the product Answered a question, with the answer below

Built from your suggestions

BuiltSQL2-196

"It might be valuable to see the list of items and qty… I need to open each draft to know which is which."

What we did: rebuilt My Order History and the order page around that sentence. Each row now names what is inside the order ("2 items · 2 units — the supplies on that order"), and opening an order shows an Items card with pictures, quantities and units — no need to resume a draft to find out what is in it. The list also gained search, counted tabs, and pages of ten.

Check it in: PA7 · My Order History & the order page, Scenarios 1–3.

BuiltSQL2-199

"When the recurring order is opened in the portal, you cannot tell what supplies will be delivered — a mystery box."

What we did: the mystery box is open. My Order History has a Recurring tab listing your standing orders; expanding one shows every delivery it has already produced, and opening it shows the items it will ship plus its schedule and next run date.

Check it in: PA7 · My Order History & the order page, Scenarios 4–5.

BuiltSQL2-185

"Cannot remove an item on this screen — I need to go back to Select Items to do it."

What we did: added a Remove control to every line on Review Order. It asks once (the button changes to Confirm?) so a stray click cannot delete a line. Removing the last remaining line is refused with an explanation, because an order needs at least one item.

Check it in: PA3 · Review, confirm & polish and again inside PA6 · Reordering.

BuiltSQL2-197

"It might be useful to modify delivery comments, location and quantities on the Reorder screen — sites differ in size and staffing."

What we did: this already existed, but the journey was not obvious, so the guide now teaches it properly. Reorder does not place an order — it copies the old one into a fresh draft and opens it in the ordering wizard, where you can change quantities, remove lines, pick a different location and write new delivery comments before anything is placed.

Check it in: PA6 · Reordering, the whole module.

BuiltSQL2-198

"It might be useful to have a picture of the item in the quantity representing the ordering unit of measure."

What we did: every product now carries a unit badge — an icon and a word such as Case, Box or Vial — next to its supply number, repeated in your cart, on Review Order and on the finished order. Hovering it spells out the unit in full. Photographs of each product's actual case or box are a separate piece of work with our marketing team; the badge answers "how does this ship?" today.

Check it in: PA2 · Wizard UX and PA4 · Catalog deep-dive.

BuiltSQL2-200

"Can the Create Order button be bolded? It took a while to find it — too many buttons on the same screen."

What we did: Salesforce cannot bold a button, so we did the next best thing — Create Order is now the first action on the client record, before every other button, instead of hiding in the overflow menu.

Check it in: PB1 · Order on behalf of a client, Scenario 2.

BuiltSQL2-202

"Where can the case status be seen in the Provider Portal?"

What we did: nowhere — you were right, so we built it. An order with an open inquiry is tagged Inquiry open in My Order History, and the order page carries a Support case card with its number, subject and status. When our team answers, the tag turns green — Inquiry answered — and their reply appears on the order page under "Response from our team".

Check it in: PA8 · Support requests & notifications, and the internal half in PB5 · Manage orders, cases & notifications.

Defects we fixed

FixedSQL2-183

"Review Template doesn't open after clicking View Template. No notice about a blocked popup."

What we did: your diagnosis was right that this was not a permissions problem. The template link was doing nothing at all from inside the order window, so nothing ever appeared. It now opens the template in a new browser tab. If your browser is set to block pop-ups it will show its own blocked-pop-up indicator in the address bar — allow it once for this site and the tab opens.

Check it in: PB4 · Recurring orders (internal).

FixedSQL2-184

"Copy order number shows 'copied' but is not populating."

What we did: the copy control was reporting success while writing nothing. Rewritten so it genuinely copies the order number — paste it somewhere to prove it.

Check it in: PB4 · Recurring orders (internal).

FixedSQL2-182

"Unable to find the case unless the last 8 digits are searched. The case number is not connected to the order."

What we did: an inquiry now records the order it came from, together with the client and the contact who raised it, so the case and the order are linked in both directions. The subject arrives pre-written as "Supply Order 000… Inquiry", which is also what makes it findable by search.

Check it in: PA8 · Support requests and PB5 · Manage orders, cases & notifications.

FixedSQL2-186

"Client can be found by ID number or by name. Both at the same time do not work together."

What we did: corrected how client search is described in the guide. Search itself is unchanged: the ID works, the name works, and the two together work when separated by a space — only the record heading, with its hyphen, finds nothing.

Check it in: PB1 · Order on behalf of a client.

FixedSQL2-195

"There is no 'Recent Order', only 'Resume Order'."

What we did: the guide was wrong, not the build — so the guide was corrected and swept for every other control name that did not match what shipped. For the record, the buttons are Resume Order on a draft, View Order on one already placed, and Reorder to copy a finished order into a new one.

Check it in: PA6 · Reordering and PA7 · My Order History.

It worked — the account could not see it

Six of your ten failures were one problem wearing six hats. Field visibility in Salesforce comes from a permission set, and the test account was missing the one for ordering — so price books, addresses, record types and Workday identifiers were simply not on screen. Administrator rights do not override that. Every tester for this round has the permission set; if a field named below is still missing, that is a genuine finding and we want it.

AccessSQL2-187

The root cause: the ordering permission set was not assigned

What we did: assigned the Provider Order Management permission set to every tester and confirmed it on each account before this round.

Check it in: everywhere — if the fields below appear, this is proven.

AccessSQL2-188SQL2-189

"Price Book and Exclusive Product Access are not visible under Account Detail" / "…cannot be found under the client"

What we did: nothing to the build — the fields were always there. With the permission set in place they appear on the client record, and switching exclusive access changes which products that client can order.

Check it in: PB2 · Catalog management.

AccessSQL2-190SQL2-191SQL2-192

"Address field is not displayed" / "Record Type is not displayed in New Facility Location" / "Status and address are not available"

What we did: same cause — with the permission set you can create a Facility Location, choose its record type, enter an address and set its status. Because you could not enter an address at all, geocoding was never actually exercised; it is in this round, and it fills in coordinates and altitude for you.

Check it in: PB3 · Locations, geocoding & delivery defaults.

AccessSQL2-193

"The Workday WID is not displayed in Salesforce, but it is visible in the Provider Portal under the same order."

What we did: exactly as you deduced — the data was there and the integration had written it; only the internal view was hiding it. Internal users now see the Workday identifiers on the order and the location.

Check it in: PB3 · Locations and the Workday scenarios in PB11 · Compliance operations.

AccessSQL2-194

"The order cannot be found in Related → Orders. I had to add Orders to the favourites bar."

What we did: the Orders related list had been dropped from the client page layout. It is back, so a client's orders are listed on the client record where you looked for them.

Check it in: PB1 · Order on behalf of a client.

Questions you asked

AnsweredSQL2-201

"Can the order number from the Provider Portal also be used in Workday to search the order?"

Answer: not today. The portal order number is never sent to Workday, so there is nothing there to search on — you match orders by the supply item reference instead. We have proposed carrying the order number across inside the Workday memo as part of the next phase of integration work, which would make it searchable.

Related scenarios: PB11 · Compliance operations covers what does travel to Workday.

FixedSQL2-180SQL2-181

"It only works for item #40274 — other supplies are not visible in Workday" / "Orders stopped appearing in Workday after initially syncing"

What we did: two different causes. The first was product data: most items were missing the reference and unit that Workday needs to accept a line, so only one product could ever succeed — that mapping has been corrected for the catalogue. The second was not your order at all: the integration link had gone quiet and needed restarting, which is now a known operating procedure.

Check it in: PB11 · Compliance operations, the Workday scenarios.

One more thing

Your first round also produced something that is not on this list: it is the reason the whole compliance track exists in this guide. Testing an order end to end exposed how much of the story sits after you press Place Order — approvals, limits, timeouts and notifications. That is the Compliance track, and it is new here.

All modules PHASE 2

Phase 2 fixes

Why this page exists

During Phase 2 testing (September 17 to 28) you reported 23 items on this site and left 9 suggestions. This page lists everything that has been solved: what you reported, what was wrong, what we changed, and, where there is something to see, a picture from before and after.

Items under Waiting for your re-test are fixed on our side and need one more run from you. Five of the reports had a single cause: emails started by portal users and by Salesforce's own automation never left Salesforce. That was fixed on September 23, and order emails now come from Sonora Quest Laboratories.

Updated October 1, 2026.

Fixed a defect, corrected Access the feature worked; the account could not reach it Built your suggestion, now part of the product Answered a question, answered below Guide the guide’s wording, corrected

Waiting for your re-test Fixed on our side. Please re-run the scenario and record the result.

FixedSQL2-192

“The address is still offered after being set up as inactive.”

PB3 · Scenario 4 · reported by Kamil Popiela on Sep 22 · done Sep 30

What was wrong: An address switched to Inactive still appeared on Shipping Address. After the first fix, a saved draft that already pointed at an inactive address could still reach Place Order before being stopped.

What we changed: Inactive addresses no longer appear on Shipping Address, and an order can't be placed to one. When you resume a draft whose address was switched off, the wizard clears it, opens the Shipping Address step and says the saved address is no longer active. Recurring deliveries to an inactive address are held too.

Before
Before
The inactive 77777-KP address still offered (Sep 22)

Re-test it in: PB3 · Scenario 4: Take a location out of service and bring it back

FixedSQL2-63

“Clicking Resume, Cancel or Activate Recurring Order only shows the message in the top right corner, but the buttons don't change. To see the change, the whole website needs to be refreshed.”

PB4 · Scenario 4 · reported by Kamil Popiela on Sep 22 · done Sep 30

What was wrong: Each change was saved, but the page re-read the recurring order from an out-of-date copy in the browser, so the buttons flipped back. Your re-test also found Custom in the frequency list, a leftover with nothing behind it.

What we changed: Pause, Resume, Cancel and Activate now update the buttons and the Template Status straight away, with no refresh. The frequency list offers the two frequencies recurring orders support: Bi-Weekly and Monthly.

Before
Before
Custom in the frequency list (Sep 26)
After
After
Only Bi-Weekly and Monthly (Sep 30)

Re-test it in: PB4 · Scenario 4: Pause it, restart it, cancel it

FixedSQL2-163

“Didn't receive the email. And since the portal only says 'A requested quantity exceeds the allowed amount', a client may not know what to do next if the email doesn't reach them. Could the portal show which supply and quantity was denied or removed?”

PB7 · Scenario 2 · reported by Kamil Popiela on Sep 22 · done Sep 30

What was wrong: The denial email wasn't being sent, and the order page in the portal only showed one generic line, so a client without the email couldn't tell what had happened, which supplies changed, or what to do next.

What we changed: The denial email goes out with the account manager's comment. On the portal order page, the Review Decision card explains the outcome in one standard message, shows the account manager's own comment, and each supply says what happened to it on its own row of Items on this Order (for example "Removed (2 requested)", "Reduced to 1 (3 requested)" or "Approved in full"). It works the same whether the account manager made the change or the review window ran out.

Before
Before
Only the generic line on a denied order (Sep 22)
After
After
Order 00000886: the outcome, and each supply says what happened to it (Oct 4)

Re-test it in: PB7 · Scenario 2: What the practice sees when the answer is no

FixedSQL2-135

“Compliance log shows no transitions for any recurring orders.”

PB10 · Scenario 3 · reported by Kamil Popiela on Sep 23 · done Sep 30

What was wrong: Two things, one after the other. First, the nightly job that creates recurring deliveries didn't have the order permissions, so no delivery was checked. Then your re-test found that when several deliveries were created the same night, only the first one was checked and none of them moved on (00000901 to 00000905).

What we changed: Each delivery is now checked on its own, so one can't hold up the others. A delivery over the allowance goes to In Progress with its evaluation in the Compliance Log, and it is released automatically if nobody reviews it within the review window. If a check can't finish, the delivery stays in Draft and the order says why in Compliance Evaluation Error. The stuck deliveries were processed: 00000901 and 00000903 went to In Progress, 00000904 was approved, and 00000905 was held because its address is inactive.

Before
Before
An empty Compliance Log on a recurring delivery (Sep 23)
After
After
Delivery 00000901, checked and waiting in In Progress (Sep 30)

Re-test it in: PB10 · Scenario 3: A delivery that needs a human goes into the same queue

FixedSQL2-163

“The wording needs updating: 'If your Account Manager does not review it within 1 hours' should read 'within the hour'. Also, I am blocked from viewing the compliance dashboard.”

PB8 · Scenario 1 · reported by Mike Davis on Sep 21 · done Sep 24

What was wrong: The banner printed the review window as "1 hours", and the Compliance Engine Dashboard wasn't switched on for your user.

What we changed: The banner no longer names the review window at all. It now reads Pending Approval: "One or more items in this order exceed your allowed amount and are under review. You'll receive an email confirming exactly what shipped." The dashboard is switched on for your user and sits in the app's top bar.

Before
Before
"within 1 hours" on the submitted order (Sep 22)
Before
No dashboard in the App Launcher (Sep 21)

Re-test it in: PB8 · Scenario 1: Start the clock and read what the client is promised

Your suggestions Ideas you left in the guide, now part of the product (or answered).

BuiltSQL2-142

“Clients could potentially max out the money allowance and work out how much each item costs. The money information might be valuable for the SCM team and Sales only.”

PA11 · Scenario 1 · reported by Kamil Popiela on Sep 22 · done Sep 30

What we changed: Agreed. In the portal, the compliance check no longer shows any dollar amounts. Clients still see which supplies are over their allowance and by how many units, and can add a justification or reduce the supply. Account managers and our internal teams still see the figures.

Check it in: PA11 · Scenario 1: Push a quantity over the limit and watch the panel change

BuiltSQL2-199

“After opening 'View Full Record' of a generated order from Generated Order History, there is no way back to the recurring order to see its other orders. I have to go back to My Orders and search again.”

PA7 · Scenario 3 · reported by Kamil Popiela on Sep 18 · done Sep 30

What we changed: A generated delivery's Details card now shows Recurring Order with a link straight back to the recurring order, where Generated Order History lists all its deliveries.

After
After
Delivery 00000887 links back to recurring order 00000303

Check it in: PA7 · Scenario 3: Open the recurring mystery box

BuiltSQL2-196

“Finding denied orders requires a manual search. A filter may help communication with clients, especially those who place many orders. And when only 2 lines out of 10 were over the limit, will the client receive the other 8?”

PA7 · Scenario 5 · reported by Kamil Popiela on Sep 21 · done Sep 30

What we changed: My Order History now has a Denied tab. On your question: while any line is over the allowance, the whole order waits for the account manager. They can approve it, approve it with changes (the 2 lines reduced or removed, the other 8 ship), or deny it, which stops all 10 lines. If nobody decides within the review window, the 2 lines are cut to the allowed amount and the rest ships. A denied order shows the standard message followed by the account manager's own comment, so the client sees the real reason.

After
After
The new Denied tab in My Order History

Check it in: PA7 · Scenario 5: Why an order was turned down

BuiltSQL2-202

“Support case # visible on the My Orders screen, on the same line as the order, may help to identify the order.”

PA8 · Scenario 2 · reported by Kamil Popiela on Sep 21 · done Sep 30

What we changed: The inquiry tag on each My Order History row now includes the case number, for example Inquiry answered · Case 01556020. When an order has several inquiries, the newest open one is shown.

After
After
The case number on the order's row

Check it in: PA8 · Scenario 2: See that we've got it, without phoning anyone

BuiltSQL2-147

“It might be confusing for a practice manager in the portal alone. It might be needed to add 'Ordered Qty' and 'Approved Qty' along with the quantity.”

PB8 · Scenario 2 · reported by Kamil Popiela on Sep 22 · done Sep 30

What we changed: When a review changes an order, each changed supply says on its own row of the order page what was requested and what was approved ("Reduced to 1 (3 requested)"), and the approval email shows Requested and Approved columns side by side. See the picture under PB7 above.

Check it in: PB8 · Scenario 2: Come back after the window — the order released itself

BuiltSQL2-147

“A dedicated message may improve the experience. Adding a phrase like 'Please contact your account manager for further details' could also help.”

PB8 · Scenario 3 · reported by Kamil Popiela on Sep 22 · done Sep 24

What we changed: Each outcome now has one standard message that says what happens next, for example "…please raise a separate request with your Account Manager if the volume is permanent", followed by the account manager's own comment when they write one.

Check it in: PB8 · Scenario 3: The other ending: nothing left to ship

FixedSQL2-60

“When typing at a moderate tempo, the search sometimes removes the last typed letter and it needs to be retyped. It might have to do with refreshing the results.”

PA4 · Scenario 2 · reported by Kamil Popiela on Sep 17 · done Sep 30

What was wrong: You were right: when the delayed search caught up, it redrew the box with slightly older text and erased the letter you had just typed.

What we changed: The search box now keeps every keystroke. The list still waits for a short pause in your typing before it filters.

Check it in: PA4 · Scenario 2: Search by name or code — including when nothing matches

AnsweredSQL2-24

“When removing the last item on Review Order it says 'An order needs at least one item. To discard the whole order, cancel the draft instead.' It might be valuable to have 'Delete Draft' next to 'Save Draft'.”

PA2 · Scenario 2 · reported by Kamil Popiela on Sep 17 · answered Sep 30

What we answered: A draft never ships and never counts against the allowance, so an order you no longer need can simply stay a draft. The old message pointed to a cancel option that doesn't exist; it now says exactly that: "If you no longer need this order, you can leave it as a draft; drafts are never sent."

Check it in: PA2 · Scenario 2: An empty cart can't move forward

Verified by you Fixed, and confirmed on your re-test.

GuideSQL2-20

“No dead links, but instead of Exit there is Return to Provider Dashboard.”

PA1 · Scenario 1 · reported by Kamil Popiela on Sep 17 · verified Sep 17

What was wrong: The guide said Exit; the portal button reads Return to Provider Dashboard, as Marketing asked.

What we changed: The guide now uses the portal's wording.

Before
Before
The portal header (Sep 17)

Check it in: PA1 · Scenario 1: Sign in and find your way around

FixedSQL2-22

“After updating the quantity from 1 to 10 in Resume Order and saving, My Orders showed 10, but when I clicked Resume Order again the quantity was back to 1.”

PA1 · Scenario 5 · reported by Kamil Popiela on Sep 17 · verified Sep 21

What was wrong: Resume Order read the draft from a copy the browser had kept, so for two or three minutes it showed the quantities from before your save.

What we changed: Resume Order now always reads the draft fresh, so it opens with what you last saved.

Before
Before
Saved with Qty 10
Before
…but Resume Order opened with 1 (Sep 17)

Check it in: PA1 · Scenario 5: Save a draft, walk away, come back to the same order

AnsweredSQL2-45

“After clicking 'How is it calculated' under both lines of supplies, all buttons became dead.”

PA3 · Scenario 1 · reported by Kamil Popiela on Sep 17 · verified Sep 21

What was wrong: We couldn't make it happen again on the same account, order and steps, and neither could you on September 22. One thing that does happen by design: while a line is over the limit, Continue stays grey until you add a justification (the amber "1 item(s) need justification" note).

What we answered: Nothing to change for now. If it ever comes back, tell us your browser and what was on the screen.

Before
Before
Continue greyed while a line needs a justification (Sep 17)

Check it in: PA3 · Scenario 1: Review Order — everything on one screen before you commit

FixedSQL2-81

“Step 9. After clicking Review Draft Order it showed Invalid Page.”

PA6 · Scenario 2 · reported by Kamil Popiela on Sep 18 · verified Sep 21

What was wrong: Review Draft Order (and View Template) opened an internal Salesforce address that doesn't exist in the portal.

What we changed: In the portal they now open the order's own portal page; inside Salesforce they still open a new tab, as before.

Before
Before
"Invalid Page" (Sep 18)

Check it in: PA6 · Scenario 2: Copy a past order into a fresh draft

AccessSQL2-34

“I don't have the ability to look up supply images.”

PB12 · Scenario 1 · reported by Mike Davis on Sep 18 · verified Sep 21

What was wrong: Supply Images wasn't switched on for your user, so the App Launcher found nothing.

What we changed: It is switched on now, and Supply Images sits in the app's top bar.

Before
Before
No results for Supply Images (Sep 21)

Check it in: PB12 · Scenario 1: Read a supply the way a client will see it

AnsweredSQL2-199

“I cannot replicate 'You may have already ordered some of these items recently', even with duplicate orders for the same item from recurring orders.”

PA7 · Scenario 6 · reported by Kamil Popiela on Sep 21 · verified Sep 22

What was wrong: Nothing was broken. The warning only appears when the same items, in the same quantities, go to the same address within 7 days, and it only counts orders that were submitted: drafts don't count, and recurring deliveries count once they've been submitted.

What we answered: No change needed. PB11 Scenario 1 shows both settings.

Check it in: PA7 · Scenario 6: The recurring reminder inside the wizard

AnsweredSQL2-151

“The order 00000683 has status Approved but still shows as awaiting approval in the Compliance Engine Dashboard.”

PB11 · Scenario 2 · reported by Kamil Popiela on Sep 21 · verified Sep 24

What was wrong: The dashboard keeps showing the results from its last refresh (the "As of…" time); it doesn't update by itself when you open it.

What we answered: No change needed: click Refresh at the top right of the dashboard. Once refreshed, 00000683 dropped off the list.

Before
Before
3 waiting, from an older refresh (Sep 21)
After
After
After Refresh: 0 waiting (your own screenshot, Sep 24)

Check it in: PB11 · Scenario 2: The two dashboards

FixedSQL2-202

“When Client Response is edited, it cannot be saved. Changing Case Origin makes Client Response disappear. After saving, the answer is not showing in the portal.”

PB5 · Scenario 2 · reported by Kamil Popiela on Sep 21 · verified Sep 24

What was wrong: Two problems. Order inquiries were created without a Case Origin, so saving made you pick one, and some choices switched the case to a type without the Client Response field. And the portal's order page only ever showed one support case, so an answer on an older case stayed hidden.

What we changed: New inquiries get their Origin automatically (the older open ones were filled in). The portal's order page lists every inquiry on the order, newest first, each with its status and answer, and a new inquiry shows up right after it's submitted.

Before
Before
Only one of the order's two cases shown (Sep 24)
After
After
Order 00000708: Support cases (2), each with its answer

Check it in: PB5 · Scenario 2: Answer the client — one field, and the portal changes

FixedSQL2-66

“Didn't receive the email in step 5.”

PA9 · Scenario 4 · reported by Kamil Popiela on Sep 22 · verified Sep 26

What was wrong: The email problem described at the top of this page. On your re-test, Resume Order then failed with "insufficient access rights": the draft had been started by someone else (a test order of ours that crossed your test, our apologies), and the portal offered Resume on it anyway.

What we changed: Order emails go out from Sonora Quest Laboratories. Resume Order only appears on drafts you started yourself; on a colleague's draft the page names who started it and says "Only they can finish it."

Before
Before
Resume on someone else's draft failed at Place Order (Sep 24)

Check it in: PA9 · Scenario 4: Follow the order you just placed

FixedSQL2-202

“When I write the Client Response, the field disappears after save and no answer is visible under the order number.”

PA8 · Scenario 3 · reported by Kamil Popiela on Sep 22 · verified Sep 24

What was wrong: The same missing Case Origin as in PB5 above: saving switched the case to a type without the Client Response field.

What we changed: The Origin is filled in automatically, the Client Response saves, and the answer shows under the order number in the portal.

Before
Before
Client Response empty after saving (Sep 22)

Check it in: PA8 · Scenario 3: Read the answer when it comes back

FixedSQL2-144

“No email confirmation.”

PA10 · Scenario 2 · reported by Kamil Popiela on Sep 22 · verified Sep 24

What was wrong: Confirmations for orders placed in the portal weren't being sent (the email problem described at the top).

What we changed: The confirmation arrives from Sonora Quest Laboratories with the subject "Your Order 000… Has Been Received".

Check it in: PA10 · Scenario 2: Place it — approved on the spot, no approval step

FixedSQL2-124

“I ticked Compliance Exclusion, saved, and came back to create the order for the client. The order still required justification.”

PA10 · Scenario 3 · reported by Kamil Popiela on Sep 22 · verified Sep 24

What was wrong: When an order shipped to one of the client's addresses, that address's own (unticked) Compliance Exclusion box overrode the tick on the client.

What we changed: An order is now excluded when either the client or the ship-to address is ticked, so no justification or approval is asked for.

Before
Before
Compliance Exclusion ticked on client 77777
Before
…but the order was still flagged (Sep 22)

Check it in: PA10 · Scenario 3: Check the three client settings the engine reads

BuiltSQL2-143

“These justification categories can be added: scheduled patients, new provider, expired supplies, test conversion, seasonal (flu, RSV, etc.), hosting a special event.”

PA11 · Scenario 2 · reported by Kamil Popiela on Sep 22 · verified Sep 24

What we changed: All six are in the reason picker: Scheduled Patients, New Provider, Expired Supplies, Test Conversion, Seasonal Demand (Flu, RSV, etc.) and Hosting a Special Event, alongside the original reasons, with Other still last.

Check it in: PA11 · Scenario 2: Give a reason for the overage

FixedSQL2-63

“The recurring order doesn't show Order Products under Related in Salesforce. In the provider portal the supplies are visible.”

PB4 · Scenario 3 · reported by Kamil Popiela on Sep 22 · verified Sep 24

What was wrong: The Salesforce page layout for recurring orders only had the Cases list.

What we changed: The recurring order's Related tab now shows Order Products, each item with its quantity.

Before
Before
Related showed only Cases (Sep 22)
After
After
Recurring order 00000741: Order Products (1)

Check it in: PB4 · Scenario 3: Read the template record

AccessSQL2-63

“I opened the generated order and I cannot see most of its features. It might be an access permission issue for recurring orders.”

PB4 · Scenario 5 · reported by Kamil Popiela on Sep 22 · verified Sep 26

What was wrong: You were right that it was access: the nightly job that creates deliveries ran as a user without the order permissions, so every delivery stayed a Draft with nothing filled in.

What we changed: That user now has the right permissions; deliveries are created and checked.

After
After
A generated delivery, approved, from recurring order 00000303 (your own screenshot, Sep 26)

Check it in: PB4 · Scenario 5: What the schedule produces — and the new automatic review

FixedSQL2-146

“The email 'Action Required — Order 000… Pending Compliance Approval' didn't arrive. Only 'You have an assigned action item in Salesforce' was received.”

PB6 · Scenario 1 · reported by Kamil Popiela on Sep 22 · verified Sep 26

What was wrong: Our "Action Required" email wasn't going out (the email problem described at the top); only Salesforce's generic notice got through.

What we changed: The email now reaches the account manager. Its subject has since dropped the word Compliance: "Action Required — Order 000… Pending Approval".

Before
Before
Only Salesforce's generic notice arrived (Sep 22)

Check it in: PB6 · Scenario 1: Find the order that is waiting for you

FixedSQL2-146

“Email not received as described in point 9.”

PB6 · Scenario 3 · reported by Kamil Popiela on Sep 22 · verified Sep 26

What was wrong: The email after an approval wasn't going out (the email problem described at the top).

What we changed: "Your Order 000… Has Been Approved" arrives from Sonora Quest Laboratories.

Check it in: PB6 · Scenario 3: Trim a line, write a note to the client, approve

All modules PB12

Keep the supply catalog client-ready

Not started

Why you're testing this

Everything a provider sees in the order portal — the supply number, the name, the picture, the unit it is sold in — comes from one page on your side: Supply Images. After go-live this page belongs to Sonora Quest, not Penrod: when Marketing wants a better photo, when Supply Chain wants a friendlier name than the Workday description, when a supply is retired or a new one is added, this is where it happens. Portal users never see this page; they only see its results. This module walks the page as the people who will own it.

Full story & acceptance criteria

SQL2-34 — Item Catalog Management. "As a Provider Portal User, I want to apply the correct product list automatically when I start an order." The catalog the portal shows is the one maintained here: a supply appears to a client only when it is Active and on a price book.

SQL2-60 — Product Catalog Browsing Images Design. Every supply carries an image shown on its portal card. Images are stored as Salesforce Files in the Client Supplies library — no public link, no external host is needed.

SQL2-177 — Customer-facing item name and number. The portal shows the Customer-facing name and Customer-facing item # when they are filled in, and falls back to the supply name and supply # when they are blank, so no card is ever left without a label. The mapping was confirmed with Aaron Collins on 2026-07-07: friendly name = item name, legacy part number = item number.

Scenario 1 · ~7 min SQL2-34 SQL2-177

Read a supply the way a client will see it

Not run

What you're checking: that one page explains everything a provider will see on a supply card, and that what it says matches the portal. Read only in this scenario — you will change things in Scenario 2.

The Supply Images tab sits in the Sonora Quest Sales app's navigation bar (it may be under More). If you cannot see it, open it from the App Launcher — search "Supply Images".
  1. Click Supply Images in the navigation bar. The page is headed Supply Image Manager and lists every supply in the catalog, ten to a page, with a search box and two buttons: New Supply and Add Media.
    Sonora Quest Sales — Supply Images
    Each row is one supply: its picture, Supply #, name, and a chip saying where its image lives. Edit opens the full record.
  2. Click the ⓘ next to the title and read Where are images stored? — images are saved as Salesforce Files in the Client Supplies library, shown to internal staff and to logged-in providers; there is no external host and no public link.
  3. Type APTIMA in Search all supplies. The list narrows to SUPPLY #40274 — APTIMA SPECIMEN TRANSFER KIT PRINTABLE 100T/KT.
  4. Click Edit on that row and read the Edit supply window top to bottom.
    Edit supply — SUPPLY #40274
    Left: the image with Upload and From library. Right: Supply name, Supply #, Unit of measure, the two Customer-facing fields, Category, Description, Unit cost and the Active switch. Below: the Image URL with a Copy button.
  5. Read the two Customer-facing fields and hover their ⓘ. They are blank here — so the portal falls back to the supply name and supply #. When they are filled in, they are what the client sees instead. That is the whole SQL2-177 rule.
  6. Read the Unit cost box and the amber note under it: No unit cost — compliance dollar limits are skipped for this supply. Remember this: the engine's dollar rules (the low-dollar auto-approval and the per-line cost ceiling) can only judge a supply that has a cost. In this sandbox most supplies have none, so those two rules stay quiet. Four supplies are the exception, and they are the ones the compliance modules depend on. For test client 77777 these four carry real laboratory usage, so their limits come from history rather than the 50-unit fallback, and each one is priced. The dollar rules measure the overage — the cost of units above the allowance — so a line inside its allowance is never stopped by them: LABEL ZEBRA FIELD ACCESSIONING (10750, $2.50); APTIMA SPECIMEN TRANSFER KIT PRINTABLE 100T/KT (40274, $4.50); FORM IRREPLACEABLE SPECIMEN LOG (900005, $0.25); and PIPET TRANSFER W/GRADUATIONS (900010, $3.25). What each one allows moves with the usage feed and with every order placed, so it is read on the Review step (ALLOWED) rather than quoted here; the Before you start tab shows how. Every other supply in the catalog falls back to an allowance of 50. Leave these four alone in this module — changing a name, a number or a cost on one of them changes what other testers see in the compliance scenarios.
  7. Read the Active switch and the line under it — Available in the order catalog. If a supply is Active but not on any price book, the line changes to a warning: it will not appear in the portal even though it is Active. Both conditions have to be true.
  8. Click Cancel. Nothing has changed.
  9. Now look at it from the client's side. In another tab, sign in to the provider portal with your portal login, click the Order Supplies tile and find SUPPLY #40274 in the catalog.
    Provider portal — Order Supplies
    The same supply number, the same picture, the name as its title, the description underneath, and the unit of measure as a small badge — every one of them set on the Supply Images page.
  10. Match the card to the record: picture, number, name, description, unit badge. Note in your comments anything the card shows that you could not find on the Edit window, or the other way round.
Expected result
  • The Supply Images page lists the catalog with search, paging and an Edit per supply.
  • The Edit window explains its own rules: fallback names, the dollar-limit note, and the Active + price book condition.
  • The portal card for #40274 shows exactly what the record holds.
Result:
Scenario 2 · ~9 min SQL2-177 SQL2-60

Give a supply a friendlier name and a real picture

Not run

What you're checking: the everyday job — a Workday description that no provider would recognise gets a customer-facing name and a proper photo, and the portal picks both up without anyone at Penrod being involved.

Work on SUPPLY #900004 — FORM HEREDITARY CANCER FAMILY HISTORY 25/PD. It is in the portal catalog but nobody orders it in the other modules, so your change will not confuse another tester. If someone got there before you, their name is already on it — put yours on instead; the last save wins and that is fine.
  1. On the Supply Images page, search HEREDITARY and click Edit on SUPPLY #900004.
  2. Type a Customer-facing name a provider would actually recognise, with your initials at the end so you can find it again — for example Hereditary Cancer Family History Form, pad of 25 (AC).
  3. Type a Customer-facing item # — for example HC-FORM-25. Leave Supply name and Supply # exactly as they are: those are the Workday values and the sync depends on them.
  4. Replace the picture. On the Upload tab click Upload Files and pick any PNG or JPG from your computer — a photo of a form pad, or any test image. The preview on the left changes as soon as the upload finishes and the row's chip will read Salesforce Files instead of External URL. The From library tab reuses a picture someone already uploaded — the Client Supplies library starts empty in this sandbox and fills up as testers upload, so by the second tester it will have something in it. Try it if there is.
  5. Click Save changes. A green toast confirms the save and the list row now shows your new picture; the name in the list is still the supply name — the customer-facing name is for the portal.
  6. Switch to your portal tab, refresh the Order Supplies catalog and find the supply. The card now carries your name and picture, and the small supply number reads your customer-facing item #.
  7. Go back and clear the picture's history. Reopen Edit, click the From library tab and confirm your upload is now in the Client Supplies library — that is where the next person will find it. Cancel.
  8. One more read. Open Add Media from the page header — the same library, with grid and list views, where Marketing can upload a batch of photos in advance and rename them by clicking their titles. Click Done.
Expected result
  • Customer-facing name and item # save, and the portal shows them in place of the Workday values.
  • The uploaded image replaces the placeholder on the row and on the portal card, with no public link involved.
  • The upload is reusable from the library for any other supply.
  • Supply name and Supply # were never touched.
Result:
Scenario 3 · ~8 min SQL2-34

Add a supply, price it, then retire it

Not run

What you're checking: the full life of a catalog item from your side — created with a cost so the engine can judge it in dollars, placed on a price book so the portal can show it, and then switched off without deleting anything.

In the live system new supplies arrive from Workday through the item sync; this button is for the exceptions. Use your initials in the name and number so every tester's supply is distinct.
  1. Click New Supply in the page header.
    New supply
    The same fields as Edit plus two that only exist at creation: a Price, and the Add to price books checkboxes — the rule at the bottom says why: a supply must be on a price book to appear in the order portal.
  2. Fill it in: Supply name UAT Test Supply (AC) with your own initials · Supply # UAT-AC · Unit of measure any value · Customer-facing name Test supply — please ignore (AC) · Description one line · Price 10 · Unit cost 2.50.
  3. Read the Category list before you pick one. The categories are the portal's filter groups (Collection & Tubes, Forms & Labels, and so on) and they are an admin setting — note in your comments whether the list offers the groups you would expect; if it is empty, say so and continue without one.
  4. Tick both price books — Standard Price Book and Family Practice >20 — so the supply shows for every client type, and click Create supply.
  5. Find it in the list (search your initials) and open Edit. Because you gave it a unit cost there is no amber "dollar limits are skipped" note — this is a supply the engine can price. The line under Active reads Available in the order catalog.
  6. Check the portal. Refresh the Order Supplies catalog; your supply is there with its customer-facing name. Do not order it.
  7. Now retire it. Back in Edit, switch Active off, click Save changes, and refresh the portal catalog: the supply is gone for clients, but still listed on the Supply Images page with an inactive status — nothing was deleted and its history stays intact.
Expected result
  • A supply created here appears in the portal only after it is Active and on a price book.
  • A unit cost removes the "dollar limits are skipped" warning — the engine's dollar rules now apply to it.
  • Switching Active off hides it from clients without deleting it.
  • Your notes say whether the Category list matched the portal's filter groups.

Send your results

Review the draft below — it's fully editable — then send it straight from here or copy it into your own email client.

Gmail and Outlook open a plain-text draft — web compose links can’t carry formatting. For the styled version, use Copy formatted email and paste it into the message body — and attach your results file (Download results file) so all testers’ runs can be consolidated.