App users only need to enter data once for a Session

Session answers are automatically included in sequential scans without the app-user needing to enter the same data again

This feature allows you to create Sessions where your app users answer your prompts (enter/select/scan) in admin-defined fields that are auto-submitted with every scan in the subsequent series of scans. The app user only needs to answer the prompts once for a related series of scans (a ‘session’). That data is auto-included in the scan record for every subsequent scan in that series.

The app user cannot scan until they have answered the session prompts. They can change the answers whenever they need to by tapping the ‘Sessions’ banner on the app’s Tap to Scan screen. The iOS app will force your app-users to check their saved answers every time the app goes to sleep or when they leave the app to multi-task. The Android app has this behavior but (for technical reasons) it waits 10 minutes after sleep or multi-tasking to force them to check their answers.

There are many uses for this feature. We outline just a few here:

Batch Scanning for Logistics
Multi-Session Attendance Tracking
Ticket Validation by Ticket Type

Setting up Sessions

You can enable app users to collect supplemental data after each scan using our Questions feature. A question is a prompt you add to your service so your authorised app users know what data you want them to collect. That same feature is used for sessions but instead of re-capturing the same data after each scan, these special prompts are answered only once by the app user for each related session. After creating your prompt(s), simply drag and drop them to the section “Ask once but submit with each scan.”
Shared Answers web view questions page

The app user will then see a Session Info banner on the Tap to Scan screen. To start the session they would tap that banner and be presented with your session prompt(s).  Once entered they will Save those answers. When creating a new session they would again tap the Session Info banner, Clear the current answers and optionally create new answers for the next session.

Auto-Next Scan
A very popular feature found on the Advanced Step when creating/editing your services is to choose ‘Auto-Next Scan’ which automatically submits every scan without the app user having to press any buttons. When combined with Auto Sync it makes data capture and collection very fast.

With Sessions you must use ‘Only when Valid’ for Auto-Next Scan.

Auto-next barcode scanning

Batch Scanning for Tracking Assets & Inventory and for Logistics

Common for logistics applications is the need to quickly scan a large number of barcodes. In many cases, more than one data point is required with each scan. An app-user prompt after each scan will enable variable data to be entered after each scan. However, if the data is fixed for a series of sequential scans it’s much more productive to use sessions.
However, if the data is fixed for a series of sequential scans it’s much more productive to use sessions. For example, the app user may need to capture the barcode values of all items in a location (building, shelf, etc) or list (delivery, picking, packing, etc.).

In the example below, the app user can scan or manually enter the location ID or list ID. Alternatively, a drop-down menu could be used for selecting locations, lists or other repeating data. If the location, list or any other important data is unknown in advance, then they can manually input the data with text or voice-to-text entry. We show 3 fields that will repeat with each scan in this session but you can have just one or any number that suits your needs.

start a session          enter shared answers in scans

Note: There are other ways to batch scan. Please look at this article about how to configure the codeREADr app as a smart batch barcode scanning app.

Multi-Session Attendance Tracking

If you need to track attendance for a large number of sessions, you have two ways you can accomplish that. The first way would be to create a Service for each session. However, that could be tedious if, for example, you have 50 sessions in one day. While that can be done in an automated way when using our API, for the non-developer there’s a simpler way.
You can use our Copy & Paste option for importing a list of sessions.

copy paste session list

The result would look like this:

session list answers

And once saved,  the list can be edited.

edit answer options

And here’s what the app user would see:

Barcode Scanning for Sessions     Choosing a Session     Saving Session

Once a session is selected, every subsequent scan includes that session name or ID in the scan record. In this way, your app users can quickly scan the attendee’s IDs or badges, ideally using our Auto Next Scan and Auto Sync features.

Ticket Validation by Ticket Type

For the 80+ ticketing companies that have integrated with our service, we’ve received requests for the ability to validate specific ticket types stored in a single database on-the-fly. The difference between what they can currently do with codeREADr and their request is ‘on-the-fly’.
For our validation service type, if you want to validate a VIP pass you would need a VIP service associated to a VIP database.  You would need another service and database for early bird attendees, voucher holders, parking passes, etc.

Now with sessions, instead of creating a different service and database for each type of ticket, you can create sessions to accomplish that. Currently, this only applies to online services deploying Direct Scan to URL (DSU) or Postback URL services.  With those service types, the validation occurs on their servers. Now that we can submit both the ticket ID and the ticket type to their server, they will know which type to validate against.

The session options you make available for app users to choose from could be one or a combination of these examples:

  • VIP Ticket
  •  Earlybird Ticket
  • General Admission
  • Voucher
  • Parking
  • Etc.

The app user would select the option(s) to save for the session. Those options would be posted with the Ticket ID for every subsequent scan until they need to scan for another ticket type. They would then edit or clear the previously selected options and then choose another option(s).

Since this won’t work offline, we are building another feature for Q3/2017 called ‘Custom Validation’ where clients will be able to create their own scripts to run offline. Those scripts could validate the Ticket ID and selected session option(s) offline against a single database.

in Data Collection