Question 3
Improve Naming of Flag
Advanced solution
| Txn ID | Vendor | Amount | Flag name | Created |
|---|---|---|---|---|
| TX-10021 | Miller LLC | $5,000 | Duplicate Tax#/Name|Delete one | 2025-08-02 |
| TX-10022 | Orbit Design | $1,250 | Service Qty>1|Submit Manually | 2025-08-03 |
| TX-10023 | Zeno Labs | $850 | Buyer & Seller Name Match|Check | 2025-08-03 |
| TX-10024 | Apex Systems | $3,400 | PO Keyword Flag|Validate VAT | 2025-08-04 |
| TX-10025 | Nimble Co | $2,200 | Service Qty>1|Submit Manually | 2025-08-05 |
| TX-10026 | Vector Ltd | $7,900 | Duplicate Tax#/Name|Delete one | 2025-08-06 |
Problem statement
Flags are automatic triggers for transactions processed by our system to indicate problems that need to be dealt with.
The team who reviews Seller Invoices & sends Buyer Invoices clears these for all transactions.
Current pain points
Team doesn't always know what they are supposed to do without taking a lot of time and reading all of the detail.
Unclear flag names lead to slower resolution times and potential errors in judgment.
New team members struggle to understand what each flag means and what action is required.
Inconsistent naming patterns make it harder to predict and categorize similar issues.
Requirements
- Clarity: Flag names must immediately convey what the issue is and what action is needed
- Consistency: Follow standardized naming patterns across all flag types
- Actionability: Include clear indication of required resolution steps
- Scannable: Enable quick triage and prioritization by the review team
- Context: Provide sufficient detail to understand the business impact
- Reduce cognitive load: Team should understand the issue within 3-5 seconds
- Minimize training time: New team members should grasp flag meanings intuitively
- Support workflow efficiency: Enable batch processing of similar flag types
- Prevent errors: Clear naming reduces misinterpretation and wrong actions
- Character limits: Keep names under 32 characters for UI display (In the example that Candex provided, the max length is 32 characters so we know that at least 32 characters are available)
- Backwards compatibility: Maintain system references while updating display names
- Internationalization: Consider future translation needs
- Searchability: Include keywords that team members would naturally search for
Information hierarchy
Use the compact Issue|Action format to maximize clarity within 32 characters.
Optimized naming structure (≤32 characters)
Concise problem identification: "Duplicate Tax#/Name" (19), "Service Qty>1" (13), "Buyer & Seller Name Match" (25), "PO Keyword Flag" (15). Front-load the condition users scan for.
Short, explicit actions: "Delete one" (9), "Submit Manually" (15), "Check" (5), "Validate VAT" (12). Joined with a pipe (|) for compact Issue|Action labels.
Simplified structure maximizes clarity within UI character constraints while maintaining consistency and actionability.
Solution
Below are four flag naming proposals that transform the existing unclear names into actionable, scannable labels.
Proposal A — Entity Consolidation Pattern
Transforms unclear entity issues into clear consolidation actions
| Current Name | Improved Name | Key Improvement |
|---|---|---|
| Duplicate in same company | Duplicate Tax#/Name|Delete one | Issue|Action format. Policy match: same Tax#/Name not allowed. Do: move payment to original entity and delete the duplicate. |
Pattern Analysis
Clear violation phrased to mirror the policy: duplicate Tax#/Name within a company. Action is explicit: keep original, delete duplicate.
Proposal B — Service Validation Pattern
Clarifies service quantity validation requirements
| Current Name | Improved Name | Key Improvement |
|---|---|---|
| Multi QTY Service | Service Qty>1|Submit Manually | Issue|Action format with explicit condition and action. Clear cue to submit invoice manually. |
Pattern Analysis
Compact label uses Issue|Action: "Service Qty>1|Submit Manually". Instantly communicates the condition and next step.
Proposal C — Name Verification Pattern
Makes name matching validation requirements explicit
| Current Name | Improved Name | Key Improvement |
|---|---|---|
| B Name = S Name or S Entity Name | Buyer & Seller Name Match|Check | Issue|Action format. Names match is the condition; "Check" is the required verification step. |
Pattern Analysis
Follows Issue|Action: "Buyer & Seller Name Match|Check". Plain-English condition and the expected verification step.
Proposal D — Compliance Validation Pattern
Makes compliance requirements and VAT validation explicit
| Current Name | Improved Name | Key Improvement |
|---|---|---|
| PO has Trigger Words | PO Keyword Flag|Validate VAT | Issue|Action format; keeps familiar concept (PO keywords) and makes the compliance step explicit: validate VAT. |
Pattern Analysis
Uses Issue|Action: "PO Keyword Flag|Validate VAT". Familiar trigger concept with a concise, explicit compliance action.
Recommendation
Choose the best approach and justify why.