Documentation
Tutorials
Workflows
Kebab actions
Daily Work
Dashboard & Reports
Quality Control
ISO 17025
Logs
Contacts
Billing
Analysis Setup
Settings
Initial Setup
Help & Reference
Architecture decisions
Kebab actions
0:000:00

Record customer consultation (§7.4.3)

Goal

When a sample arrives at the laboratory in a doubtful state — that is, the Condition on Arrival field (conditionOnArrival) is anything other than OK — ISO/IEC 17025:2017 §7.4.3 requires the laboratory to consult the customer, agree on how the item should be handled and log the documented outcome of that consultation before any analysis is performed or any result released.

This how-to recipe shows how that consultation is captured inside the sample edit dialog so the chain of custody and the quality file remain complete and auditable by the accreditation body (ESYD).


Prerequisites

The §7.4.3 sub-block only becomes relevant — and only becomes editable — when all of the following hold:

  • The sample has already been registered and is in the RECEIVED status (arrived at the lab). The block is also available on newly created samples through the same dialog.
  • The Condition on Arrival field is set to a non-OK value — one of DAMAGED, INSUFFICIENT, UNPRESERVED or OTHER.
  • The customer's contact details (phone, email) are populated on the linked Contacts card, so the consultation is genuinely reachable and traceable.
  • You are signed in as a user with edit rights on samples (role LAB_TECHNICIAN, QUALITY_MANAGER or LAB_DIRECTOR).

Steps

  1. Open the sample edit dialog from the /samples list — either by clicking the sample code or selecting Edit from the row kebab menu.
  2. Locate the Lab Reception section and change the Condition on Arrival field to a non-OK value (for example Damaged).
  3. As soon as the value differs from OK, an @if-gated reveal automatically displays the CUSTOMER CONSULTATION (MANDATORY) sub-block, marked with a red left bar and a deep-link to clause 7.4.3.
  4. Fill in the mandatory fields:
  • Consultation Timestamp (customerConsultedAt) — the exact moment the call/email took place.
  • Lab Contact Person (consultedById) — the lab employee who actually spoke with the customer.
  • Consultation Outcome (consultationOutcome) — one of:
  • PROCEED_AS_ISProceed as is (the customer authorises continuation; the Customer Authorised to Proceed checkbox is also required).
  • REJECTReject sample (the customer agrees to reject).
  • RESAMPLERe-sample (the customer requests new sampling).
  1. Use the status notes (conditionNotes) to capture a short narrative of the conversation — who spoke, via which channel, what information was exchanged.
  2. Click Save. The system validates the §7.4.3 bundle and, if the outcome dictates it, performs an automatic status transition:
  • REJECT → sample status becomes REJECTED.
  • RESAMPLE → sample status becomes CANCELLED.
  • PROCEED_AS_IS → the status is unchanged and the sample continues through the analysis flow with the relevant disclaimer on the final report (§7.8.2.2).
If any mandatory field is missing, the server returns the error ISO_17025_7_4_3_CONSULTATION_REQUIRED with the list of missing fields, and the save is aborted.

How to choose the consultation outcome

The outcome you pick strictly reflects the customer's own decision — not the lab's judgement. Use the following decision guide:

  • PROCEED_AS_IS. The customer is aware of the problem (e.g. cracked container, slightly low volume) and asks for the analysis to continue "at their own risk". The final report automatically carries the §7.8.2.2 disclaimer that the result refers to "the sample as received".
  • REJECT. The customer acknowledges the sample is not representative and agrees that it should NOT be analysed. No report is issued and the analysis is not charged.
  • RESAMPLE. The customer asks for a new sample to be sent in place of the problematic one. The current sample is cancelled — create a fresh sample record when the replacement arrives.
Ethical note: §7.4.3 does NOT allow the laboratory to decide unilaterally. If you cannot reach the customer, do not pick an outcome arbitrarily — leave the sample pending and document the contact attempts in the notes.

What happens behind the scenes

The flow is enforced by three coordinated layers:

  • Form-schema visibility gate. The template at sample-upsert-form.html:294 carries the guard @if (sampleForm().conditionOnArrival().value() !== 'OK') which reveals the §7.4.3 sub-block only when needed; the three core fields (customerConsultedAt, customerConsultedById, consultationOutcome) are flagged [required]="true" and the signal-form schema applies applyWhen() for conditional-required validation before the payload ever reaches the server.
  • Backend resolver guard. SampleResolver invokes assertConsultationComplete() (sample.resolver.ts:1540) on every create/update; that function computes the missing fields and throws a GraphQLError with code ISO_17025_7_4_3_CONSULTATION_REQUIRED. Additionally, when the outcome is PROCEED_AS_IS the customerAuthorisedProceed=true flag is also required, otherwise ISO_17025_7_4_3_AUTHORISATION_REQUIRED is raised.
  • Automatic status transition. applyConsultationStatusTransition() (sample.resolver.ts:1585) reads the ConsultationOutcome enum (enums/consultation-outcome.enum.ts) and:
  • On REJECT or RESAMPLE calls repository.update(id, { status }) setting the terminal status to REJECTED or CANCELLED respectively.
  • Writes a SampleStatusLog entry with noteCode = 'SAMPLE_REJECTED_BY_CUSTOMER' or 'SAMPLE_CANCELLED_FOR_RESAMPLING' and noteParams carrying the consultation timestamp and the lab contact person — this is the evidence the ESYD assessor inspects.
  • Pushes a sampleStatusChanged event via pubSub.publish(…) plus a push notification, so the other operators' grids refresh without a manual reload.
  • The status flip also triggers the automated customer email via NotificationsService, carrying the consultation note code so the audit trail is complete on both sides of the conversation.
  • Idempotency. If the sample is already in the terminal status implied by the outcome, the transition is skipped — no duplicate SampleStatusLog rows and no duplicate emails are generated.


Worked example — cracked container

A soil-sample bottle arrives with a cracked lid and partial loss of content. The receiving technician:

  1. Creates or opens the sample record and sets conditionOnArrival = DAMAGED.
  2. Writes in the status notes: "Crack on lid, estimated ~10% content loss. Picture attached in the photos field."
  3. Calls the customer at 09:42. The customer asks the analysis to proceed on the remaining sample.
  4. Fills in customerConsultedAt = 2026-05-23 09:42, consultedById = self, consultationOutcome = PROCEED_AS_IS, and ticks customerAuthorisedProceed = true.
  5. Clicks Save. The sample status stays RECEIVED, the analysis report will carry the §7.8.2.2 disclaimer automatically and the quality file now contains the full trace.

Had the customer asked for a re-sample instead, the technician would have picked RESAMPLE, the sample status would have flipped to CANCELLED and the customer would have received an automated notification carrying the SAMPLE_CANCELLED_FOR_RESAMPLING reason code.


Audit trail — what the ESYD assessor will see

When the assessor asks for evidence of doubtful-item handling, the system produces on demand:

  • The Condition on Arrival field rendered on the result PDF and on the sample history view.
  • The SampleStatusLog row carrying the note code (SAMPLE_REJECTED_BY_CUSTOMER / SAMPLE_CANCELLED_FOR_RESAMPLING) and the noteParams showing who spoke and when.
  • The automated customer email (when a status transition applies) carrying the same note code — two-way confirmation.
  • The §7.8.2.2 disclaimer block on every report produced from a PROCEED_AS_IS sample, making the customer's authorisation explicit on the deliverable.

  • ISO/IEC 17025:2017 §7.4.3When any doubt about the suitability of a test or calibration item is identified, or when the item does not conform to the description provided, the laboratory shall consult the customer for further instructions before proceeding and shall record the outcome of this consultation.
  • Related documentation anchors: §7.4 (handling of test items), §7.5 (technical records), §7.8.2.2 (statements of conformity and disclaimers in result reports).
  • See also the in-app Workflow: Samples how-to for the broader sample lifecycle context in which §7.4.3 sits.