Skip to main content

Incident Log

The Incident Log is a chat-style timeline that documents everything that happens with an incident from creation through completion. It creates an audit trail of repair progress, administrator actions, and important notes throughout the incident lifecycle.

The incident log is found on the Incident Log tab of any incident profile.

Permission Required

To view the incident log, you need the View Incidents permission assigned to your administrator role.

Understanding the Incident Log​

Think of the incident log as a conversation history about the repair. It shows:

  • What happened - Actions taken, decisions made, progress updates
  • Who did it - Which administrator performed the action
  • When it happened - Date and time of each entry

The log displays entries in chronological order (oldest first, newest last), creating a complete timeline from initial report through final resolution.

Types of Log Entries​

Automatic Entries​

The system creates log entries automatically when certain actions occur:

Incident creation:

  • "Incident created by [Admin Name]"

Status changes:

  • "Status changed from Pending to In Progress"
  • "Status changed to Completed"

Incident edits:

  • "Incident updated by [Admin Name]"

Photo uploads:

  • "Photos added to incident"

Flag acknowledgments:

  • "Incident flag acknowledged"

Incident marked complete:

  • "Incident marked as completed by [Admin Name]"

These automatic entries ensure key actions are always documented, even if administrators forget to add manual notes.

Manual Entries​

Administrators add manual log entries to document:

  • Repair progress updates
  • Communication with users
  • Diagnostic findings
  • Parts orders or delays
  • Next steps planned
  • Issues encountered
  • Important context or decisions

Examples of good manual entries:

  • "Contacted student, device dropped during PE class transition. No visible damage beyond screen crack."
  • "Ordered replacement battery from vendor #12345, ETA 3 business days."
  • "Attempted keyboard repair, keys still unresponsive. Liquid damage suspected, full keyboard replacement needed."
  • "Device ready for pickup. Emailed user at [email] with pickup instructions."
  • "User picked up device 3:15pm, tested all functions, user satisfied with repair."

Adding Log Entries​

At the bottom of the Incident Log tab, you'll see a text area for adding new entries.

How to Add an Entry​

  1. Navigate to the incident profile
  2. Click the Incident Log tab
  3. Scroll to the bottom of the log
  4. Type your note in the text box
  5. Click Add Note
  6. The entry appears in the log immediately with your name and timestamp
Permission Required

To add incident log entries, you need the Add Incident Log permission.

What to Include in Log Entries​

Good log entries are:

  • Specific - Include details like part numbers, times, names
  • Objective - Document facts, not opinions or assumptions
  • Actionable - Explain what happened and what's next
  • Contextual - Provide information that helps others understand

Examples:

✅ Good: "Spoke with Mrs. Johnson (teacher), device was working fine Friday. Monday morning wouldn't power on. Tried known-good charger, no response. Battery or logic board issue suspected."

❌ Vague: "Teacher said it doesn't work."

✅ Good: "Replaced screen assembly (part #LCD-7890). Tested touch response across entire display. All quadrants responsive. Device returned to service."

❌ Incomplete: "Fixed screen."

✅ Good: "Waiting for replacement keyboard from TechSupply (order #45678), tracking shows delivery Thursday 3/15. Will install upon arrival."

❌ Unclear: "Waiting for parts."

When to Add Log Entries​

Critical Moments to Document​

When starting work:

  • "Beginning diagnostic assessment"
  • "Device received in repair queue"

During diagnosis:

  • "Tested with known-good charger, device charges normally. Issue appears to be original charger failure."
  • "Ran hardware diagnostics, battery health at 45%. Replacement recommended."

When ordering parts:

  • "Ordered screen assembly from [Vendor], tracking #[number], ETA [date]"

When parts arrive:

  • "Replacement battery received, beginning installation"

During repair:

  • "Screen replacement in progress"
  • "Encountered issue: screw stripped during disassembly, using extraction tool"

When testing:

  • "Repair complete, running full device diagnostics"
  • "All functions tested: display, touch, keyboard, trackpad, ports, WiFi - all operational"

When communicating with users:

  • "Emailed user about repair completion, device ready for pickup"
  • "Called user regarding additional damage found, approved $50 additional charge"

When completing:

  • "Device tested and ready for deployment"
  • "User picked up device, signed receipt"

When issues arise:

  • "Repair delayed, waiting for specialized tool"
  • "Cannot complete repair, part no longer available, recommending device replacement"

Viewing Log Entry Details​

Each log entry shows:

Administrator name - Who created the entry (or "System" for automatic entries)

Timestamp - Exact date and time of the entry

Message - The log content

Entry format example:

John Smith
03/10/2024 2:45 PM
Replaced battery, device now charging normally. Tested for 30 minutes, charge holding at expected rate.

Deleting Log Entries​

Some log entries can be deleted if needed (typically user-created entries, not system-generated ones).

How to Delete an Entry​

  1. Locate the entry in the log
  2. Look for a delete button or icon (usually an X or trash icon)
  3. Click to delete
  4. Confirm deletion if prompted
  5. Entry is removed from the log
Permission Required

To delete incident log entries, you need the Delete Incident Log permission.

When to Delete Entries​

Appropriate reasons to delete:

  • ✅ Accidentally posted duplicate entry
  • ✅ Entry contains incorrect information that cannot be corrected with a new entry
  • ✅ Typo that causes confusion
  • ✅ Test entry posted by mistake

When NOT to delete:

  • ❌ Entry reveals a mistake you made - instead, add a correction entry
  • ❌ Entry documents something embarrassing - maintain historical accuracy
  • ❌ Incident is completed and you want to "clean up" the log - preserve the complete history
  • ❌ Someone asks you to remove their entry - discuss with administration first

Best practice: Instead of deleting entries, add a new entry clarifying or correcting previous information. This maintains the complete audit trail.

Best Practices for Incident Logging​

Be Timely​

  • Add entries when actions happen, not hours or days later
  • Document as you work rather than from memory later
  • Update the log at natural milestones (diagnosis complete, parts ordered, repair finished)

Be Complete​

  • Include all relevant details (part numbers, error messages, test results)
  • Document conversations with users (what they said, what you advised)
  • Record decisions made and why
  • Note who was involved (other technicians, vendors, users)

Be Professional​

  • Use clear, professional language
  • Avoid slang, abbreviations (unless industry-standard)
  • Keep tone objective and factual
  • Don't include inappropriate comments or speculation

Be Helpful​

  • Write entries that help the next person understand what's happening
  • Explain your reasoning for decisions
  • Document things you wish you had known when you started
  • Provide context that won't be obvious to someone reading later

Common Scenarios​

Scenario 1: Multi-Day Repair​

An incident spans several days with multiple administrators working on it:

Day 1 - Admin A:

  • "Device received. Initial assessment: won't power on, no charging indicator. Beginning diagnosis."
  • "Tested with known-good charger and cable. No response. Battery or logic board issue suspected."
  • "Running battery diagnostic test overnight."

Day 2 - Admin B:

  • "Diagnostic complete. Battery health: 12%, far below acceptable threshold. Ordering replacement battery."
  • "Order placed with TechParts, order #67890, tracking #1Z999, ETA Thursday."

Day 4 - Admin A:

  • "Battery arrived. Beginning replacement procedure."
  • "Battery installed successfully. Device now powers on and charges normally."
  • "Running full system test to verify all functions operational."
  • "All tests passed. Device ready for user pickup. Notified user via email."

Day 5 - Admin B:

  • "User picked up device 11:00am. Demonstrated charging, confirmed working. User satisfied."

Scenario 2: Insurance Claim Documentation​

Creating a thorough record for insurance purposes:

  • "Device brought in by student. Assessment: Large crack across entire screen, touch unresponsive in top right quadrant."
  • "Interview with student: Device dropped from desk during class, fell approximately 3 feet onto tile floor. Immediately stopped responding to touch in damaged area."
  • "Photos uploaded showing extent of damage (4 photos attached)."
  • "Contacted insurance carrier, claim #ABC-12345 filed."
  • "Insurance approved claim. Proceeding with screen replacement."
  • "Screen replaced (part #SCR-7890-A), touch tested across all zones, fully functional."
  • "Insurance claim documentation completed and submitted."

Scenario 3: Complex Repair with Issues​

Documenting challenges during repair:

  • "Attempting screen replacement."
  • "Issue encountered: adhesive extremely difficult to remove without damaging display cables. Proceeding with caution."
  • "During disassembly, discovered additional damage not visible in initial assessment: bent frame near hinge."
  • "Contacted user about additional damage. User approved frame repair, additional cost $35."
  • "Frame straightened using alignment tool. Screen replaced. Testing all functions."
  • "WiFi antenna appears damaged during initial impact. Ordering replacement antenna."
  • "Antenna replaced. All systems now functional. Extended testing in progress."
  • "24-hour test completed, all functions stable. Device ready for deployment."

Tips for Effective Logging​

✅ Do:

  • Log in real-time or immediately after actions
  • Include specific details (part numbers, times, names)
  • Document both successes and issues
  • Write entries that help future readers
  • Use the log to communicate with other administrators
  • Add entries even for quick repairs (documents efficiency)

❌ Don't:

  • Wait days to add entries from memory
  • Use vague language ("fixed it", "broken")
  • Skip logging just because repair was quick
  • Delete entries to hide mistakes
  • Assume everyone knows context you have
  • Write unprofessional or inappropriate content

Common Questions​

Q: How many log entries should I add for one incident? As many as needed to tell the complete story. Simple repairs might have 3-4 entries; complex multi-day repairs might have 15-20. Document all key actions and decisions.

Q: Can other administrators see my log entries? Yes. All administrators with View Incidents permission can see all log entries. The log is a shared communication tool.

Q: What if I make a typo in a log entry? If you have Delete Incident Log permission, you can delete and re-post. Otherwise, add a new entry: "Correction to previous entry: [correct information]"

Q: Do I need to log every single action? No, use judgment. Log significant actions, decisions, communications, and milestones. Don't log every mouse click or routine action.

Q: Can users see the incident log? No. The incident log is internal to administrators. Users do not have access to incident records or logs.

Q: How long are log entries kept? Indefinitely. Log entries are permanent parts of the incident record and remain even after the incident is completed.

Next Steps​

The incident log is your communication tool, audit trail, and historical record. Keep it detailed and current!

Related articles

Loading…