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:
- Scanned values first pass all enabled validation rules, then go into the active list.
- Separator rules create collapsible sections inside a list.
- Each list can be exported to CSV or synced through a webhook on its own.
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:
consumeMatchoff — the trigger fires, the active list changes, and the triggering value is also added as a normal entry to the new active list.consumeMatchon — 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
consumeMatchon 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