How to Use Barcode Rules | Standard Time®

What is a Barcode Rule?

Standard Time® examines new barcode scan text and determines if it matches one or more of the rules. If a match is found, the Action is run.

Why is this valuable? This can eliminate the need for admins to create projects, tasks, inventory items, or other scannable items. Those items are created at the moment of scan instead of ahead of time. A work order can be scanned the instant it arrives on the shop floor — no one needs to open Standard Time® first to set up the project. The first scan creates it. Every subsequent scan of that barcode uses the auto-created record.

Diagram showing how the rules engine processes each barcode scan — from scan input through pattern matching to action execution or no-match alert

Overview of the four Barcode Rule property groups: Name and Description, Rules, Action, and Extras and Test

How to Open Barcode Rules

Barcode Rules are accessed through the Scan Barcodes page — the same page your employees use on the shop floor. Follow these steps:

Start at the Home page — Open Standard Time® and go to the main Home screen.
Click Scan Barcodes — This opens the scanner page used on the shop floor.
Find the Menu icon in the toolbar — Look for the ☰ icon in the toolbar at the top of the Scan Barcodes page.
Click the Menu icon and choose Barcode Rules — The Barcode Rules list opens, showing all existing rules.
Click the green "+" button — This creates a new, blank rule ready for configuration.

Creating a New Rule

When you click the green + button, a new rule is added to the list with default values. Select it to open the property panel on the right (or below, depending on your layout). Each property controls a specific aspect of when the rule fires and what it does.

Rules are tested in order — the first rule whose conditions match the incoming scan value wins. Give each rule a clear Name, configure its matching Conditions, and set the Action to run when it fires. Use the built-in Test value field to verify the rule before going live.

Tip: Configure the most specific rules first in the list. A broad rule placed above a narrow one will match scans the narrow rule was meant to catch. Use the Order property or drag-and-drop to arrange rules correctly.

Name and Description Properties

These four properties identify the rule and control whether it is active in the rules engine.

Name

A human-readable label for the rule. The name appears in the rules list so you can quickly identify what each rule does. Use a descriptive name that captures both the pattern and the action — for example, Work Orders — WO prefix or Employee Badges — 6-digit ID. The name has no effect on matching behavior.

Description

Additional free-text notes about the rule's purpose, history, or special conditions. Use this field to record context that the name alone cannot capture — for example, which work centers this rule applies to, when it was added, or what problem it solves. Like Name, the description is for reference only and does not affect matching.

Active

Controls whether the rule participates in scan processing. When set to Yes, the rule is evaluated each time a barcode is scanned. When set to No, the rule is skipped entirely — it remains in the list but never fires.

Use Active = No to temporarily disable a rule without deleting it. This is useful for seasonal rules, rules under development, or rules you want to keep as a reference but are not currently needed.

Order

Sets the sequence in which this rule is evaluated relative to other rules. Rules with lower order numbers are tested first. When the rules engine finds a match, it stops evaluating and fires the matched rule's action — so a rule with Order = 1 that matches a scan will fire before a rule with Order = 10 ever gets tested.

Assign lower order numbers to more specific rules and higher numbers to general or catch-all rules. If two rules have the same Order value, Standard Time® evaluates them in the sequence they appear in the list.

Rules Properties

Rules properties define the matching logic — which scan values trigger this rule and what prerequisites must be satisfied before the rule can fire.

Allow letters · Allow numbers · Allow special characters · Allow spaces · Allow 0 values

These five Yes/No properties act as character-type filters before the condition matching logic runs. If a scan value contains a character type that is set to No, the rule rejects the scan immediately without evaluating the conditions.

Property	Controls	Set to No when…
Allow letters	Whether scan text containing A–Z (upper or lower) can match this rule	The rule is for purely numeric codes such as employee ID numbers
Allow numbers	Whether scan text containing digits 0–9 can match this rule	The rule is for alphabetic-only codes such as process codes like WELD or ASSY
Allow special characters	Whether scan text containing hyphens, slashes, dots, or other non-alphanumeric characters can match	The rule should only match plain alphanumeric codes with no separators
Allow spaces	Whether scan text containing space characters can match	Scanned barcodes in your shop never contain spaces and you want to reject accidental space-padded reads
Allow 0 values	Whether a scan value of `0` (or a zero-padded string that resolves to zero) can match	A zero scan would represent an error read and should not trigger any action

Tip: Most shops leave all five set to Yes and rely on the Condition properties below for precise matching. Use these filters as an extra safety net for rules where you know the barcode format never uses certain character types.

Condition type 1 · Condition value 1 · Condition type 2 · Condition value 2 · Condition type 3 · Condition value 3

Up to three independent conditions can be combined on a single rule. The scan text must satisfy all active conditions for the rule to match. Each condition pair consists of a type (how to compare) and a value (what to compare against).

Three examples showing Starts With, Ends With, and Contains condition matching

Property	What it sets
Condition type 1	The comparison method for condition 1 — one of the 15 choices described in the reference table below
Condition value 1	The comparison value for condition 1. What this field means depends on the type chosen — see the reference table below
Condition type 2	The comparison method for a second, independent condition. Both condition 1 and condition 2 must be satisfied for the rule to match
Condition value 2	The comparison value for condition 2
Condition type 3	The comparison method for a third, independent condition. All three conditions must be satisfied if all are active
Condition value 3	The comparison value for condition 3

Condition Type Choices

Each Condition type dropdown offers the following choices. Reserved scan keywords (STOP, CLEAR, CANCEL, and similar) never match any condition regardless of the type selected.

Condition type	Rule fires when…	Condition value contains…	Case-sensitive?
None	This condition slot is inactive and is always skipped	Not used	—
Starts with	The scan text begins with the condition value	The required prefix. Example: `WO-` matches `WO-2024-001`	No
Does not start with	The scan text does not begin with the condition value. Useful as an exclusion guard alongside a broader rule	The prefix to reject. Example: `EMP-` passes any scan that is not an employee badge	No
Contains	The scan text includes the condition value anywhere within it	The required substring. Example: `-INV-` matches `WH-INV-PART-123`	No
Ends with	The scan text ends with the condition value	The required suffix. Example: `-STOP` matches `LINE-3-STOP`	No
Equal to	The scan text is an exact, character-for-character match of the condition value	The exact string the scan must equal. Example: `HOLD` matches only `HOLD`, not `hold` or `HOLD-1`	Yes — the only case-sensitive choice
Less than	The scan text, interpreted as a number, is less than the condition value	A numeric threshold. Example: `100` passes any scan whose numeric value is below 100	Numeric — both sides are parsed as decimals
Greater than	The scan text, interpreted as a number, is greater than the condition value	A numeric threshold. Example: `0` passes any scan whose numeric value is above zero	Numeric
Character Length Greater Or Equal	The scan text is at least as long as the condition value (inclusive)	An integer minimum length. Example: `6` passes scans of 6 or more characters; rejects shorter ones	Length only — content ignored
Character Length Less Than	The scan text is shorter than the condition value (exclusive upper bound)	An integer maximum length. Example: `13` passes scans of up to 12 characters; rejects 13 or more	Length only — content ignored
Value is not in choices	The scan text is not among the values listed in the Contains these choices property. Passes if the scan is absent from the list (or the choices list is empty)	Not used — this condition type reads from the Contains these choices property, not from the Condition value field	No
Regex expression	The scan text matches the regular expression pattern in the condition value. Matching strips the matched portion from the text, passing the remainder to the next condition	A regular expression pattern. Example: `^WO-\d+` matches work order codes. See the regex callout below for full details	No — case-insensitive, multiline
Contains multiple values	The scan text contains the condition value as a separator — i.e., splitting the scan on that separator produces more than one segment	The delimiter to look for. Example: `\|` passes any scan that contains a pipe character, such as `WO-001\|STEP-3`	No
JSON Structure	The scan text is valid JSON	Not used — the condition value is ignored; the check is purely whether the scan parses as JSON	—
Scan sequence	The current scan is the Nth scan in the session, where N equals the condition value	An integer scan position. Example: `1` passes only the very first scan of a new session; `3` passes only the third scan	Numeric position

Example using two conditions: To match work orders from a specific customer — codes that start with ACME- and also contain -WO- — set Condition type 1 = Starts with, value 1 = ACME-, Condition type 2 = Contains, value 2 = -WO-. A scan of ACME-WO-2024 would match; a scan of ACME-PO-2024 would not.

Leave Condition type 2 and 3 blank if only one condition is needed.

Using Regular Expressions as a Condition Type

A regular expression (regex) is a pattern language for describing the structure of text. Instead of specifying a fixed prefix like WO-, a regex describes the shape a valid value can take — characters, digits, separators, lengths, sequences — so it can match scan values that share a format but vary in content.

Set any Condition type to Regex expression and enter your pattern in the corresponding Condition value field. Standard Time® matches with case-insensitive, multiline mode, so you do not need separate patterns for upper and lower case.

When a regex condition matches, the matched portion is stripped from the scan text and the remainder is passed to the next condition. This makes chaining powerful: if condition 1 uses regex ^WO- to strip the prefix from WO-ACME-2024, condition 2 receives ACME-2024 — a clean way to progressively parse a structured barcode into its components.

Example patterns:

Pattern	Matches	Does not match
`^WO-\d+`	`WO-2024`, `WO-001`	`WO-ALPHA`, `MO-2024`
`^\d{6}$`	Any exactly 6-digit value: `100042`	`12345` (5 digits), `1234567` (7 digits)
`-INV-\d`	`WH-INV-4`, `RACK-INV-12`	`WH-INV-A` (letter after -INV-)
`^(EMP\|USR)-`	`EMP-0042`, `USR-SMITH`	`MGR-0042`, `EMP0042`

Build and test patterns before entering them in Standard Time® — paste your pattern and a sample scan into regex101.com or regexr.com , which highlight exactly which part of the text the pattern matched and explain each component in plain language.

Contains these choices

A comma-separated list of exact values the scan must match one of. When this property is populated, the rule fires only when the incoming scan text exactly matches one of the listed values.

Use this property when the valid scan values are a fixed, known set — for example, a rule that matches only the status codes HOLD,RELEASE,COMPLETE,SCRAP. This is more precise than a Contains condition because it checks the full value, not a substring.

Leave blank if you are using Condition type/value fields for matching instead.

Require User scan · Require Project scan · Require Subproject scan · Require Project Task scan

These four Yes/No properties add prerequisite scan requirements. When set to Yes, the corresponding item must have already been scanned in the current session before this rule can fire. If the prerequisite has not been scanned, the rule is skipped even when its conditions match.

Property	Prerequisite required before this rule fires	Typical use
Require User scan	A Username barcode must have been scanned in the current session	Rules that log time — ensures every time entry is attributed to a specific employee
Require Project scan	A Project (Work Order) barcode must have been scanned first	Task-level rules that should only fire in the context of an already-identified project
Require Subproject scan	A Subproject barcode must have been scanned first	Rules targeting tasks or operations under a specific sub-level of a project hierarchy
Require Project Task scan	A Project Task barcode must have been scanned first	Rules that apply only after a specific task is active — for example, a material scan that should log to the current task, not just the project

Tip: Enable Require User scan on any rule that logs time or creates records tied to an employee. Without it, a scan at an unattended station could fire the rule with no employee context, creating anonymous time entries.

Action Properties

Action properties define what Standard Time® does after the rule's conditions are satisfied. This is where the work happens — logging time, creating records, setting field values, running scripts, and notifying people.

Perform action

The primary action to execute when this rule fires. This is the most important Action property — it determines the fundamental behavior of the rule. Choosing a value here also affects which other Action properties become visible: selecting Run script reveals the Run script field; selecting Duplicate project reveals the Duplicate field.

The ten available choices are described below.

Choice	What it does	When to use
None	No primary record action is taken. The rule still fires — conditions are matched, Save value / Save to field pairs are applied, and Status message and Send email are triggered if configured.	Use when the rule's sole purpose is to write field values (via Save value/field), display a message, or send an email — with no need to create or modify a record.
Run script	Runs a saved script identified by the Run script property. The script output is used as the status message if no explicit Status message is set. Scripts run synchronously in the scan session, with access to the current scan value, active user, and active project.	Custom logic not covered by the built-in action types — field calculations, API calls, conditional branching, or any operation the scripting engine supports.
Toggle timer	Looks for a running timer for the current user that was started by a scan matching the same value (stored in the time log's UserText3 field). If a matching running timer is found and has been running for at least 30 seconds, it is stopped. If no running timer is found, any existing timers are stopped (unless Allow multiple timers is enabled) and a new timer is started.	The primary action for shop-floor time tracking. Employees scan the same barcode to start a work session and scan it again to stop — no separate stop scan is needed.
Create time log	Creates a completed (non-running) time log entry immediately, stamped with the current time as both start and end. The entry type is recorded as Barcode (type 3). User, project, task, category, location, device, and custom text fields are populated from the active session context and any configured defaults.	Recording a point-in-time event that does not need a start/stop timer — a quality inspection pass, a milestone confirmation, or a parts-received acknowledgement.
Create project	Searches for an existing project matching the scan value by name or code. If found, no action is taken (the existing project is used). If not found, a new project record is created using the scan value as both name and code. The client from the active session is applied if available. Scans that match a username are skipped.	Auto-creating work orders at the moment of first scan — no admin setup needed before the job hits the floor.
Create subproject	Creates a new subproject under the currently active project, using the scan value as the subproject name. If a subproject with that name already exists under the project, no duplicate is created. Requires a project to already be active in the session; returns an error if none is present. Scans that match a username are skipped.	Adding sub-phases, work centers, or sub-jobs to an in-progress work order via scan — for example, scanning `WELD` under an already-open project to create a welding phase on the fly.
Create project task	Creates a new task under the currently active project (inheriting subproject and client from the active session context). If a task with that name already exists under the project and subproject, no duplicate is created. Requires a project to already be active. Scans that match a username are skipped.	Adding operation steps to a work order as the job progresses — employees scan new operation codes and the tasks are created automatically without any pre-configuration.
Create inventory	Searches for an existing inventory item matching the scan value by Name, Code, or the Text3 field. If found, no action is taken. If not found, creates a new inventory item with Name, Code, and Text3 all set to the scan value. Location is inherited from the session context if available.	Auto-creating parts on their first scan when inventory records have not been set up in advance — useful for receiving new parts where the part number is not yet in the system.
Duplicate project	Checks whether a project with the scan value already exists. If yes, that project is used. If no, it looks up the template project specified in the Duplicate property and creates a full copy of it, giving the copy the scan value as its new name. Scans that match a username are skipped.	Shops where every work order follows the same structure — tasks, routing steps, billing type, work center — can scan a new job number and instantly get a fully pre-configured project without manual setup.
Required scan before start	Captures the current scan value and stores it as a pending property/value pair (using Save to field as the property name) that will be applied to the next time log entry when the timer actually starts. This pre-populates the field silently, eliminating the "Required Scan" prompt that would otherwise interrupt the employee mid-sequence. Scans matching a username are skipped; duplicate values for the same property are ignored.	Collecting a required value — a machine ID, work center, tool number — during the employee's normal scan sequence so that a popup is never shown. The employee simply scans the machine barcode before scanning the work order, and the machine code is recorded automatically on the resulting time entry.

Tip: Toggle timer is the action type most shops configure on their primary work-order rules. It handles both start and stop with a single scan, keeps the rule count low, and produces paired time entries that flow directly into job costing reports.

Run script

Selects the saved script to execute when Perform action is set to Run script. This property is only visible when that action type is selected. Scripts let you go beyond the built-in action types — query or update any database table, call an external API, send a formatted email, open a file, play a sound, or run any logic the built-in actions cannot express.

Creating Scripts — Tools > Scripts

Scripts are created and managed at Tools > Scripts in the Standard Time® menu. Click the green + button to create a new script, give it a name, choose its type, and write the code. Once saved, the script appears in the Run script dropdown on any barcode rule whose action type is Run script.

Scripts can be assigned to specific users via the Assign to users property, and organized into folders. Each script has a History field that logs when it last ran and what result it produced.

Script Types

Three languages are supported. Choose the type when creating the script:

Type	How it runs	Best for
SQL	The script is a SQL statement executed directly against the Standard Time® database. Context IDs and input values are substituted as plain-text tags before the query runs.	Inserting or updating records, looking up values, logging custom data to any table
JavaScript	The script is written in a JavaScript-like syntax that is automatically converted to C# and compiled before running. Short variable names (no prefix needed) are used for context and output.	Conditional logic, string manipulation, calling `alert()`, `SendEmail()`, `ExecuteSQL()`, or `UrlRequest()` with a familiar syntax
C# (C Sharp)	The script body is compiled as a C# method with full access to the Standard Time® object model. Context and output are accessed via `ScriptSet1.xxx` properties.	Complex logic, API calls, file I/O, anything requiring typed variables or .NET framework classes

Scan Context Available to Scripts

When a barcode rule fires a script, the following values are pre-loaded and accessible from any script type:

JavaScript / C# name	SQL tag	Contains
`UserData1` / `ScriptSet1.sScriptTempUserData1`	`TAG_USERDATA1`	The Save value field from this barcode rule
`UserData2` / `ScriptSet1.sScriptTempUserData2`	`TAG_USERDATA2`	The Save to field field from this barcode rule
`UserData4` / `ScriptSet1.sScriptTempUserData4`	`TAG_USERDATA4`	The raw scan text that triggered this rule
`UserId` / `ScriptSet1.sScriptTempUserId`	`TAG_USERID`	ID of the currently scanned user
`ProjectId` / `ScriptSet1.sScriptTempProjectId`	`TAG_PROJID`	ID of the active project / work order
`TaskId` / `ScriptSet1.sScriptTempTaskId`	`TAG_TASKID`	ID of the active project task
`TimelogId` / `ScriptSet1.sScriptTempTimelogId`	`TAG_TLOGID`	ID of the time log entry just created by this scan
`ClientId` / `ScriptSet1.sScriptTempClientId`	`TAG_CLNTID`	ID of the active client
`CategoryId` / `ScriptSet1.sScriptTempCategoryId`	`TAG_CATGID`	ID of the active category
`InventoryId` / `ScriptSet1.sScriptTempInventoryId`	`TAG_INVTID`	ID of the active inventory item

SQL scripts can also use FIELDVALUE(fieldname) to read a field value from the current record, and SQLDATEVALUE(fieldname) / SQLDATETIMEVALUE(fieldname) for date fields formatted for SQL.

Returning a Result

Set the script's output value to control what the scanner station displays after the rule fires:

JavaScript: ResultData = "your message";
C#: ScriptSet1.sScriptTempResultData = "your message";
SQL: Include RETURN_VALUE in your query to capture a result value.

This return value is shown as the Status message after the scan unless an explicit Status message is configured on the rule. If the script returns nothing, the display falls back to "Script: [script name]".

Built-in Script Functions

The following functions are available to JavaScript and C# scripts. In JavaScript, call them directly by name; in C#, prefix with ScriptSet1.:

Function	What it does
`alert(message)`	Displays a popup message on the scanning station after the script completes
`SendEmail(toEmail, fromEmail, subject, body, attachmentPath, attachmentBytes)`	Sends an email through the configured Standard Time® email account
`ExecuteSQL(sql, connectionString)`	Runs a SQL statement against the Standard Time® database (or any other database if a connection string is supplied). Returns the result value if `RETURN_VALUE` is present in the query.
`UrlRequest(url, port, objectName, verb)`	Makes an HTTP GET request and returns the response body. Use this to call a REST API, trigger a webhook, or push data to an external system at the moment of scan.
`ShellExecute(pathname)`	Opens a file using the system default application — for example, a PDF work instruction or a traveler document
`PlaySound(pathname)`	Plays an audio file — useful for distinct confirmation tones on different scan outcomes
`BuildSqlConnectString(server, database, auth, login, password)`	Builds a SQL Server connection string for use with `ExecuteSQL()` when targeting an external database
`NewGuid()`	Returns a new GUID string — useful when inserting records into a database that requires a unique identifier

Example (JavaScript): A rule that fires when a work order barcode is scanned and calls an external system to update job status:

var scanValue = UserData4;
var url = "https://erp.example.com/api/jobs/" + scanValue + "/start";
var response = UrlRequest(url, "443", "", "GET");
ResultData = "Job started: " + scanValue;

Duplicate

Identifies the item to duplicate when Perform action is set to Duplicate. This property is only visible when that action type is selected. The duplicate action creates a copy of an existing record using the scan value to identify or name the copy — useful for cloning a template project or task and assigning it a new identifier from the barcode.

Save value · Save to field · Save value 2 · Save to field 2 · Save value 3 · Save to field 3

These six properties (three value/field pairs) allow the rule to write specific values into fields of the matched or created record when the rule fires. Each pair is independent — you can use one, two, or all three.

Property	What it does
Save value	The value to write. Can be a literal string, a number, or a token that resolves at runtime (such as the current date or the scan text itself)
Save to field	The name of the record field where Save value is written. For example, `Status`, `BillingType`, or a custom field name
Save value 2	A second value to write, independent of the first pair
Save to field 2	The record field for the second value
Save value 3	A third value to write
Save to field 3	The record field for the third value

Example: A Work Order rule that auto-creates projects can use Save value / Save to field to set the new project's Status to Active and BillingType to TimeAndMaterials — so every auto-created project is immediately configured for time entry without manual follow-up.

Extracting Scan Text with Regex Tokens

The Save value field accepts special tokens that use regular expressions to pull a specific fragment out of the raw scan and write just that fragment to a record field — not the entire scan string.

[SCAN] — Inserts the complete, unmodified scan text. Use this to write the full barcode value to a custom field on the created record.
REGEX(pattern) — Applies pattern to the scan text, removes the portion that matched, and saves what remains. For example, REGEX(^WO-) applied to a scan of WO-1234 saves 1234 — the order number without its prefix — into whatever field you specify in Save to field.
REGEXALLRULES — Runs every regex-type condition defined on this rule in sequence. Each strips its matched portion from the text the previous condition left behind, and the final remaining text is what gets saved. This is useful when a barcode has multiple components to remove before reaching the segment you want — for example, stripping both a customer prefix and a year suffix to isolate the job number in the middle.

These tokens let you decompose structured barcodes and route each meaningful segment to the right database field without any scripting. A barcode encoded as WO-ACME-2024-042 could use REGEX(^WO-[A-Z]+-\d{4}-) in Save value 1 to extract 042 and save it to a JobNumber field — while Save value 2 uses a different regex to extract ACME and save it to the Customer field.

Try your extraction patterns at regex101.com or regexr.com — paste in the full scan value, apply the regex, and watch it highlight exactly what would be stripped, so you know what the remainder will be before configuring the rule.

Save scan values to fields

Maps multiple segments of the scan text to multiple record fields in a single operation. Where the Save value/field pairs write a fixed literal value, this property extracts parts of the scan string itself and routes each part to a different field.

This is useful when the barcode encodes several pieces of information — for example, a scan value of WO-ACME-2024 could be split so that ACME is saved to the Customer field and 2024 is saved to a Year field, all in one scan.

The value is a comma-separated mapping string; refer to the Standard Time® scripting documentation for the exact token syntax supported in your version.

Allow multiple timers for user

When set to Yes, a user can have more than one active timer running simultaneously after this rule fires. The default behavior in Standard Time® stops any running timer before starting a new one, ensuring employees are tracked on only one project at a time.

Enable this property on rules where parallel work is a valid scenario — for example, a supervisor monitoring multiple work centers simultaneously, or a setup tech who legitimately starts a new job while the previous job is still running on a machine. Use with care: multiple simultaneous timers can inflate reported hours if employees forget to stop a timer before moving to a new task.

Status message

Text displayed on the scanning station screen when this rule fires successfully. The message confirms to the employee that the scan was recognized and the action was taken. A well-worded status message reduces confusion at the scanner and eliminates the need for employees to guess whether their scan registered.

Examples: Timer started for WO-2024-0047, Inventory deducted — PN-8872-A, Work order created. Leave blank to use the default system confirmation or no message at all.

Send email

An email address (or template reference) to notify when this rule fires successfully. Use this property to alert a supervisor, manager, or downstream team member when a specific event is recorded by scan — for example, emailing a project manager when their work order is first scanned, or notifying shipping when a final inspection scan is recorded.

Leave blank if no email notification is needed for this rule.

Continue rules

Controls whether the rules engine keeps evaluating subsequent rules after this one fires. The default behavior is to stop at the first matching rule. When set to Yes, the engine fires this rule's action and then continues evaluating the remaining rules — allowing multiple rules to match and act on the same scan.

Use Continue rules = Yes when a single scan should trigger two independent actions — for example, logging a time entry (rule 1) and also sending a supervisor email (rule 2) on the same scan value. Both rules must match the scan value, and rule 1 must have Continue rules set to Yes.

Caution: Enabling Continue rules on a rule that auto-creates records can cause multiple records to be created from a single scan if more than one downstream rule also has auto-create active. Test carefully before enabling in production.

Continue barcode processing

Controls whether Standard Time® continues its built-in scan processing logic after this rule fires. The built-in logic handles standard behaviors such as project lookups, task context updates, user clock-in/clock-out sequences, and time entry creation.

When set to Yes, the rule fires its action and Standard Time® also runs its normal scan handling for the same value — as though the rule had not intercepted the scan at all. This allows a rule to augment built-in behavior (for example, saving a custom field value) without replacing it.

When set to No (the default), the rule completely handles the scan. Standard Time® does not run any additional built-in logic after the rule action completes. Use No for rules that fully replace default behavior with custom logic.

Extras Properties

Folder

Groups rules into named folders for organizational purposes. When a shop has many rules — separate rules for each work center, shift, customer, or scan type — folders help keep the rules list readable without affecting how rules are evaluated.

The Folder property is purely organizational: it has no effect on rule matching, priority, or action behavior. Two rules in different folders are evaluated in their configured Order sequence just like rules in the same folder.

Example folder names: Work Orders, Employees, Inventory, Quality Control, Archived.

Test Properties

The Test properties provide a built-in rule tester directly in the rule editor. Use them to verify that a rule matches the scan values you expect and rejects the ones it should not — before the rule is ever used in a live scan session.

Test value

Enter any scan text here to test whether this rule would match it. Type the value exactly as it would arrive from the scanner — including any prefix, suffix, separators, or special characters. As soon as you enter a value, Standard Time® evaluates it against all of the rule's conditions (character-type filters, condition types and values, choices list) and reports the result in Test results.

This field is for testing only — entering a value here does not create a time entry, modify any record, or trigger any action. It simply reports whether the rule would have fired.

Test results

Displays the outcome of the test entered in Test value. A passing result confirms that the rule's conditions matched the test text. A failing result — or a description of which condition rejected the value — helps you diagnose and correct the rule configuration without going through a live scan session.

This field is read-only. It updates automatically when Test value changes.

Use the test cycle — enter a known-good value, confirm a match; enter a known-bad value, confirm no match — for every rule before deploying it to a production scanner station.

Related Resources

← Back to Learning Center Try Standard Time® Free