Ticket Scout: Pattern Detection with Regex

Ticket Scout's default patterns work great for standard PSA ticket formats. Every organization is different. You might use custom formats like REQ-12345 for service requests, or see false positives from invoice numbers that match ticket patterns.

Understanding pattern detection helps you add custom formats, exclude false positives, and fine-tune highlighting to match your workflow.

Prerequisites

Before you start, make sure you have:

Ticket Scout installed and connected to your PSA
Access to settings (Extension icon → Configure Extension)
Examples of your ticket ID formats
Examples of false positives you want to exclude (optional)

Configuration Time

Basic configuration: 5-10 minutes. Advanced exclusions: 15-20 minutes.

Understanding Default Patterns

Ticket Scout comes with patterns for common environments:

Pattern	Example	Where It Works
ConnectWise whitespace-isolated	`123456`, `Service Ticket #123456`	`.connectwise.com`, `.myconnectwise.net`
Huntress hash prefix	`#123456`	`*.huntress.io`
Teams various formats	`#123456`, `Ticket 12345`	`teams.microsoft.com`
Outlook ticket word	`ticket #123456`, `Ticket:234567`	`outlook.office.com`

Domain-specific patterns mean different formats work on different sites, reducing false positives where they don't belong.

Quick Start: Component Builder

Most users never need regex. The Component Builder handles common scenarios through a form.

Creating Your First Pattern

Let's add a pattern for REQ-12345 format service requests:

Click extension icon → Configure Extension
Navigate to Detection Patterns tab
Click + Add Pattern
Fill in the form:
- Pattern Name: Service Request Format
- Pattern Type: Include (Match and highlight)
- Configuration Mode: Select Component Builder (Recommended) from dropdown
- Prefix: REQ-
- Prefix Required: ✓ (checked)
- Min Length: 5
- Max Length: 5
- Notes: Internal service request format
Scroll to Pattern Validation section
Enter test strings in Example Matches:
```
REQ-12345
req-67890
```
Enter test strings in Example Non-Matches:
```
REQ-12
REQQ-12345
```
Click Test Pattern to verify
Click Save Pattern

Result: REQ-12345 and req-67890 will now be highlighted (case-insensitive).

Pattern Validation

Always test patterns before saving. The validation section shows exactly what will match.

Understanding Regex Basics

The Component Builder creates regex behind the scenes. Understanding these patterns helps troubleshoot issues and build advanced rules.

Essential Regex Symbols

Symbol	Meaning	Example	Matches
`\d`	Any digit 0-9	`\d\d\d`	`123`, `456`
`\b`	Word boundary	`\b\d+\b`	`123` not `abc123xyz`
`( )`	Capture group (what gets highlighted)	`#(\d+)`	`#12345` highlights `12345`
`[Tt]`	Character class	`[Tt]icket`	`Ticket` or `ticket`
`*`	Zero or more	`\s*`	Any whitespace
`?`	Zero or one (optional)	`#?`	Optional `#`
`{5,9}`	Range (5 to 9 times)	`\d{5,9}`	5 to 9 digits
`\|`	OR operator	`(#\|T)`	`#` or `T`

Capture groups matter: Only text inside ( ) gets highlighted.

Reading a Real Pattern

Default ConnectWise pattern:

(?:(?<=Service Ticket #)|(?<!of )(?<!\S))(\d{5,9})(?!\S)

What it does:

Matches 5-9 digit numbers after "Service Ticket #" OR
Matches standalone 5-9 digit numbers (not preceded by "of " or other text)
Ensures numbers aren't attached to text after them
Only highlights the digits (in the capture group)

Matches:

✅ Service Ticket #123456
✅ The ticket is 98765
❌ batch of 12345 (comes after "of ")
❌ ref12345 (attached to text)

Practical Use Cases

Excluding False Positives: Dates

Problem: Dates like 01/15/2024 or 2024-01-15 are highlighted.

Solution (Raw Regex):

Detection Patterns → + Add Pattern
Configuration Mode: Select Raw Regular Expression from dropdown
Fill in:
- Pattern Name: Exclude Dates
- Pattern Type: Exclude
- Regular Expression Pattern: \b\d{1,2}[/-]\d{1,2}[/-]\d{2,4}\b|\b\d{4}[/-]\d{1,2}[/-]\d{1,2}\b
- Regex Flags: g
- Notes: Prevents MM/DD/YYYY and YYYY-MM-DD formats
Test in Pattern Validation with sample dates
Save

How it works:

\d{1,2}[/-]\d{1,2}[/-]\d{2,4} - Matches MM/DD/YYYY
| - OR
\d{4}[/-]\d{1,2}[/-]\d{1,2} - Matches YYYY-MM-DD

Exclusions Win

Exclusion patterns ALWAYS process first and take priority over includes.

Excluding False Positives: Phone Numbers

Pattern: \(?\d{3}\)?[\s.-]?\d{3}[\s.-]?\d{4}\b

Matches: (555) 123-4567, 555-123-4567, 555.123.4567

Excluding Other Ticketing Systems

JIRA tickets (PROJ-456):

Pattern: \b[A-Z]+-\d+\b
Type: Exclude

ServiceNow incidents (INC0012345):

Use Component Builder
Prefix: INC
Min Length: 7, Max Length: 10
Type: Exclude

Domain-Specific Patterns

Problem: Email shows Ticket 12345 but PSA uses #12345.

Solution: Use Domain Restrictions field when creating patterns.

Email pattern:

Prefix: Ticket, Separator: space, Digits: 4-9
Domain Restrictions: outlook.office.com (one per line)

PSA pattern:

Prefix: #, Digits: 4-9
Domain Restrictions: *.connectwise.com

Result: Different formats work on different sites, reducing false positives.

Domain Wildcards

*.domain.com matches all subdomains like app.domain.com, portal.domain.com

Advanced: Lookaheads and Lookbehinds

When Component Builder isn't enough, use raw regex with zero-width assertions.

Positive Lookbehind (?<=...) - Must come after this

Example: (?<=Ticket #)\d+
Matches 12345 in Ticket #12345 (not standalone 12345)

Negative Lookbehind (?<!...) - Must NOT come after this

Example: (?<!of )\d{5}
Skips 12345 in batch of 12345

Negative Lookahead (?!...) - Must NOT be followed by this

Example: \d{5}(?!-\d{4})
Skips 12345 in ZIP code 12345-6789

When to use:

Complex documents with many numbers
Need context-aware matching (after X, not before Y)
Component Builder can't achieve needed specificity

Testing and Verification

Using Pattern Validation

Built-in testing prevents broken patterns:

Settings → Detection Patterns → Edit pattern
Scroll to Pattern Validation
Add comprehensive examples in Example Matches and Example Non-Matches
Click Test Pattern
Review results (green = matched, no color = excluded/no match)

Test comprehensively:

Valid tickets: Ticket 12345, #98765, Service Ticket #67890
False positives: 01/15/2024, (555) 123-4567, batch of 12345

Testing on Real Pages

After saving patterns:

Navigate to email, PSA, or documentation
Look for highlighted tickets
Identify false positives or missed tickets
Return to settings to refine

Test checklist:

Email client
PSA dashboard
Internal wiki/docs
Chat platform

Export and Backup

Once patterns are configured:

Detection Patterns → Export Patterns
Save JSON file
Share with teammates for consistent configuration

Import patterns:

Detection Patterns → Import Patterns
Select JSON file
Review and save

Troubleshooting

Too Many False Positives

Problem: Dates, phone numbers, order IDs all highlighted.

Solutions:

Tighten digit ranges (change \d{3,10} to \d{5,9})
Add required prefix in Component Builder
Create exclusion patterns for dates, phones, timestamps
Enable word boundaries (\b in regex)

Valid Tickets Not Highlighted

Problem: Known ticket IDs aren't detected.

Check:

Digit range too narrow - Pattern requires 5-6 digits but ticket is 7 digits
Case sensitivity - Use Component Builder's case-insensitive toggle or [Tt]icket in regex
Domain exclusions - Check Exclusions tab for overly broad rules
Missing separators - Pattern expects space but text has colon

Debug: Copy ticket ID, paste in Pattern Validation, see which patterns match

Pattern Matches Too Much Context

Problem: Entire sentences highlighted instead of just the number.

Cause: Missing or incorrect capture group.

Fix:

Bad: Ticket[\s:#-]*?\d{4,9} - Highlights "Ticket 12345"
Good: Ticket[\s:#-]*?(\d{4,9}) - Highlights only "12345"

Put ONLY the ticket number in parentheses ( ).

Exclusion Not Working

Check:

Pattern Type is set to Exclude (not Include)
Pattern is enabled (toggle on)
Pattern actually matches the false positive (test in Pattern Validation)
Separator characters match (pattern expects / but text has -)

Pattern Processing Order

Ticket Scout processes patterns in a specific order:

Exclusions first - Type: Exclude, always win
Inclusions second - Type: Include, processed in creation order

Exclusions are created above inclusions in the pattern list. You cannot manually reorder patterns (they process in the order they were created).

Why this matters: If a number matches both an exclusion and an inclusion, it won't be highlighted.

Quick Reference

Common Ticket Formats

Format	Component Builder	Raw Regex
`#12345`	Prefix: `#`, Min: 4, Max: 9	`#(\d{4,9})`
`Ticket 12345`	Prefix: `Ticket`, Separator: space, Min: 4, Max: 9	`[Tt]icket[\s:#-]*?(\d{4,9})`
`REQ-12345`	Prefix: `REQ-`, Min: 5, Max: 5	`REQ-(\d{5})`

Common Exclusion Patterns

False Positive	Raw Regex
Dates (MM/DD/YYYY)	`\b\d{1,2}[/-]\d{1,2}[/-]\d{2,4}\b`
Dates (YYYY-MM-DD)	`\b\d{4}[/-]\d{1,2}[/-]\d{1,2}\b`
Phone (US)	`\(?\d{3}\)?[\s.-]?\d{3}[\s.-]?\d{4}\b`
Timestamps (HH:MM:SS)	`\b\d{1,2}:\d{2}:\d{2}\b`
ZIP codes	`\b\d{5}(?:-\d{4})?\b`
JIRA tickets	`\b[A-Z]+-\d+\b`
ServiceNow	`\b(INC\|REQ\|CHG)\d{7,10}\b`
IP addresses	`\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b`

Regex Symbols Quick Reference

Symbol	What It Does	Example
`\d`	Any digit	`\d{5}` = 5 digits
`\b`	Word boundary	Prevents `abc123` matching
`( )`	Capture group	What gets highlighted
`[Tt]`	Character class	`T` or `t`
`*`	Zero or more	`\s*` = any whitespace
`?`	Optional	`#?` = optional hash
`{5,9}`	Range	5 to 9 times
`\|`	OR	`#\|T` = `#` or `T`
`(?<=...)`	Positive lookbehind	Must come after
`(?<!...)`	Negative lookbehind	Must NOT come after
`(?!...)`	Negative lookahead	Must NOT follow

Escaping: Use \. for literal period, \( for literal parenthesis, \\ for backslash.

Best Practices

✅ Start with Component Builder - Use for 90% of patterns

✅ Use exclusions liberally - Easier than perfecting includes

✅ Test before saving - Pattern Validation catches issues early

✅ Document patterns - Use Notes field to explain purpose

✅ Export for backup - Save configuration as JSON

✅ Domain restrictions reduce noise - Limit patterns to relevant sites

✅ Word boundaries prevent partial matches - \b is critical

❌ Don't make patterns too broad - \d{3,10} matches everything

❌ Don't skip testing - Always validate before deploying

Key Takeaways

✅ Component Builder handles most scenarios without regex knowledge

✅ Exclusion patterns prevent false positives and always process first

✅ Pattern Validation tests patterns before deploying to real pages

✅ Word boundaries (\b) and capture groups (( )) control what's highlighted

✅ Lookaheads/lookbehinds solve context problems when Component Builder isn't enough

✅ Domain restrictions improve accuracy by limiting patterns to specific sites

Additional Resources

Regex101.com - Interactive regex tester (use JavaScript flavor)
RegexLearn.com - Interactive regex tutorial
MDN: Regular Expressions - JavaScript regex reference
Ticket Scout GitHub - Extension repository

With these patterns configured, Ticket Scout intelligently highlights your PSA tickets while ignoring the noise.

Prerequisites​

Understanding Default Patterns​

Quick Start: Component Builder​

Creating Your First Pattern​

Understanding Regex Basics​

Essential Regex Symbols​

Reading a Real Pattern​

Practical Use Cases​

Excluding False Positives: Dates​

Excluding False Positives: Phone Numbers​

Excluding Other Ticketing Systems​

Domain-Specific Patterns​

Advanced: Lookaheads and Lookbehinds​

Testing and Verification​

Using Pattern Validation​

Testing on Real Pages​

Export and Backup​

Troubleshooting​

Too Many False Positives​

Valid Tickets Not Highlighted​

Pattern Matches Too Much Context​

Exclusion Not Working​

Pattern Processing Order​

Quick Reference​

Common Ticket Formats​

Common Exclusion Patterns​

Regex Symbols Quick Reference​

Best Practices​

Key Takeaways​

Additional Resources​