Skip to main content

Incident History Tab

The Incident History tab provides a complete chronological record of all device-related incidents associated with a user. Think of it as the damage and loss report card - showing every time a device was damaged, lost, stolen, or needed repair while in this user's possession.

This tab is essential for identifying patterns, making informed decisions about device assignments, understanding billing history, and supporting accountability.

Permission Required

To view the Incident History tab, you need both the View Users permission AND the View Incidents permission assigned to your role. If you lack View Incidents permission, this tab won't be visible.

Understanding Incident History​

Think of incident history as a complete record of device issues - every broken screen, lost device, water damage, or theft that occurred while this user had a device checked out.

What incident history shows:

  • All incidents (current and historical)
  • Incident types (Damage, Loss, Theft, etc.)
  • Which device was involved
  • When the incident occurred
  • Current status (Open, Under Review, Resolved, etc.)
  • Repair costs and billing status
  • Investigation notes and outcomes

What incident history doesn't show:

  • Incident details like photos or assessment notes (see individual incident profile)
  • Payment history for incident invoices (see Billing History tab)
  • Which devices are currently checked out (see User Information tab)

Why incident history is important:

  • Pattern identification - Recognize repeat offenders or accident-prone users
  • Informed decisions - Review history before issuing expensive devices
  • Parent communication - Reference past incidents during conversations
  • Billing justification - Show history of charges and damages
  • Accountability - Document user's track record with district devices
  • Intervention planning - Identify users needing device training or support

What You'll See on the Tab​

The Incident History tab displays a table showing all incident records for this user:

Incident History Table Columns​

ColumnWhat It Shows
Incident #Unique incident identifier (clickable to open incident profile)
DateWhen the incident was reported/created
TypeIncident category (Damage, Loss, Theft, etc.)
DeviceWhich device was involved
StatusCurrent incident state (Open, Investigating, Resolved, etc.)
CostRepair cost or replacement value
BilledWhether invoice has been created
ActionsView Incident, PDF Work Order

Visual indicators:

  • Active incidents - May be highlighted or marked (Open, Investigating, In Progress)
  • Resolved incidents - Standard formatting, marked as Complete or Closed
  • Billed incidents - May show checkmark or "Yes" indicating invoice created

Example entry:

Incident #: 2024-001234
Date: 09/15/2024
Type: Damage
Device: Chromebook - Serial ABC123
Status: Resolved
Cost: $150.00
Billed: Yes
Actions: [View] [PDF Work Order]

Example active incident:

Incident #: 2024-002456
Date: 11/20/2024
Type: Loss
Device: iPad - Serial XYZ789
Status: Investigating
Cost: $450.00 (estimated)
Billed: No (pending investigation)
Actions: [View] [PDF Work Order]

Incident Types​

Incidents are categorized by type to describe what happened:

Damage​

What it means:

  • Device is physically broken or malfunctioning
  • Examples: Cracked screen, broken keyboard, water damage, won't power on

Typical workflow:

  • User reports damage
  • Incident created with photos
  • Device assessed for repair cost
  • User billed for repair or replacement
  • Device sent for repair or decommissioned

Common damage types:

  • Cracked/broken screen (most common)
  • Water/liquid damage
  • Physical damage (bent, crushed, broken hinges)
  • Component failure (keyboard, trackpad, ports)

Loss​

What it means:

  • Device is missing or lost
  • User cannot locate the device

Typical workflow:

  • User reports device missing
  • Incident created with loss details
  • Investigation period (searching, verifying loss)
  • If not found, user billed for replacement cost
  • Device marked as lost in inventory

Why loss incidents matter:

  • High cost (full device replacement value)
  • May indicate security or responsibility issues
  • Requires thorough investigation before billing

Theft​

What it means:

  • Device was stolen
  • Differs from loss - theft implies criminal activity

Typical workflow:

  • User reports device stolen
  • Incident created with theft details
  • Police report may be filed
  • Investigation conducted
  • Insurance claim may be filed
  • User may or may not be billed depending on circumstances

Why theft incidents are different:

  • May involve law enforcement
  • Insurance may cover replacement
  • Billing decision depends on circumstances (stolen from locker vs. left unattended)

Other Incident Types​

Districts may configure additional incident types:

  • Malfunction - Technical failure not user-caused
  • Accidental Damage - Unintentional damage (dropped, stepped on)
  • Intentional Damage - Deliberate destruction
  • Found - Previously lost device recovered
  • Missing Accessories - Lost chargers, cases, styluses

Incident Statuses​

Incidents move through various statuses during their lifecycle:

Open

  • Newly created incident
  • Initial report submitted
  • Awaiting review or assessment

Investigating / Under Review

  • Incident is being researched
  • Determining cause, cost, responsibility
  • May involve reviewing evidence, interviewing user

In Progress

  • Active work happening (repair, replacement processing)
  • Device may be at repair center
  • Awaiting parts or service

Resolved / Completed

  • Incident closed
  • All actions taken (device repaired, invoice created, etc.)
  • No further work needed

Pending Billing

  • Incident resolved but invoice not yet created
  • Awaiting final cost determination

Closed - No Charge

  • Incident resolved without billing user
  • Examples: Warranty repair, manufacturer defect, district-absorbed cost

Common Use Cases​

Scenario 1: Reviewing History Before Device Assignment​

A student requests a device and staff want to check their incident history first:

  1. Open student's user profile
  2. Click Incident History tab
  3. Review all incidents:
    • Incident #1: Damage (cracked screen), 01/15/2024, Resolved, $125 billed
    • Incident #2: Damage (water damage), 05/10/2024, Resolved, $200 billed
    • Incident #3: Loss, 08/20/2024, Resolved, $450 billed
  4. Total: 3 incidents, $775 in charges in one year
  5. Decision: Require parent meeting and device training before issuing new device
  6. Document decision in user Notes tab

Result: Informed decision based on pattern of incidents prevents potential future damage.

Scenario 2: Parent Questions Incident Charge​

A parent calls questioning a $150 damage charge from last month:

  1. Open student's user profile
  2. Click Incident History tab
  3. Find incident from last month:
    • Incident #2024-001890: Damage, 10/15/2024, Resolved, $150.00, Billed: Yes
  4. Click View to open incident profile
  5. Review incident details:
    • Photos showing cracked screen
    • Assessment notes: "Screen completely shattered, requires replacement"
    • Repair cost breakdown: Screen replacement $125 + labor $25 = $150
  6. Explain to parent: "The incident was reported on October 15th with photos showing a shattered screen. The repair cost was $150 for screen replacement."
  7. Offer to email incident PDF work order for their records

Result: Clear documentation supports billing decision, parent questions answered.

Scenario 3: End of Year Incident Review​

Principal wants to identify students with multiple incidents for intervention:

  1. Review students in building
  2. For students with known issues, open user profiles
  3. Click Incident History tab
  4. Count incidents for current school year
  5. Student A: 4 incidents (3 damage, 1 loss)
  6. Student B: 2 incidents (both damage)
  7. Student C: 0 incidents
  8. Create list of students with 3+ incidents for device care training program
  9. Schedule parent meetings for repeat offenders

Result: Data-driven intervention program to reduce future incidents.

Scenario 4: Verifying Incident Billing Status​

Business office is reconciling billing and needs to verify incident charges:

  1. Open student's user profile
  2. Click Incident History tab
  3. Review Billed column for each incident:
    • Incident #001: Billed: Yes ✓
    • Incident #002: Billed: No (incident type: malfunction, no user fault)
    • Incident #003: Billed: Yes ✓
  4. Cross-reference with Billing History tab:
    • Invoice #INV-2024-5678 matches Incident #001
    • Invoice #INV-2024-7890 matches Incident #003
  5. Confirm billing is correct
  6. Generate PDF work orders for accounting records

Result: Complete reconciliation of incidents to invoices.

Scenario 5: Supporting Insurance Claim​

A student had their device stolen and district is filing insurance claim:

  1. Open student's user profile
  2. Click Incident History tab
  3. Find theft incident:
    • Incident #2024-002100: Theft, 11/05/2024, Resolved, $450.00
  4. Click View to open incident profile
  5. Review incident details:
    • Police report number documented
    • Theft location and circumstances
    • Device serial number and model
  6. Click PDF Work Order to generate incident documentation
  7. Attach PDF to insurance claim
  8. Submit claim with police report and incident documentation

Result: Complete incident documentation supports insurance claim processing.

Incident Actions​

View Incident​

Click View to open the full incident profile page.

What you'll see:

  • Complete incident details and description
  • Photos uploaded during incident creation
  • Assessment notes and cost breakdown
  • Status history (when status changed and by whom)
  • Internal notes and communications
  • Associated device information
  • Billing status and invoice link (if billed)
  • Actions taken (repair, replacement, etc.)

When to use:

  • Need complete incident context
  • Reviewing photos or damage assessment
  • Checking status updates and notes
  • Verifying cost breakdown
  • Understanding incident resolution

See Incident Profile for complete details.

PDF Work Order​

Click PDF Work Order to generate a printable incident report.

What's included:

  • Incident number and date
  • User information
  • Device information (serial, asset tag, model)
  • Incident type and description
  • Photos (if available)
  • Cost assessment
  • Status and resolution
  • Billing information

When to use:

  • Creating paper documentation for files
  • Providing parent with incident details
  • Supporting insurance claims
  • Accounting/audit documentation
  • Sending incident summary to stakeholders

Formats:

  • PDF download for printing
  • Can be emailed or printed directly

Identifying Incident Patterns​

The Incident History tab helps identify concerning patterns:

High Incident Frequency​

What to look for:

  • Multiple incidents in short time period
  • Example: 3 incidents in 2 months

What it may indicate:

  • User needs device care training
  • User may be careless with devices
  • Environmental factors (harsh conditions, rough handling)

Actions to consider:

  • Require parent meeting before next device issuance
  • Provide device care training
  • Issue more durable device or case
  • Monitor more closely

Repeat Incident Types​

What to look for:

  • Same type of damage repeatedly
  • Example: 3 cracked screens in one year

What it may indicate:

  • Specific handling issue (dropping, sitting on device)
  • Need for protective case or screen protector
  • Behavioral pattern

Actions to consider:

  • Provide targeted training on preventing that specific damage
  • Require protective case
  • Consider device with more durable screen

Loss vs. Damage​

What to look for:

  • Pattern of lost devices vs. damaged devices
  • Users with multiple losses

What it may indicate:

  • Multiple losses - Organizational issues, need for device tracking training
  • Multiple damages - Handling issues, need for device care training

Actions to consider:

  • For losses: Training on device security, organization, tracking
  • For damage: Training on physical device care, protective equipment

High Cost Pattern​

What to look for:

  • Multiple high-cost incidents
  • Total incident costs exceeding device value

What it may indicate:

  • Financial burden on family
  • Need for intervention before more costs accrue

Actions to consider:

  • Payment plan discussions
  • Device insurance enrollment
  • More intensive training and monitoring
  • Consider whether user should continue receiving devices

Cross-Referencing with Other Tabs​

The Incident History tab provides valuable context when used with other profile tabs:

User Information Tab​

Use together to:

  • See current incidents (User Information) vs. all incidents (Incident History)
  • Check compliance status before addressing incidents
  • Access Quick Actions (create new incident from User Information tab)

Example: User Information shows 1 current incident, but Incident History shows 5 total incidents this year.

Checkout History Tab​

Use together to:

  • Match incidents to specific device checkouts
  • Understand which device was involved in each incident
  • Identify if incidents occurred during loaner periods vs. assigned devices

Example: Student had device 9/1-10/1, incident occurred 9/15, device was checked in 10/1 and new device issued.

Billing History Tab​

Use together to:

  • Verify incidents have been billed
  • Check payment status for incident charges
  • Confirm invoice amounts match incident costs

Example: Incident History shows $150 damage charge, Billing History shows corresponding invoice, payment status: Paid.

Notes Tab​

Use together to:

  • Review staff observations about incident patterns
  • Document conversations about incidents
  • Record intervention plans based on incident history

Example: Notes tab documents parent meeting on 11/1 about repeated damage, agreement to extra training.

Tips for Using Incident History​

✅ Do:

  • Review incident history before assigning expensive devices
  • Check for patterns (repeat damage types, high frequency)
  • Cross-reference with Billing History to verify charges
  • Use incident history to support parent conversations
  • Document intervention decisions in Notes tab based on incident patterns
  • Generate PDF work orders for documentation and insurance
  • Check "Billed" status to ensure incidents are properly invoiced

❌ Don't:

  • Assume no incidents means perfect record (check thoroughly)
  • Ignore patterns of repeated damage (intervene early)
  • Bill without documenting incident properly (photos, assessment)
  • Delete incident records (permanent audit trail)
  • Overlook unresolved incidents before issuing new devices
  • Skip reviewing incident details when parents have questions
  • Forget to check for active/investigating incidents during checkout

Common Questions​

Q: What's the difference between "Current Incidents" on the User Information tab and this Incident History tab?

  • Current Incidents (User Information tab) - Only shows ACTIVE (unresolved) incidents (Open, Investigating, In Progress)
  • Incident History tab - Shows ALL incidents, both active and historical (Resolved, Closed)

The User Information tab focuses on "what needs attention now," and Incident History shows "everything that's ever happened."

Q: Can I edit or delete incidents from this tab? No. Incident History is a read-only view. To modify incidents, click View to open the incident profile, then use the Edit button if you have Edit Incidents permission. Deletion requires Delete Incidents permission and should only be used for incidents created by mistake.

Q: Why would an incident show as "Billed: No"? Several reasons:

  • Incident is still under investigation (cost not yet determined)
  • Incident was warranty repair (no user charge)
  • Incident was manufacturer defect (no user fault)
  • Incident invoice hasn't been created yet (pending billing)
  • District absorbed cost (policy decision)

Q: How do I create a new incident for this user? Two methods:

  1. From User Information tab: Click Add Incident quick action button
  2. From device profile: If user has device checked out, go to device profile and create incident there

Incidents should be associated with a specific device whenever possible.

Q: What if a user has an incident but the device was already returned? You can still create incidents for previously checked-out devices. Use the incident creation workflow and select the specific device from the user's checkout history. This is common when damage is discovered after check-in.

Q: How far back does incident history go? Incident history is maintained indefinitely unless your district has a data retention policy. Typically, you can see all incidents for the user's entire time in the district.

Q: Can I export incident history for this user? Export options depend on system configuration. Typically:

  • Export incident history table to CSV
  • Use PDF Work Order for individual incidents
  • Use district-wide incident reports for bulk data across all users

Q: Why is an incident marked "Resolved" but not billed? "Resolved" means the incident case is closed (device repaired, replaced, or written off), but it doesn't automatically mean the user was charged. Billing is a separate decision based on:

  • User fault (accidental vs. intentional)
  • Warranty coverage
  • District policy (absorb cost vs. bill user)
  • Insurance coverage

Q: What's the difference between Loss and Theft?

  • Loss - Device is missing, user doesn't know where it is
  • Theft - Device was stolen (criminal activity)

Theft typically involves police reports and may have different billing/insurance implications. Loss is usually user responsibility, while theft billing depends on circumstances.

Q: Can I see who created or resolved each incident? Yes! Click View to open the incident profile. The incident profile shows:

  • Who created the incident
  • Who last modified it
  • Who changed its status
  • All activity history

Q: How do I know if an incident has photos? Click View to open the incident profile. The incident profile page will display any photos uploaded during incident creation or added later. The Incident History tab doesn't show photo thumbnails.

Q: Why don't I see the Incident History tab at all? You're missing the View Incidents permission. Contact your system administrator to request this permission if you need access to incident data.

Q: What should I do if I see a pattern of repeated damage?

  1. Document the pattern (how many incidents, what types, timeframe)
  2. Add note to user's Notes tab documenting the pattern
  3. Consider intervention:
    • Parent meeting
    • Device care training
    • More protective equipment (case, screen protector)
    • More durable device assignment
  4. Monitor future incidents closely
  5. May warrant restricting device privileges if pattern continues

The Incident History tab provides a complete chronological record of all device-related incidents for a user. This permanent record supports pattern identification, informed decision-making, accountability, parent communication, and billing justification throughout the user's relationship with district technology.

Related articles

Loading…