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.
Group
What it lets you do
In QA on Oct 2
Provider Order Management — Standard User
Place 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 — Admin
Everything above, plus the Compliance Configuration page and the compliance dashboards. This is the group that changes the ratios and thresholds.
8 people
Compliance Approval Reviewer
Sees 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 Manager
Edit 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 happens
Who hears about it
How
An order goes over its supply limit
The client's account manager
Bell notification in Salesforce and an email
The account manager approves it
Whoever placed the order
Email
A line is trimmed or the order is denied
Whoever placed the order, and the practice
Email carrying the reviewer's reason
Nobody reviews it inside the window
Both sides
Email — the order releases itself (module PB8)
An admin recalls an order already sent for review
The person who submitted it
Notification
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.
How this works
You are signed in with your tester account — your name goes on your results automatically.
Pick a module below and work through it — each one holds a handful of scenarios with numbered steps. Every key step has a real screenshot of what you should see. Click any screenshot to enlarge it.
After each scenario, hit Pass, Fail, or Blocked — and add a comment (required for a Fail: tell us what you saw).
Everything saves to your account as you go — watch the bar up top fill in, and sign in from any device to pick up where you left off. Spotted something that is not broken but could be better? Use the 💡 suggestion bulb in the top bar (or on any scenario) and it reaches us instantly.
When you record a Fail or Blocked, it opens a conversation with the team right on that scenario card — no email needed. The 🔔 bell in the top bar counts your open reports and takes you back to each one; when we reply or mark something Fixed — please re-test, the bell glows and the update is waiting on the card. Re-test and record a Pass, and the report closes itself as verified. The whole back-and-forth stays on the scenario, so nothing gets lost.
Every key step carries a real screenshot of the screen you should be looking at — click any of them to enlarge.
Before you start
You are testing in the QA sandbox. The supply pages a client uses start at Client Supplies, sonoraquest--qa.sandbox.my.site.com/ClientSupplies/: sign in there with your own portal account, the one that was sent to you (module PA1, Getting in).
The client used throughout this guide is Sonora Quest Laboratories (client 77777). It has several ship-to addresses; on the Shipping Address step the one marked Default is preselected for you. Some of them carry names that do not start with 77777 — that is fine: every address on this client is scored against client 77777, so your supply limits are the same whichever you pick.
About supply limits: every order — placed from the portal or internally — is scored against the client's live usage feed (Data Cloud) over the last 90 days, and whatever the client already ordered in that window is deducted. A supply with no usage history for the client falls back to a flat 50 units and shows the Limit Estimated chip.
Four supplies carry real usage history for client 77777, on both tracks. Use them for every limit scenario. Their allowance is not a fixed number: it is three times the usage recorded over the last 90 days, less what has already been ordered in that time, so it moves with the usage feed and shrinks as testers order. Read it where the system shows it — ALLOWED in the SUPPLY LIMIT block on the Review step, with the arithmetic under How is this calculated? — and work from the number on your own screen. As an example, this is what the screen read on October 2, 2026:
Supply
Supply #
ALLOWED on Oct 2
LABEL ZEBRA FIELD ACCESSIONING
10750
1,782 772 used × 3 = 2,316, less 534 already ordered — plenty of headroom, use this one for a clean pass
APTIMA SPECIMEN TRANSFER KIT PRINTABLE 100T/KT
40274
0 7 used × 3 = 21, less 168 already ordered — used up, so any quantity is over the limit
FORM IRREPLACEABLE SPECIMEN LOG
900005
1 8 used × 3 = 24, less 23 already ordered
PIPET TRANSFER W/GRADUATIONS
900010
18 10 used × 3 = 30, less 12 already ordered
To go over a limit on purpose, so that the order needs approval, ask for more than double the number ALLOWED reads (any quantity, when it reads 0). Every other supply falls back to the standard 50 — there is no usage history for it on this client — less what has already been ordered. An allowance that has been used up reads 0, and then even a quantity of 1 asks for a justification on the Review step: in a scenario that is not about limits, pick another supply.
Screenshots in this guide were captured in this same QA sandbox with the live usage feed connected. The portal's pictures were taken again on October 1 and 2, after its pages got their tiles; on October 7 those pages moved to an address of their own, /ClientSupplies, and look exactly as pictured; the internal ones date from September. Client names, order numbers and allowances in the pictures will differ from your own. The steps and the labels are what matter.
Anything marked Updated from your feedback changed because of round-one testing.
What the supply-limit engine is set to right now
The values in force in the QA sandbox as of Oct 2, in plain language, so you know what to expect before you place an order. They live on the Compliance Configuration page (internal track, PB11); after go-live Sonora Quest owns them. Your comments on these numbers are welcome.
Setting
Value now
What it means when you test
Segment ratio — POL
3.0
Every segment's ratio is 3.0 — the allowance is three times a client's measured usage over the look-back window (the Review step breakdown shows it as 300%). This is a deliberately permissive cushion for go-live: nobody gets blocked on day one, and Sonora Quest dials the ratios down as real usage history accumulates. The Review step shows it as the allowed portion of what you asked for. Starting point agreed with the team; the original design sketched 150% / 180% / 200% as the eventual per-segment targets.
Segment ratio — IOP
3.0
Segment ratio — Global
3.0
Usage look-back
90 days
How much usage history feeds the allowance. The live feed is compiled monthly, so 90 days ≈ three monthly buckets. Original design said 90 days — to be confirmed.
Already-issued window
90 days
Approved orders from the last 90 days are subtracted from the allowance. Order 10 of something today and tomorrow's allowance for it is 10 lower — that is by design, not a bug.
No-history fallback
50 per item
A client with no usage in the feed gets a flat 50 units of each supply (less anything already issued). The Review step says so. New or freshly created clients sit in this state.
Live usage feed (Data Cloud)
Always on
Every order, internal or portal, is scored against the real utilization feed, refreshed every morning around 6 AM, so the same order can get a slightly different allowance on a different day. There is no switch for it: the two this table used to list, Use Data Cloud and Allow external DMO access, were removed on September 29. If the feed cannot be read, the Review step says it hit a temporary issue verifying your supply limits and the order is blocked until the feed is back — it is never judged on an estimate. The Limit Estimated chip only appears on a supply with no usage history for the client.
Low-dollar auto-approval
$5
Dollar guardrails on an over-allowance line: if the extra costs $5 or less (and the request is under the overage factor) it is approved quietly; if the extra costs more than $200 it always goes to a person. The four feed-backed supplies now carry unit costs, so both dollar rules are live for them. Both figures measure the overage — the cost of the units above your allowance — not the value of the whole line, so a line inside its allowance is never stopped by a dollar rule however much it is worth. Module PB12 shows where the cost is set. Production ceiling not yet proposed by Sonora Quest.
Per-line cost ceiling
$200
Overage factor
2.0×
The second half of the low-dollar gate: the cheap-overage shortcut only applies while the request stays under double the allowance. Agreed with the Supply Chain team.
Cut threshold
20%
When a line is over its allowance, the engine trims it back to the allowance and measures the cut as a share of what was requested. A cut of 20% or less is approved automatically with a justification you must type; a bigger cut is routed to the approver, justification still required. Discovery discussed 30–50%; 20% is the value tuned with the team in April.
Approval window
1 hour
How long a routed order waits for the approver before releasing itself. 1 hour is a testing value so module PB8 fits in one sitting. Production: 24 hours (agreed in discovery).
Approver
Client owner
The client record's owner receives routed orders. Read who that is in Client Owner on the client's Details tab; no backup approver is set.
Possible-duplicate warning
7 days · exact match
Re-order the same items to the same address within a week and the Review step shows an amber possible duplicate banner. It is advice, not a block — read it and continue. Design discussed ~48 hours; to be confirmed.
Configuration version
2026.09.v4-UAT
Stamped on every order the engine judges, so a result can always be traced to the rules that produced it.
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).
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.
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.
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.
Tester
Internal Salesforce
Portal (client view)
Aaron Collins
aaron.collins@sonoraquest.com.qa
aaron.collins@sonoraquest.com
Bhavani Mamidi
bhavani.mamidi@sonoraquest.com.qa
clinicalreviewuat@sonoraquest.com
Jef Wright
jef.wright@sonoraquest.com.qa
jefmwright@gmail.com use this one — the sonoraquest.com portal account sits on a different practice
Kamil Popiela
kamil.popiela@sonoraquest.com.qa
kamil.popiela@sonoraquest.com
Mike Davis
mike.davis@sonoraquest.com.qa
mike.davis@sonoraquest.com.qasb
Olivia Seiter
olivia.seiter@sonoraquest.com.qa
not set up yet — internal only for now
Ryan Eidson
ryan.eidson@sonoraquest.com.qa
ryan.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.
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.
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.
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.
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.
ClickOrder 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.
ClickMy Order History. Your list of orders opens, headed ‹ My Order History. Click the arrow to come back.
ClickKnowledge 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.
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.
Click the Order Supplies tile on Client Supplies. The wizard opens straight onto Select Items with your products already loaded — nothing to choose first.
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
Confirm your own practice is the only option in that dropdown — no list of Sonora Quest's other customers. Close it again.
ClickAdd to Cart on any product, then Continue to Review.
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.)
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.
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.
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
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.
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.
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.
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.
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.
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.
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).
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
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.
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".
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.
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.
OpenOrder Supplies from Client Supplies, add one product with Add to Cart, then click Continue to Review.
ClickSave 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.
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.
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".
ClickResume 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.
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.
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.
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.
OpenOrder 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
Add one product with Add to Cart, then click Continue to Review.
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.
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.
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
ClickContinue 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.
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.
OpenOrder Supplies fresh. If anything is already in the cart, click Remove on each row until the cart is empty.
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.
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.
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.
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.
OpenOrder 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.
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.
ClickAdd 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
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.
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.
ClickRemove 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.
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.
AddPIPET 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.
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
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.
Try-5 the same way — the same "must be at least 1" toast appears.
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.
Set the quantity to a sensible number such as 5. The toast stops coming back and Continue to Review turns solid teal again.
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.
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.
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.
OpenOrder 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
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.
Check the Order Items heading carries a count chip ("2 items") that matches the number of lines.
Check the Order Summary card on the right shows Total Items and Total Quantity. Change one line's quantity and watch both update immediately.
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.
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.
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.
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).
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
Wait a few seconds without clicking. The control disarms itself and goes back to Remove — nothing is lost by hesitating.
ClickRemove again, then Confirm? straight after. The line disappears immediately.
Check the Order Items count chip and the Order Summary totals both drop to match what's left.
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.
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.
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.
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
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).
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.
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.
ClickContinue from Review to reach Shipping Address, leave the pre-selected default location as it is, and click Continue again.
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
Check the Ordering As card on the right — Name, Email, Phone and Facility — and confirm it matches the contact you chose on Review.
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".
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.
ClickBack 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.
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.
ClickPlace Order on Confirm Order & Submit and give it a few seconds — the order is being checked against your supply allowance while you wait.
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
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.
Confirm the four buttons are there: Place New Order, Reorder, View Order Details and Submit an Order Inquiry.
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.
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.
From the Submitted screen, click Place New Order.
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.
ConfirmContinue to Review is greyed out again with the empty cart.
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.
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.
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.
Click the Order Supplies tile on Client Supplies. The wizard opens directly on Select Items.
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
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.
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.
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.
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.
Note the "n products found" counter above the list before you start.
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
Keep typing to spell out part of a product name you can see in the list, and confirm the rows narrow to matches only.
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.
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.
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.
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.
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.
Compare a few rows and confirm the chips differ product by product — they come from the item master, not from a single default.
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.
Add that product to your cart and confirm the same unit now appears in the row's UNIT column.
ClickContinue 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.
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.
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.
Hover over a product's photo — a VIEW DETAILS overlay appears across it.
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
Confirm the window shows the photo full size, the SUPPLY #, the CATEGORY and the complete DESCRIPTION — not the truncated version from the row.
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.
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.
FindSort 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.
ClickSupply #. 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
ClickSupply # a second time. The arrow flips to Supply # ↓ and the order reverses — the item that was first is now last.
ClickName to go back to alphabetical order.
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.
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.
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.
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.
Start a new order: Order Supplies, add a product, Continue to Review, then Continue — your name is already set as the Ship To Contact.
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
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.
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.
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.
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.
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.
Note which card currently carries the amber DEFAULT tag, and which card is currently selected for this order.
Click the bookmark icon on a card that is not the default — the one whose tooltip reads Set as default location.
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.
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.
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.
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.
Click the map-pin icon on any location card — the one whose tooltip reads View map.
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
Check the map has a red pin on the address, and that you can switch between Map and Satellite.
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.
ClickClose 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.
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.
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.
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
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.
Type something different into the lower box, Comments for this order (badged THIS ORDER ONLY) — for example "Please deliver before noon this week."
ClickSave.
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
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.
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.
Continue from Shipping Address, with the location you added the note to still selected.
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
ClickPlace Order and wait for the Submitted screen.
Scroll to the bottom of the Submitted screen and confirm Shipping Details shows the same address and a Delivery Instructions section with your wording.
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.
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.
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.
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.
OpenMy Order History — the middle tile on Client Supplies.
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.
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".
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
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
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.
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.
From the View Order window you opened in Scenario 1, click Reorder.
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
Check the ORDER OVERVIEW block names three things: ORIGINAL ORDER (the number you came from), CLIENT and SHIPPING LOCATION.
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.
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.
ClickCancel once, to prove nothing happens when you back out. Re-open Reorder.
ClickCreate Draft Order and wait.
The button is copying the order and its lines while you wait, so give it a few seconds.
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
ClickReview 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).
ClickResume 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.
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.
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.
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.
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.
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.
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
ClickRemove 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
Wait a few seconds without clicking. The button quietly goes back to Remove on its own — that's the safety catch, not a fault.
ClickRemove again, then click Confirm? while it is still armed.
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.
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.
Keep removing lines on the Review step until only one line is left. The Order Items heading should read 1 items.
ClickRemove on that final line.
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
Confirm the line is still there and the button never went to Confirm? — the check happens before the control is even armed.
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.
Send it somewhere else, with a note for this delivery only
Updated from your feedbackNot 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.
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).
Read the DELIVERING TO: line — it names the location the order was copied with.
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
Click the middle of the three small icon buttons on that card — hovering it shows Add delivery instructions or Edit delivery instructions.
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.
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.
ClickSave, then Continue to reach Confirm Order & Submit.
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.
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.
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.
ClickPlace Order and wait a few seconds.
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
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.
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.
OpenMy 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.
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.
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.
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
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.
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.
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.
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.
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.
What you're checking: the search box and the page numbers, and that they behave sensibly together — including when a search finds nothing.
OnMy Order History, note the footer line at the bottom-left: Showing 1–10 of n orders. Ten rows per page is the rule.
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
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.
Copy an order number you can see, then type the last four digits of it into Search by order number… at the top.
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
Type nonsense such as zzzz into the search box. The list empties and reads No orders match this filter. — not a blank panel.
Clear the search box and confirm the full list and the page numbers come back.
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.
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.
OpenMy 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
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.
Click the n deliveries pill on that row — the pill itself, not the row.
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
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.
Click one of the deliveries. It opens as an ordinary order page.
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.
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.
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.
Open any completed order from My Order History.
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
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.
Compare those quantities against the confirmation you were given when the order was placed — they must agree.
Scroll down to the Details card (Client, Order Date, Created, Status) and then the Shipping card.
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
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.
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.
What you're checking: that an order which didn't go straight through explains itself on its own page, in words rather than codes.
OpenMy 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.
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
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.
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.
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.
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.
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.
OpenOrder Supplies from Client Supplies and wait for the product list to appear.
Read the teal band near the top: ACTIVE RECURRING ORDERS — You have n active recurring orders scheduled. Click to view details.
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.
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
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.
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.
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.
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.
OpenMy Order History and open any order you want to ask about. Note its number.
ClickSubmit an Order Inquiry — it sits beside View Order (or Resume Order) under the Order Progress card.
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
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".
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.
Type a real-sounding question into Description, for example "When will this order arrive? I need the tubes before Friday."
ClickNext and wait a few seconds.
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
ClickClose 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.
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?".
Stay on the order you raised the inquiry from and reload the page.
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."
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.
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.
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
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.
Read the Question about an order? card below it — it explains the two tags in the same words this scenario just used.
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.
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.
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.
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.
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
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.
Confirm the line "Our support team will reach out by email with any updates." has gone. It belongs to the waiting state only.
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
CheckAt 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.
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.
Open a completed order and click View Order to bring up its confirmation screen.
ConfirmSubmit 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.
Raise a second inquiry from here about a different order, using the same two fields, and note its case number.
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.
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.
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.
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.
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.
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.
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
Check the CLIENT / FACILITY box in the Filters panel — it already names your practice. You never have to pick it.
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.
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.
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
Change your mind once: remove one of the products with Remove and add a different one instead. The counter and the cart follow immediately.
ClickContinue 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.
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.
OnReview 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
ReadSHIP 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.
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.
ClickContinue 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
ClickContinue again to reach Confirm Order & Submit.
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
UseBack 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.
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.
Read the line beneath the Order Summary: "By placing this order, you confirm all details are correct."
ClickPlace Order and wait. The order is being checked against your practice's supply allowance while you wait, so give it a few seconds.
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
Click the small copy icon inside the order-number chip and paste it somewhere to check it copied the number cleanly.
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.
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.
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.
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.
Leave the confirmation — click the back arrow, ‹ Order Supplies, at the top-left — and open My Order History from Client Supplies.
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
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.
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
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.
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.
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.
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.
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.
OpenClient 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.
ClickContinue to Review.
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
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.
ClickHow 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
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.
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.
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.
Carry on from Scenario 1: click Continue through the Shipping Address and Confirm steps.
ClickPlace Order and wait for the Submitted screen.
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
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.
ClickView 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.
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.
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.
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.
Open your test client record in Salesforce and go to the Details tab.
Find the Compliance Information section and read the three fields in it: Client Number, Client Segment and Compliance Exclusion.
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.
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.
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.
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.
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.
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.
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.
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
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.
OpenHow 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
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.
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.
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.
Click the amber n item(s) need justification button.
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
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.
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.
PickOther and confirm a free-text Additional Details box appears underneath. Type a sentence into it.
Change the picker to one of the named categories and confirm the free-text box disappears again — the categories stand on their own.
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
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.
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.
Carry on from Scenario 2 through Shipping Address and Confirm, then click Place Order.
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.
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.
Check the status. The Order Summary should read IN PROGRESS, not Approved. That status is what holds the order back from Workday.
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.
OpenView 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.
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.
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.
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.
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.
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.
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
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").
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.
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.
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.
Find the client: ID or name, never the pasted heading
Updated from your feedbackNot 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.
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.
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
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.
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.
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.
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.
Create Order is the first button, and the Orders list is back
Updated from your feedbackNot 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.
Open your test client record and look at the row of buttons on the right of the header.
ConfirmCreate 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
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.
ClickOrders. 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.
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.
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.
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.
ClickCreate 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
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.
Note the line above the product list — "n products found". Write that number down; the next module explains where it comes from.
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.
ClickContinue to Review at the top right.
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.
OpenORDER 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.
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.
ClickContinue.
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.
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.
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
Click the card you want to ship to (the default is already selected) and then Continue.
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"
ClickPlace Order and wait — this takes a few seconds while the order is checked against the client's supply allowance.
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.
ClickView 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.
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
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.
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.
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.
ClickContinue to Review, then click Save Draft at the top right rather than continuing.
Close the window with the X at the top right.
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.
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.
ClickResume Order. The wizard reopens on the step you left, with both products and both quantities exactly as you set them.
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.
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.
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.
Open your test client record and stay on the Details tab.
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.
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
FindExclusive 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.
FindRelated 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.
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
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.
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.
Click the App Launcher (the grid of nine dots, top left), type Price Books and open it.
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.
Click the small arrow beside Recently Viewed to open the list-view picker, and choose All Price Books.
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.
Pin the view if you like — the pin icon beside the view name makes All Price Books your default next time.
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.
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.
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.
Go back to the client record and click Create Order.
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
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.
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.
Close the window with the X.
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.
Flip the exclusive switch and watch the catalog change
Updated from your feedbackNot 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.
Open your test client, expand Budgetary Responsibility (Admin Only) and write down the current values of Exclusive Supply Product Access? and Related Price Book.
ClickCreate Order, note the "n products found" count for the current catalog, then close the window.
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.
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.
ClickCreate 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
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.
Close the window without placing an order.
SetExclusive 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.
The finished order remembers which catalog it used
Updated from your feedbackNot 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.
Place a small order for your test client using Create Order (one item is enough), and note the order number from the confirmation.
Close the window and open the client's Orders related list — its link sits in the strip under the highlights, right after Client History.
Find your new order — click the Order Number heading if the oldest order is on top — and open it.
On theDetailstab, find the Price Book field and confirm it names the same price book as the client's Related Price Book.
Click the Related tab and open Order Products. Every line should be a product from that catalog.
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.
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.
Create a facility location: record type, address and all
Updated from your feedbackNot 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.
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
ClickNew. 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
Confirm the four choices are listed — Courier (the default), Courier + Supplies, Quest Only PU, Supplies — select Courier + Supplies and click Next.
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
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.
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
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.
ClickSave 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.
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.
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.
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
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.
Check the Address field on the same tab prints the street, the city, the state and the ZIP you typed.
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
Find your new location's card and click its third small icon, View map and altitude.
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
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.
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.
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.
On theDetailstab, 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
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.
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.
ConfirmWorkday 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.
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.
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.
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."
Click the pencil beside Status and open the list. Three values are offered: Active, Inactive, Active - Temp Facility.
ChooseInactive and click Save. Confirm the record saves with no error and Status now reads Inactive.
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.
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.
Close the wizard, reopen the location, set Status back to Active and Save.
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.
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.
Open the client record, click Create Order, add an item, Continue to Review, choose a Ship To Contact, then Continue to reach Shipping Address.
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).
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.
Confirm the note now prints on the location's card, under the address, without opening anything.
Select that card, click Continue, and check the Confirm screen: the note appears under DELIVERY INSTRUCTIONS beneath the shipping address.
ClickPlace Order, then open the resulting order from the client's Orders list.
On the order'sDetailstab, find Order Memo. It reads "Delivery Instructions:" followed by your note — that is how the instruction reaches fulfilment.
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.
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.
Copy the order number — and prove it really copied
Updated from your feedbackNot 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.
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.
Place a small order for your test client from Create Order — one item, any contact — and continue through to the Submitted screen.
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".
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
Prove it. Click into any text box and press Ctrl+V (Cmd+V). The order number should paste — not the word MARKER.
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.
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.
Turn an order into a schedule, then open the template
Updated from your feedbackNot 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.
On the Submitted screen from Scenario 1, find the row of five actions and click Set Up Recurring Order.
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
Set the Frequency. Open the list and confirm it offers Monthly and Bi-Weekly. Leave it on Monthly.
Set a Start Date of today. Leave End Date empty — it is optional and means "keep going".
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.
ClickCreate Recurring Order and wait a few seconds.
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
ClickView 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.
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.
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.
Open the template record from Scenario 2 (or from the client's Orders related list — templates appear there too).
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.
On theDetailstab, read theOrder Template Informationsection: 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
ConfirmTemplate Status reads Active and Next Run Date matches the date the preview showed you when you set the schedule up.
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.
Click the Related tab and confirm Order Products lists the items the schedule will send each time.
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.
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.
Open your template record and click Edit Recurring Order Settings in the highlights panel.
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
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.
Reopen the window and click Pause Recurring Order.
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.
ClickResume Recurring Order and confirm it returns to Active with its next run date intact.
Now cancel it. Reopen the window and click Cancel Recurring Order. Confirm Template Status on the record becomes Cancelled.
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.
What the schedule produces — and the new automatic review
Updated from your feedbackNot 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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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."
Open the order the inquiry was raised against, from the client's Orders related list.
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
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.
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.
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
ConfirmCase Owner reads Supply Order Support — the queue, not a person. That is the routing working.
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.
Answer the client — one field, and the portal changes
Updated from your feedbackNot 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.
Open the case from Scenario 1 and go to the Details tab.
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.
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
ClickSave 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.
Confirm the case saves and Client Response now shows your text on the record.
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.
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
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?"
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.
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.
Open the case you answered in Scenario 2. Case Owner still reads Supply Order Support.
ClickTake Ownership in the header and confirm. Case Owner becomes your name — that is how a queue case becomes somebody's job.
ClickClose Case in the header.
Try to close it without a comment first. Leave Close Case Comments empty and save.
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.
Type a closing note — "Delivery date confirmed to client, no further action" — and save.
ConfirmStatus is now Closed and a Date/Time Closed has been stamped.
Check the Case History panel on the right: it lists the creation, the status changes, and who made each one, with times.
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.
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.
Open one of the orders you placed earlier from the client's Orders related list.
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.
Click the In Fulfillment stage on the Path and then Mark Status as Complete.
Confirm the save completes with no error banner and the Path moves on. The Status field on the Details tab agrees with it.
Open the Related tab and read Order History. A new row logs the status change — old value, new value, your name and the time.
CheckOrder Products on the same tab: the line items and quantities, unchanged by the status move.
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.
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.
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.
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.
Place a fresh order for that client from Create Order, choosing that contact as the Ship To Contact.
Check the inbox within a few minutes. A confirmation should arrive naming the order number.
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?
Now change that order's status as you did in Scenario 4 and check whether a second message arrives for the change.
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.
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.
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.
Confirm you own the client. Open the client record, go to the Details tab and check Client Owner reads your name.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
Add a line into Comments — optional for an approval, required for a denial.
ClickApprove with changes and wait for the screen to finish.
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.
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
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.
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.
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.
Open the review panel on your second pending order.
Leave Comments empty and click Deny entire order.
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
ClickConfirm 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.
ClickBack 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."
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.
ClickDeny entire order again, then Confirm deny.
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.
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.
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.
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
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.
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.
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.
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.
ClickSubmit 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).
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.
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.
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.
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.
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.
Check Order History in the right-hand column: it should show the status moving to Denied, with your name and the time.
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.
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.
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.
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.
Note the exact time you clicked Place Order, and the order number.
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
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.
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.
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.
Open your Scenario 1 order in Salesforce.
Check the status.Status should now be Approved — released, not denied. The order is on its way.
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.
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.
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
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
Check My Order History: the row should have moved out of In Review and now reads the trimmed quantity.
Check the inbox. An email should confirm the outcome and list what actually shipped against what was requested.
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.
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.
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.
Check the Compliance Status section.Compliance Status reads Auto Released — the same timeout path — while Compliance Locked is ticked.
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.
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.
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.
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.
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.
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.
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.
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
Confirm Compliance Locked is ticked on all three. Approval, denial and auto-release all lock the order. The lock means "settled", not "successful".
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.
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).
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.
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.
Open the Client Supplies site and open My Order History from Client Supplies.
Find a Draft order first — its row offers Resume Order, which reopens the wizard so the client can carry on editing.
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
ClickView Order on the auto-released one and confirm the quantities are shown as text with no editable boxes, no Remove control and no Save.
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.
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.
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.
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.
Open one of your over-limit orders in Salesforce and go to the Compliance Status section.
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.
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.
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.
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.
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.
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.
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 minSQL2-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.
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.
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.
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
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.
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.
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.
Scenario 2 · ~7 minSQL2-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.
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.
Read the Compliance Decision Reason and satisfy yourself you can explain, in one sentence, why the engine declined this delivery.
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.
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.
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).
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.
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.
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.
Find a delivery sitting at In Progress with Order Source Recurring. Ask us for one if you have none.
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.
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.
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.
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.
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.
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.
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.
Open the order that auto-released in module PB8 — it has the longest story — and click the Compliance Log tab.
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
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.
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.
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.
Use the filter chips — Lifecycle, Evaluation, Decisions, Line Changes — and confirm each narrows the list and that the counts on the chips are right.
Use the search box to find an entry by product name or reason.
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.
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.
ClickCompliance Engine Dashboard in the app's top navigation bar.
ClickRefresh 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
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.
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.
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.
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
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.
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.
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.
ClickCompliance Configuration in the app's top navigation bar. The page is headed Review & edit rules with the active record named beside it.
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
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
Check a denied order. Its Workday fields should be empty. Nothing declined is ever handed over.
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.
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.
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.
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.
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
"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.
"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.
"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.
"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.
"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.
"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.
"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".
"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.
"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.
"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.
"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.
"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.
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.
"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.
"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.
"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.
"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.
"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.
"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.
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.
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.
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.
“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)
“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.
“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)
“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)
“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.
“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.
“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
“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.
“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.
“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.
“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.
“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.
“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."
“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.
“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)
“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.
“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
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)
“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.
“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.
“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)
“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".
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.
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".
ClickSupply 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.
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.
TypeAPTIMA in Search all supplies. The list narrows to SUPPLY #40274 — APTIMA SPECIMEN TRANSFER KIT PRINTABLE 100T/KT.
ClickEdit 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.
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.
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.
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.
ClickCancel. Nothing has changed.
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.
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.
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.
On the Supply Images page, searchHEREDITARY and click Edit on SUPPLY #900004.
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).
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.
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.
ClickSave 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.
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 #.
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.
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.
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.
ClickNew 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.
Fill it in:Supply nameUAT Test Supply (AC) with your own initials · Supply #UAT-AC · Unit of measure any value · Customer-facing nameTest supply — please ignore (AC) · Description one line · Price10 · Unit cost2.50.
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.
Tick both price books — Standard Price Book and Family Practice >20 — so the supply shows for every client type, and click Create supply.
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.
Check the portal. Refresh the Order Supplies catalog; your supply is there with its customer-facing name. Do not order it.
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.