Incident History Tab
The Incident History tab is your complete repair and maintenance log for the device. Every time something goes wrong - a cracked screen, a battery issue, software problems, or any other incident - it's recorded here.
Think of this tab as the device's medical history. Just like a doctor reviews your health records to understand patterns and past treatments, you'll use incident history to understand what's happened to a device over time.
To view incident history, you need the View Incidents permission assigned to your administrator role.
Understanding the Incident History Table
The incident history table shows all incidents ever reported for this device - both current (still being worked on) and completed (finished repairs). This is different from the "Current Incidents" section on the Device Information tab, which only shows open issues.
The table is sorted with the most recent incidents at the top, so you immediately see what's happened lately.
What the Table Shows
| Column | What It Shows |
|---|---|
| Date | When the incident was first reported or created |
| Model | The device model (confirms you're looking at the right device) |
| Finish Date | When the incident was marked as completed (empty if still open) |
| Incident Status | Current state of the repair or issue |
| Incident Type | Category tags describing what's wrong |
| Action | Button to view complete incident details |
Incident Statuses Explained
The Incident Status column shows where each repair or issue stands in your workflow. Understanding these statuses helps you quickly assess what's happening with the device.
Common incident statuses include:
Completed
The incident has been resolved and closed. The repair is finished, the problem is fixed, or the issue was addressed. This is the final state for most incidents.
Example uses:
- Screen replaced and tested
- Software issue resolved
- Battery swap completed
- Loaner returned after original device repaired
In Progress
Someone is actively working on fixing the problem. Parts might be ordered, repairs underway, or troubleshooting happening.
Example uses:
- Device is on the repair bench being worked on
- Waiting for diagnostic results
- Actively replacing components
Investigating
The incident has been reported, but the team is still figuring out what's wrong or how to fix it. This is common for unusual problems or when you need to diagnose before taking action.
Example uses:
- Intermittent issues that are hard to reproduce
- Strange behavior that requires testing
- Determining if it's hardware or software
Waiting Student to Pickup
The repair is done and the device is ready for the student to collect. This status helps you track which devices are sitting in your office waiting to go home.
Example uses:
- Repair completed, device ready in your office
- Loaner ready to be swapped for broken device
- Device cleaned and prepared for student pickup
Sent for Repair
The device has been shipped off-site for depot repair, manufacturer warranty service, or specialized repair that can't be done locally.
Example uses:
- Sent to manufacturer for warranty repair
- Shipped to district tech services
- Delivered to third-party repair depot
Other
A catch-all status for situations that don't fit standard categories. Your team might use this for unique situations specific to your workflow.
Incident statuses are configured by your system administrator in Settings > System Settings > Incidents Tab. Your district can customize these statuses to match your specific repair workflow.
Incident Types (Flags)
The Incident Type column shows category tags that describe what's wrong with the device. Think of these as labels that help you quickly identify the nature of the problem.
Common incident types include:
Hardware Issues:
- Physical Damage: Drops, cracks, dents, or impact damage
- Screen: Display problems, cracks, dead pixels, backlight issues
- Battery: Won't hold charge, battery life problems, charging issues
- Touchpad: Trackpad not working, erratic cursor, click problems
- HD (Hard Drive): Storage problems, slow performance, disk errors
- Wireless: WiFi or Bluetooth connectivity problems
Software & Maintenance:
- Reimage: Device needs operating system reinstalled or reset
- Random Check: Routine inspection or verification, not a specific problem
Other Categories:
- Case: Protective case issues or case-related problems
- Loaner Given: Indicates a loaner device was provided during this incident
Multiple types can be tagged on a single incident. For example, a device might have both "Physical Damage" and "Screen" tags if it was dropped and the screen cracked.
If you see the same incident type appearing repeatedly (like "Battery" showing up every 3 months), it might indicate a systemic problem with that device model or usage pattern. This information is valuable for warranty claims and future purchasing decisions.
Reading the Dates
Incident dates tell you the timeline of each problem and repair.
Date (Created)
This is when the incident was first reported or created in the system. It represents:
- When someone noticed the problem
- When a student brought the device in
- When you discovered the issue during inspection
Important: This might not be when the damage actually occurred - just when it was reported. A student might have cracked a screen days before bringing it to you.
Finish Date
This shows when the incident was marked as completed. The time between the Date and Finish Date tells you how long the repair took.
Empty Finish Date means:
- The incident is still open
- Work hasn't been completed yet
- The device might still be waiting for repair
Typical repair timelines:
Quick fix (same day):
Date: 03/15/2025
Finish Date: 03/15/2025
Normal repair (few days):
Date: 03/15/2025
Finish Date: 03/20/2025
Sent out for repair (weeks):
Date: 03/15/2025
Finish Date: 04/10/2025
Still open:
Date: 03/15/2025
Finish Date: [empty]
Viewing Complete Incident Details
Each incident row has an Action button that opens the full incident record. This is where you'll find all the detailed information about what happened.
Click the View button to see:
- Complete description: Full notes about the problem
- Photos: Pictures of damage or issues
- Repair notes: What was done to fix it
- Parts used: Components replaced during repair
- Cost information: Repair expenses, parts costs
- Interview notes: What the student said happened
- Assessment details: Your initial evaluation
- Incident log: Timeline of updates and actions taken
- Who worked on it: Which staff members handled the repair
This detailed view is essential for:
- Understanding exactly what was wrong
- Seeing how the repair was performed
- Reviewing costs for billing or insurance
- Following up on recurring problems
Common Use Cases
Scenario 1: Identifying Recurring Problems
A student brings in their device for the third time this year:
- Open the device profile
- Click the Incident History tab
- Review all past incidents
- Look for patterns:
- Same problem repeated? (3 screen repairs = might be misuse)
- Different problems each time? (might be a lemon device)
- Long time between incidents? (normal wear and tear)
This helps you decide if this is a pattern of carelessness, a defective device, or just bad luck.
Scenario 2: Warranty Claims
You need to file a warranty claim for a device that keeps having battery problems:
- Open Incident History tab
- Find all incidents with "Battery" type
- Click View on each to see detailed notes and dates
- Document the pattern: "Battery replaced 3 times in 6 months"
- Use this evidence to support the warranty claim
The incident history provides the documentation you need to prove manufacturing defects.
Scenario 3: Billing for Damage
A parent questions a damage charge for their child's device:
- Go to Incident History
- Find the specific incident
- Click View to open the detailed incident record
- Show them:
- Photos of the damage
- Assessment notes describing the problem
- Interview notes if applicable
- Date when damage was reported
This documentation helps resolve disputes by showing exactly what happened.
Scenario 4: Device Reliability Assessment
You're deciding whether to keep using a specific device model:
- Look at incident history for several devices of that model
- Compare the number and types of incidents
- Notice patterns:
- Model A: Mostly software issues, easy fixes
- Model B: Frequent screen and battery problems, expensive repairs
This analysis informs future purchasing decisions - maybe Model A is more reliable and cost-effective long-term.
Scenario 5: Troubleshooting Current Problems
A device has a weird issue and you're not sure what's causing it:
- Check Incident History to see if this has happened before
- Review previous repair notes to see how it was fixed
- See if the same components keep failing
- Use past solutions as a starting point for current troubleshooting
Don't reinvent the wheel - if someone already figured out how to fix this exact issue, use their notes!
Empty Incident History
If a device has never had a problem reported, the incident history table will be empty with a message like:
No incidents found
This is fantastic! It means:
- The device has been trouble-free
- No repairs have been needed
- It's been a reliable device
However, keep in mind:
- Some devices might have had problems that weren't formally documented
- If the device is brand new, it simply hasn't had time to develop issues yet
- Incidents might exist but you don't have permission to see them (though this is rare)
Understanding Incident Patterns
Over time, certain patterns in incident history can tell you important things about devices and usage:
Normal Wear Pattern
Year 1: 1 incident (minor software issue)
Year 2: 1 incident (battery replacement - normal aging)
Year 3: 2 incidents (screen crack + trackpad wear)
This is typical for a device being used as intended. Some maintenance is expected.
Misuse Pattern
Month 1: Screen crack
Month 2: Another screen crack
Month 3: Physical damage to case
Month 4: Screen crack again
Repeated similar damage in short time spans suggests the device isn't being cared for properly.
Lemon Device Pattern
Week 1: Won't power on
Week 3: Battery replacement
Week 5: Hard drive failure
Week 7: Screen issues
Multiple unrelated problems in rapid succession might indicate a defective device that should be replaced under warranty.
Heavy Use Pattern
Many incidents, but spread across 3-4 years
Mix of normal maintenance (battery, keys) and minor damage
Long periods between similar problems
This device is being used heavily but maintained - it's doing its job!
Filtering and Searching Incidents
While the incident history table shows all incidents chronologically, you might need to find specific ones:
Looking for specific incident types:
- Scan the Incident Type column for the flag you're interested in
- Most browsers let you use Ctrl+F (Windows) or Cmd+F (Mac) to search the page for keywords
Finding incidents from a specific time period:
- Incidents are sorted by date with newest first
- Scroll through to find the timeframe you need
- The Date column helps you navigate chronologically
Finding incidents in a specific status:
- Look at the Incident Status column
- Open incidents will have no Finish Date
For more complex incident searches across multiple devices, use the main incident list at View Incidents from the navigation menu, which has powerful filtering and search tools.
Creating New Incidents From This Page
While viewing a device profile, you might identify a new problem that needs to be documented. You can create a new incident without leaving the device profile:
- Look for a Report Incident or Create Incident button (usually in the quick actions area)
- Click it to open the new incident form
- Fill out the incident details
- Save the incident
The new incident will immediately appear at the top of the incident history table.
To create new incidents, you need the Create Incidents permission assigned to your administrator role.
What You Won't See Here
The Incident History tab focuses on problems and repairs. You won't find:
- Device assignments: Who has the device is in the Checkout History tab
- General device changes: Status changes, building moves, etc. are in the Activity Log tab
- Internal notes: Administrator notes about the device are in the Notes tab
- Purchase or inventory info: That's in the Device Information tab
Each tab has its specific focus - Incident History is purely about problems, repairs, and maintenance.
Tips for Using Incident History Effectively
✅ Best Practices:
- Review incident history before assigning a device to a new user - avoid giving students devices with ongoing problems
- Cross-reference incident dates with checkout history to see who had the device when problems started
- Look for patterns over time to identify devices that should be retired
- Use incident history to justify replacement purchases or warranty claims
- Check previous repair notes before attempting to fix similar issues
⚠️ Common Mistakes:
- Don't assume a long incident list means a bad device - check the dates and severity
- Don't skip documenting incidents because you fixed them quickly - the history is valuable
- Don't ignore patterns of repeated damage - they might require user training or policy changes
- Don't forget that empty incident history doesn't mean perfect condition - physical inspection still matters
Privacy and Reporting
Incident records may contain sensitive information:
- Student names and details
- Descriptions of how damage occurred
- Photos that might be used for disciplinary action
- Cost information that affects families
Your district should have policies about:
- Who can access incident information
- Whether incidents are shared with parents
- How incident data is used for billing or disciplinary purposes
- Student privacy compliance (FERPA)
Always follow your organization's guidelines when viewing or sharing incident information.
Common Questions
Q: Why do some incidents show types/flags and others don't? Incident types (flags) are optional tags. Not all incidents have them - it depends on whether the person creating the incident assigned category flags. Older incidents might not have been tagged when your district started using flags.
Q: Can I edit or delete incident history? If you have the appropriate permissions (Edit Incidents, Delete Incidents), you can modify or remove incident records. However, be cautious - incident history is often used for accountability, billing, and warranty purposes. Deleting incidents removes important documentation.
Q: What if an incident shows as "Completed" but the device still has the problem? The incident status just reflects what's recorded in the system. If the problem persists, either the repair wasn't successful or it's a new occurrence of the same issue. Create a new incident to document the ongoing problem.
Q: Why does a device have many incidents but still shows as "Active" status? Device status (Active, Sold, Lost, etc.) is separate from incident history. A device can have many repairs but still be in active use. The device status would only change if the device is retired, sold, or lost - not because it's had repairs.
Q: How far back does incident history go? All incidents ever created for this device are shown, going back to when the device was first added to Manage1to1. If you migrated from another system, only incidents created after migrating will appear.
Next Steps
The Incident History tab tells you what problems occurred. To get the complete device picture:
- Checkout History - See who had the device when problems happened
- Activity Log - View all actions taken on the device, not just incidents
- Notes - Read administrator notes that might provide context about incidents
Together, these tabs help you understand not just what went wrong, but when, who was involved, and what was done about it!