# Validation Report: URS-004 **Title:** Admin approve or reject a sales representative **Date:** 2026-08-03T23:01:56.937Z **Duration:** 67.2s **Overall Status:** ✅ PASS ## User Requirement > The system shall allow Vantis admins to approve or reject a sales representative *Source: `User_Requirement_Specifications_Vantis_DeviceFlow.xlsx` — the run below proves the system meets this requirement.* ## Environment - **Inbox URL:** http://localhost:37779 - **Database:** localhost:38971/cc_repinbox_dev ## Setup Status: ✅ PASS ## Test Steps Each step below corresponds to one Playwright test that ran sequentially. Screenshots and video recordings provide visual evidence of the UI behaviour. ### 1. Step 1: Admin navigates to rep management — ✅ PASS **What this step proves:** Proves that a Vantis admin (Alex) can authenticate and reach the Representatives management page. Both Corveta reps — Blair (pending approval) and Rana (active) — appear in the roster, establishing admin context for the approve/reject actions that follow. **Audit events generated by this step:** *(Evidence matched by declared name — step timing not available or no events fell in window)* | Time | Type | Action | User | Org | Performed | |------|------|--------|------|-----|-----------| | 2026-08-03 23:02:04Z | user_log | user:login | alex.admin@vantismedical.com | Vantis | — | | 2026-08-03 23:02:15Z | user_log | user:login | alex.admin@vantismedical.com | Vantis | — | | 2026-08-03 23:02:26Z | user_log | user:login | blair.bennett@corvetasurgical.com | Corveta Surgical Group | — | | 2026-08-03 23:02:35Z | user_log | user:login | rana.reyes@corvetasurgical.com | Corveta Surgical Group | — | | 2026-08-03 23:02:41Z | user_log | user:login | alex.admin@vantismedical.com | Vantis | — | | 2026-08-03 23:02:49Z | user_log | user:login | blair.bennett@corvetasurgical.com | Corveta Surgical Group | — | **Screenshots:** ![step 01 admin logged in](screenshots/step-01-admin-logged-in.png) ![step 01 rep list](screenshots/step-01-rep-list.png) **Video recording:** [▶ Watch step recording](videos/step-01-admin-navigate.webm) --- ### 2. Step 2: Admin rejects Blair — ✅ PASS **What this step proves:** Alex opens Blair's detail page, clicks Reject Representative, supplies a rejection reason, and confirms. Proves that an admin has an in-app control to deny a rep onboarding. The relationship row moves to status='rejected', active=false, and a rep_creation_request_rejected notification is dispatched to the distributor. **Audit events generated by this step:** *(Evidence scoped to step execution window: 2026-08-03T23:02:19.747Z → 2026-08-03T23:02:23.804Z)* | Time | Type | Action | User | Org | Performed | |------|------|--------|------|-----|-----------| | 2026-08-03 23:02:23Z | user_log | rep_onboarding_request_rejected | alex.admin@vantismedical.com | Vantis | — | **Emails triggered by this step:** *(Evidence matched by declared name — step timing not available or no events fell in window)* **Email 1: Representative Request Rejected - Vantis** Template: `Representative_Request_Rejected_-_Vantis` ![Representative Request Rejected - Vantis](screenshots/emails/2026-08-03T23-02-24-427Z-Representative_Request_Rejected_-_Vantis.png) **Screenshots:** ![step 02 bob detail pending](screenshots/step-02-bob-detail-pending.png) ![step 02 reject dialog](screenshots/step-02-reject-dialog.png) ![step 02 bob detail rejected](screenshots/step-02-bob-detail-rejected.png) **Video recording:** [▶ Watch step recording](videos/step-02-admin-rejects.webm) --- ### 3. Step 3: Blair blocked from creating orders — ✅ PASS **What this step proves:** Blair logs in after being rejected and opens the order creation page. Vantis is filtered out of the manufacturer dropdown because `getAvailableFulfillingOrganizations` requires an active representation relationship. Proves the admin action is a hard restriction on downstream order creation — not just a cosmetic UI change. **Audit events generated by this step:** *(Evidence matched by declared name — step timing not available or no events fell in window)* | Time | Type | Action | User | Org | Performed | |------|------|--------|------|-----|-----------| | 2026-08-03 23:02:04Z | user_log | user:login | alex.admin@vantismedical.com | Vantis | — | | 2026-08-03 23:02:15Z | user_log | user:login | alex.admin@vantismedical.com | Vantis | — | | 2026-08-03 23:02:26Z | user_log | user:login | blair.bennett@corvetasurgical.com | Corveta Surgical Group | — | | 2026-08-03 23:02:35Z | user_log | user:login | rana.reyes@corvetasurgical.com | Corveta Surgical Group | — | | 2026-08-03 23:02:41Z | user_log | user:login | alex.admin@vantismedical.com | Vantis | — | | 2026-08-03 23:02:49Z | user_log | user:login | blair.bennett@corvetasurgical.com | Corveta Surgical Group | — | **Screenshots:** ![step 03 bob no vantis](screenshots/step-03-bob-no-vantis.png) **Video recording:** [▶ Watch step recording](videos/step-03-bob-blocked.webm) --- ### 4. Step 4: Rana (control) can still create orders — ✅ PASS **What this step proves:** Rana, an unrelated Corveta rep, is unaffected by the action taken on Blair. He reaches Step 2 of the order form as normal, proving that admin decisions are scoped to the rep under review and do not inadvertently strip privileges from other reps. **Audit events generated by this step:** *(Evidence matched by declared name — step timing not available or no events fell in window)* | Time | Type | Action | User | Org | Performed | |------|------|--------|------|-----|-----------| | 2026-08-03 23:02:04Z | user_log | user:login | alex.admin@vantismedical.com | Vantis | — | | 2026-08-03 23:02:15Z | user_log | user:login | alex.admin@vantismedical.com | Vantis | — | | 2026-08-03 23:02:26Z | user_log | user:login | blair.bennett@corvetasurgical.com | Corveta Surgical Group | — | | 2026-08-03 23:02:35Z | user_log | user:login | rana.reyes@corvetasurgical.com | Corveta Surgical Group | — | | 2026-08-03 23:02:41Z | user_log | user:login | alex.admin@vantismedical.com | Vantis | — | | 2026-08-03 23:02:49Z | user_log | user:login | blair.bennett@corvetasurgical.com | Corveta Surgical Group | — | **Screenshots:** ![step 04 ryan order form](screenshots/step-04-ryan-order-form.png) **Video recording:** [▶ Watch step recording](videos/step-04-ryan-control.webm) --- ### 5. Step 5: Admin approves Blair — ✅ PASS **What this step proves:** After the test harness returns Blair's status to 'proposed', Alex approves him through the UI's Approve Representative flow. The relationship row becomes status='active', active=true; a rep_created notification is dispatched to Corveta announcing the approval. **Audit events generated by this step:** *(Evidence scoped to step execution window: 2026-08-03T23:02:44.741Z → 2026-08-03T23:02:46.929Z)* | Time | Type | Action | User | Org | Performed | |------|------|--------|------|-----|-----------| | 2026-08-03 23:02:46Z | user_log | rep_onboarding_request_approved | alex.admin@vantismedical.com | Vantis | — | **Emails triggered by this step:** *(Evidence matched by declared name — step timing not available or no events fell in window)* **Email 1: Representative Account Approved - Vantis** Template: `Representative_Account_Approved_-_Vantis` ![Representative Account Approved - Vantis](screenshots/emails/2026-08-03T23-02-47-073Z-Representative_Account_Approved_-_Vantis.png) **Screenshots:** ![step 05 bob detail pending again](screenshots/step-05-bob-detail-pending-again.png) ![step 05 approve dialog](screenshots/step-05-approve-dialog.png) ![step 05 bob detail approved](screenshots/step-05-bob-detail-approved.png) **Video recording:** [▶ Watch step recording](videos/step-05-admin-approves.webm) --- ### 6. Step 6: Blair submits an order after approval — ✅ PASS **What this step proves:** Now-approved Blair logs back in, reaches the order form, picks a delivery location, adds a product, and submits. Proves the restriction lifts immediately on approval — the admin's status change takes effect without any further action. The order request persists in the database for the DB-validation phase to confirm. **Audit events generated by this step:** *(Evidence scoped to step execution window: 2026-08-03T23:02:56.153Z → 2026-08-03T23:03:01.092Z)* | Time | Type | Action | User | Org | Performed | |------|------|--------|------|-----|-----------| | 2026-08-03 23:03:00Z | checklist | checklists.create | blair.bennett@corvetasurgical.com | Vantis | — | | 2026-08-03 23:03:00Z | decision | order_request_created | blair.bennett@corvetasurgical.com | Vantis | yes | **Screenshots:** ![step 06 order step2](screenshots/step-06-order-step2.png) ![step 06 order review](screenshots/step-06-order-review.png) ![step 06 order submitted](screenshots/step-06-order-submitted.png) **Video recording:** [▶ Watch step recording](videos/step-06-bob-orders.webm) --- ## Database Validations The following SQL queries ran against the application database after the Playwright scenarios completed. Each query asserts a specific condition that proves the feature under test persisted its data correctly. ### Blair's relationship ended the run as active — ✅ PASS **Assertion:** After the approve flow Blair's relationship should be status='active', active=true. ```sql SELECT id, status, active, rejection_reason FROM organization_representation_relationships WHERE id = $1 ``` | id | status | active | rejection_reason | | --- | --- | --- | --- | | 84c5d6e7-f8a9-0123-8901-234567890123 | active | true | NULL | ### Rejection status transition recorded — ✅ PASS **Assertion:** A proposed→rejected transition should have been recorded during the test run. ```sql SELECT from_status, to_status, reason, created_at FROM organization_representation_request_status_changes WHERE relationship_id = $1 AND to_status = 'rejected' AND created_at > NOW() - INTERVAL '30 minutes' ORDER BY created_at DESC ``` | from_status | to_status | reason | created_at | | --- | --- | --- | --- | | proposed | rejected | URS-004 validation test: admin rejecting rep to verify order-creation is blocked. | 2026-08-03T23:02:23.066Z | ### Approval status transition recorded — ✅ PASS **Assertion:** A proposed→active transition should have been recorded during the test run. ```sql SELECT from_status, to_status, created_at FROM organization_representation_request_status_changes WHERE relationship_id = $1 AND to_status = 'active' AND created_at > NOW() - INTERVAL '30 minutes' ORDER BY created_at DESC ``` | from_status | to_status | created_at | | --- | --- | --- | | proposed | active | 2026-08-03T23:02:46.236Z | ### Approved rep successfully submitted an order — ✅ PASS **Assertion:** At least one order_requests row should exist, tagged with the URS-004 marker. ```sql SELECT id, request_number, status, order_type, created_at FROM order_requests WHERE requested_by_user_id = $1 AND notes LIKE $2 ORDER BY created_at DESC ``` | id | request_number | status | order_type | created_at | | --- | --- | --- | --- | --- | | 019fc9dd-c030-787c-984c-7a3b0e7cdb7d | OR-1 | submitted | dropship | 2026-08-03T23:03:00.889Z | ### Audit events logged for approve and reject — ✅ PASS **Assertion:** audit_events should include both rep_onboarding_request_approved and rep_onboarding_request_rejected actions from this run. ```sql SELECT event_type, action, created_at FROM audit_events WHERE event_type = 'user_log' AND action IN ('rep_onboarding_request_approved', 'rep_onboarding_request_rejected') AND created_at > NOW() - INTERVAL '30 minutes' ORDER BY created_at DESC ``` | event_type | action | created_at | | --- | --- | --- | | user_log | rep_onboarding_request_approved | 2026-08-03T23:02:46.309Z | | user_log | rep_onboarding_request_rejected | 2026-08-03T23:02:23.285Z | ## Audit & Email Assertion Ledger Per-declaration outcome of every `expectedAuditActions` and `expectedEmailTemplates` entry written into the orchestrator. Missing evidence here is a real test failure, not a soft warning. ### Audit Action Assertions Each row asserts that a declared `expectedAuditActions` entry produced a matching row in `audit_events`. A ❌ flips overall status to FAIL — the declaration is real proof, not just an annotation. | Step | Expected Audit Action | Found | |------|-----------------------|-------| | Step 1: Admin navigates to rep management | `user_log:user:login` | ✅ | | Step 2: Admin rejects Blair | `user_log:rep_onboarding_request_rejected` | ✅ | | Step 3: Blair blocked from creating orders | `user_log:user:login` | ✅ | | Step 4: Rana (control) can still create orders | `user_log:user:login` | ✅ | | Step 5: Admin approves Blair | `user_log:rep_onboarding_request_approved` | ✅ | | Step 6: Blair submits an order after approval | `user_log:user:login` | ✅ | | Step 6: Blair submits an order after approval | `decision:order_request_created` | ✅ | ### Email Template Assertions Each row asserts that a declared `expectedEmailTemplates` entry was matched (case-insensitive substring) by a captured email subject or template. A ❌ flips overall status to FAIL. | Step | Expected Template | Found | |------|-------------------|-------| | Step 2: Admin rejects Blair | `Representative Request Rejected` | ✅ | | Step 5: Admin approves Blair | `Representative Account Approved` | ✅ | ## Audit Log Events Every row written to `audit_events` while this test was running (scoped to the demo organizations). Provides compliance evidence that user actions are traced end-to-end (URS-003). **Capture window start:** 2026-08-03T23:01:55.225Z
Query used to capture events ```sql SELECT ae.created_at, ae.event_type, ae.action, ae.user_id, u.email AS user_email, ae.organization_id, o.name AS organization_name, ae.object_id, ae.secondary_object_id, ae.payload, ae.route, ae.trace_id FROM audit_events ae LEFT JOIN users u ON u.id = ae.user_id LEFT JOIN organizations o ON o.id = ae.organization_id WHERE ae.created_at >= $1 AND ae.organization_id = ANY($2::uuid[]) ORDER BY ae.created_at ASC ```
12 event(s) captured: | Time | Type | Action | User | Org | Object ID | Performed | Reason | |------|------|--------|------|-----|-----------|-----------|--------| | 2026-08-03 23:02:04Z | user_log | user:login | alex.admin@vantismedical.com | Vantis | — | — | | | 2026-08-03 23:02:15Z | user_log | user:login | alex.admin@vantismedical.com | Vantis | — | — | | | 2026-08-03 23:02:23Z | user_log | rep_onboarding_request_rejected | alex.admin@vantismedical.com | Vantis | 84c5d6e7-f8a9-0123-8901-234567890123 | — | | | 2026-08-03 23:02:24Z | transactional_email | rep_creation_request_rejected | — | Corveta Surgical Group | — | — | | | 2026-08-03 23:02:26Z | user_log | user:login | blair.bennett@corvetasurgical.com | Corveta Surgical Group | — | — | | | 2026-08-03 23:02:35Z | user_log | user:login | rana.reyes@corvetasurgical.com | Corveta Surgical Group | — | — | | | 2026-08-03 23:02:41Z | user_log | user:login | alex.admin@vantismedical.com | Vantis | — | — | | | 2026-08-03 23:02:46Z | user_log | rep_onboarding_request_approved | alex.admin@vantismedical.com | Vantis | 84c5d6e7-f8a9-0123-8901-234567890123 | — | | | 2026-08-03 23:02:47Z | transactional_email | rep_created | — | Corveta Surgical Group | — | — | | | 2026-08-03 23:02:49Z | user_log | user:login | blair.bennett@corvetasurgical.com | Corveta Surgical Group | — | — | | | 2026-08-03 23:03:00Z | checklist | checklists.create | blair.bennett@corvetasurgical.com | Vantis | 019fc9dd-c041-7782-9d36-90b4c905af21 | — | | | 2026-08-03 23:03:00Z | decision | order_request_created | blair.bennett@corvetasurgical.com | Vantis | 019fc9dd-c030-787c-984c-7a3b0e7cdb7d | yes | Order request OR-1 created (importSource=manual) | ## Email Evidence 2 notification email(s) were captured during this test run. Each email is rendered as a screenshot for compliance review. ### 1. Representative Request Rejected - Vantis **Template:** `Representative_Request_Rejected_-_Vantis` ![Representative Request Rejected - Vantis](screenshots/emails/2026-08-03T23-02-24-427Z-Representative_Request_Rejected_-_Vantis.png) ### 2. Representative Account Approved - Vantis **Template:** `Representative_Account_Approved_-_Vantis` ![Representative Account Approved - Vantis](screenshots/emails/2026-08-03T23-02-47-073Z-Representative_Account_Approved_-_Vantis.png)