Home
TR

Lists and triggers

SQLite-based list management and triggers that switch the active list when a scanned value matches.

QCR Scanner collects the values you scan into as many separate lists as you need, rather than one undifferentiated pile. Each list lives in a local SQLite database on your device; you can create, rename, delete, and switch between lists. One list is always active, and every value you scan goes into it. This page covers how to manage lists, what the active list means, and the list trigger rules that switch the active list automatically when a scanned value matches a pattern.

Why lists are useful

Keeping a separate list per job keeps your data organized from the start. For example, while collecting serial numbers from several warehouses through the day you might open one list per warehouse, or one list per session at an event. Lists are independent: validation, separators, and entries in one list do not affect another. You can see which list is active from the top bar and switch between lists with a single tap.

Lists work together with the surrounding features:

Managing lists

List management comes down to four core operations, all running instantly against the local SQLite database.

Operation What it does
Create Opens a new, empty list and gives it a name
Rename Changes an existing list’s name; its entries are kept
Delete Permanently removes a list and every entry in it
Set active Makes the selected list active; subsequent scans land here

Note: Deleting a list cannot be undone — every entry in it goes with the list. Export the list to CSV first if you need to keep the data.

What the active list means

Only one list is active at a time. Every new value produced by scanning, voice input, or Smart Extract is added to the active list after it passes validation. Changing the active list changes where new values go; it does not move existing entries. Your active-list choice is stored on the device, so you pick up where you left off after closing and reopening the app.

You can change the active list in two ways: manually from list management, or automatically with the trigger rules described below.

List trigger rules

List triggers are rules that switch the active list automatically based on the value you just scanned. A trigger rule defines a pattern (regex) and a target list name. When a scanned value matches the pattern, QCR switches the active list to that target — without you changing anything by hand.

This is powerful in workflows where the values you scan themselves declare which list they belong to. For example, scanning a section code on a box label can make the app switch to the right section list; then, as you scan the individual items in the box, they all land in the correct list.

When the target list does not exist: create confirmation

If a trigger targets a list that does not exist yet, QCR does not silently send you somewhere else. Instead it asks whether you want to create the target list. If you confirm, the list is created and made active; if you decline, the active list stays unchanged. This stops a pattern with a typo from accidentally spawning a pile of empty lists.

consumeMatch: should the triggering value be recorded?

Every trigger rule has an option called consumeMatch that controls what happens to the value that fired it:

  • consumeMatch off — the trigger fires, the active list changes, and the triggering value is also added as a normal entry to the new active list.
  • consumeMatch on — the trigger “consumes” the value: the active list changes, but the triggering value itself does not enter the list. This is handy when the value is only a switch (for example a section-header barcode); it changes the list without mixing the header into your data.

Tip: Turn consumeMatch on for workflows where you scan a label to open a list but do not want that label in the data itself. Leave it off for values that both switch the list and belong as an entry.

Resolving the list name from a template

The target list name does not have to be a fixed string. You can use a template to insert parts of the triggering value into the list name, so a single trigger rule can route to different lists depending on the scanned value. For example, for values that contain a date or section code, you can drop that code straight into the list name and open a separate list per code. If the resolved name matches an existing list, that list becomes active; if not, the create confirmation above kicks in.

Relationship with CSV and webhook

Lists determine where data is collected, and export works per list. You can export your active list to CSV or send entries to an endpoint through a webhook. The listName field in the webhook body carries which list an entry came from, so you can keep lists apart on the server side. With auto-sync on, each new entry is sent one by one; “Send all” sends a whole list’s entries in a batch.

Here is an example of how the list name appears in a webhook body:

{
  "action": "add",
  "listName": "Warehouse-A",
  "item": {
    "value": "SN-00421",
    "isQR": false,
    "source": "ocr",
    "createdAt": "2026-06-21T10:15:00Z",
    "isSeparator": false
  },
  "timestamp": "2026-06-21T10:15:00Z"
}

Together, lists and triggers let you set up a hands-free flow where the values you scan route your data into the right buckets. Made by ReviseTouch.

Next steps

  • Validation rules — set which patterns are accepted before a value enters a list
  • Separators — create date- or header-based collapsible sections inside a list
  • CSV export — export a list to a shareable CSV file
  • Webhook sync — send list entries to an endpoint automatically or in a batch