The Conditional Lot Find Behavior setting on the Quality Inspector Setup page controls which quality inspection test the system considers when evaluating whether a grade-based lot blocking rule should prevent a transaction. Choosing the right option depends on how your testing process works and which test result should be considered authoritative.

For a reference of all settings on the Quality Inspector Setup page, see the Quality Inspector Setup page.

Background: How grade-based lot blocking works

Before choosing a Conditional Lot Find Behavior, it helps to understand the feature it supports.

On the Quality Inspection Grades page, you can configure each grade with transaction-specific blocking rules. For example, you might configure the “Fail” grade to block sales shipping and picking, while the “Pass” grade allows all transactions. These blocking rules are evaluated per lot (or serial or package) based on the item tracking on the transaction being attempted.

When a user tries to perform a transaction involving a tracked lot (such as shipping a sales order line, picking inventory, posting consumption, or posting output), the system:

1. Searches for quality inspection tests that match the item, variant, lot, serial, and package on the transaction line.
2. Uses the Conditional Lot Find Behavior to determine which of the matching tests to evaluate.
3. Reads the grade on the selected test(s) and checks the grade’s blocking configuration for that transaction type.
4. Blocks or allows the transaction accordingly.

For an example, see the Restrict the Use of a Lot Transaction When a Test Fails in Quality Inspector -Insight Works Knowledge Base page.

Options overview

How to decide: key questions

Do you have multiple tests per lot?

If each lot only ever has one test, all six options produce the same result. This setting only matters when multiple tests can exist for the same item and lot combination, which can happen when:

• A lot is retested after a failure (creating retests).
• A lot is tested at different stages (e.g., receiving, production, and warehouse movement).

Should open (in-progress) tests influence blocking?

The six options are divided into two groups:

• Options that consider all tests: “Any test that matches,” “Only the most recently modified test,” and “Only the newest test/re-test”. Includes open tests.
• Options that only consider finished tests: “Any finished test that matches,” “Only the most recently modified finished test,” and “Only the newest finished test/re-test.”

If an open test should not block transactions (because the test is being worked on and does not yet have a definitive result) use one of the finished options. If an open test with an in-progress or incomplete grade should be able to block transactions (e.g., to hold material until inspection is complete), use one of the options that considers all tests.

Should one test override all others, or should any blocking test prevent the transaction?

• “Any” options (“Any test that matches” and “Any finished test that matches”) evaluate all matching tests. If even one test has a blocking grade, the transaction is blocked. This is the most conservative approach.
• “Most recently modified” and “newest” options evaluate only a single test. This means an older failed test will not block the transaction if a newer or more recently updated test has a passing grade. This is appropriate when the most current result should supersede prior results.

Example configurations

Scenario 1: simple blocking (most common)

Situation: Each lot is typically tested once. You want any test with a blocking grade to prevent the transaction. You do not have complex retesting workflows.

Recommended Setting: Any test that matches

Why: This is the default and simplest option. Since there is usually only one test per lot, the system evaluates that test. If you do happen to have multiple tests, the most conservative behavior applies, and any blocking grade on any test will prevent the transaction.

Scenario 2: retesting with corrective action

Situation: When a lot fails inspection, corrective action is taken and the lot is retested. Once the retest passes, the lot is released for use, and the original failed test no longer blocks transactions.

Recommended Setting: Only the newest test/re-test.

Why: The newest retest in the chain represents the most current inspection result. If the retest has a passing grade, the lot is unblocked, even though the original test still has a failing grade. This ensures the retesting process releases the lot once it passes.

Scenario 3: retesting, but only trust completed results

Situation: Same as Scenario 2, but you do not want an open (in-progress) retest to affect blocking. Until the retest is finished, the blocking status is based on the last completed test.

Recommended Setting: Only the newest finished test/re-test.

Why: If a retest has been created but the inspector has not yet finished it, the system ignores the open retest and evaluates the most recent finished test instead. This prevents a lot from being accidentally released just because a retest was initiated. The lot is only released when the retest is completed with a passing grade.

Scenario 4: multiple test types per lot

Situation: A lot undergoes different types of inspections at different stages (e.g., a dimensional inspection at receiving and a chemical analysis later). Both tests must pass before the lot can be used. A failure on any test blocks the lot.

Recommended Setting: Any test that matches.

Why: Since both tests are relevant and independent, the system should evaluate all of them. If the dimensional test passes but the chemical analysis fails, the lot remains blocked. Only when all tests for the lot have passing grades will the transaction be allowed.

Scenario 5: lot tested at multiple stages, only latest result matters

Situation: A lot is tested when it is received and tested again after an aging or curing process. The second test supersedes the first. If the lot passed receiving inspection but fails the aging test, it is blocked. If the lot failed receiving inspection but a subsequent retest passes, it is released.

Recommended Setting: Only the most recently modified test.

Why: The most recently modified test reflects the latest update to the lot’s quality status, regardless of which test was created first or which template was used. This is useful when multiple test types exist but the most current result is always the one that should govern the lot’s disposition.

Scenario 6: hold until inspection is complete

Situation: When a lot arrives, a test is created automatically. Until the inspector finishes the test, the lot is blocked from being shipped, picked, or consumed. The incomplete/in-progress grade is configured to block transactions.

Recommended Setting: Any test that matches.

Why: Open tests with an incomplete or in-progress grade are evaluated and their blocking rules apply. This ensures a lot cannot be used until the inspector finishes the test and assigns a passing grade. If you used a “finished only” option, the open test is ignored and the lot is not held.

Scenario 7: ignore open tests, block only on confirmed failures

Situation: Tests are created automatically but you do not want in-progress tests to interfere with warehouse operations. A lot is only blocked if a finished test has a failing grade. Work-in-progress tests does not prevent transactions.

Recommended Setting: Any finished test that matches.

Why: Open tests are ignored entirely. Only finished tests are evaluated for blocking. This prevents disruption from tests that have been created but not yet completed, while still enforcing blocks when a definitive failing result exists.

Scenario 8: regulatory environment with strict retest control

Situation: In a regulated environment, lots are retested periodically. The most recent finished retest is the authoritative result. Older retests and open retests do not influence blocking decisions.

Recommended Setting: Only the newest finished test/re-test.

Why: Only the finished test with the highest retest number is considered. This ensures periodic retesting produces a clear, single authoritative result. Open retests do not prematurely release or block the lot, and older finished retests do not override the current result.

Quick reference: choosing the right option

Distinguishing “Most Recently Modified” from “Newest Test/Re-test”

• Most recently modified: Determined by when the test record was last edited. This includes any change to the test (e.g., adding a picture for extra context). A test created a month ago but updated today is considered more recent than a test created yesterday but not touched since.
• Newest test/re-test: Determined by the test and retest number, which reflects the order in which tests were created. The test with the highest retest number is the one that was created most recently in the retest chain, regardless of when it was last modified.