If you administer PowerSchool for a district, you’ve probably fielded this question more than once: “Should we be using Log Entries or Incidents for behavior?”
It usually comes up in August, when a new dean or assistant principal starts asking why the middle school documents referrals one way and the high school does it another. Or it comes up in the spring, when someone asks for a behavior report and the data turns out to be scattered across two systems with no consistent logic behind which entries went where.
After years of working inside PowerSchool with districts of every size, here’s the honest answer: it’s almost never one or the other. Log Entries and Incident Management were built for different jobs, and most districts that have clean, useful behavior data use both — with clear rules about when each one applies.
This article walks through what each tool actually does, where each one shines, where each one gets misused, and how to build a behavior documentation process your staff will actually follow. Whether you’re a PowerSchool administrator, a building principal, a PBIS coordinator, or the counselor who keeps getting asked to “pull the behavior data,” this should give you a practical framework you can bring back to your team.
One caveat before we start: PowerSchool is highly configurable, and behavior workflows vary widely between districts and states. What’s true in Illinois may not be true in Texas or California, and what one district does with Log Entries another handles entirely through Incident Management. Where functionality depends on configuration or state requirements, I’ll say so.
Why Consistent Behavior Documentation Matters
Before comparing tools, it’s worth being clear about why any of this matters.
Student behavior documentation serves several purposes at once. It creates a record administrators can review when patterns emerge. It supports MTSS and PBIS teams who need data to identify students for intervention. It protects the district when discipline decisions are challenged. It feeds state reporting in states that require discipline data. And — often overlooked — it captures the positive side: recognitions, restorative conversations, and parent contacts that tell the full story of a student’s year.
None of that works if documentation is inconsistent. If one teacher writes up a phone violation as an Incident, another logs it as a “Discipline” log entry, and a third emails the dean and documents nothing, your behavior reports are fiction. The single biggest predictor of useful behavior data isn’t which tool a district picks — it’s whether staff know when to use each one and actually do it the same way.
So let’s look at the two tools.
Understanding PowerSchool Log Entries
Log Entries are the older, simpler of the two systems, and they’re deceptively useful.
A Log Entry is essentially a timestamped note attached to a student’s record. Each entry has a Log Type (Discipline is the most familiar, but districts define others — Counselor, Parent Contact, Nurse, PBIS, and so on), an optional subtype and category, a date, an author, a title, and a free-text description. Discipline-type log entries also include fields for things like consequence and location, depending on how your district has configured the page.
On the admin side, staff open a student’s record and go to the Log Entries page to view or create entries. Teachers, in most district configurations, can submit log entries from PowerTeacher — typically through the Submit Log Entry function — which routes the entry onto the student’s record where office staff and administrators can see it. Exactly what teachers can submit, and which log types they can use, depends on district setup, and some districts extend or replace this workflow with customizations.
How Log Entries Typically Get Used
The typical workflow is short: something happens, a staff member writes it down, and it lands on the student’s record. That’s it. No routing, no investigation stage, no participant roles. That simplicity is the whole point.
Because Log Entries are just structured notes, districts use them for far more than discipline. Common examples include:
- Minor behaviors: classroom disruption, dress code, phone violation, tardies to class, hallway reminders
- Positive behavior tracking: positive recognition, positive citizenship, PBIS points or acknowledgments, student achievements
- Communication records: parent contact, parent phone call attempts, student conferences
- Support documentation: counselor meetings, academic concerns, teacher observations, restorative conversations, intervention notes
- Low-level consequences: lunch detention, warning issued, seat change
That range is exactly why nearly every district ends up using Log Entries for something, even if their formal discipline process lives elsewhere.
Advantages of Log Entries
They’re fast. A teacher can document a classroom disruption in under a minute. That speed matters more than people admit — documentation systems only work if busy staff will actually use them between classes.
They require almost no training. If a staff member can write an email, they can write a Log Entry. New teachers can be documenting behaviors on day one.
They’re flexible. Because log types are district-defined, you can document nearly anything: attendance concerns, counseling notes, academic interventions, classroom observations, PBIS recognitions. Log Entries are the natural home for the 90% of student documentation that isn’t a formal discipline event.
They’re excellent for positive behavior. This is underused almost everywhere. Districts running PBIS often create dedicated log types for positive recognition, which makes it possible to report on the ratio of positive to corrective contacts — a metric PBIS coordinators genuinely care about and rarely have data for.
They build the paper trail that supports MTSS. A student’s log history — minor behaviors, teacher observations, parent contacts, counselor notes — is often the record an intervention team reviews when deciding whether a student needs Tier 2 support.
Considerations When Using Log Entries
Log Entries have real limitations, though most of them are about structure rather than capability.
Consistency depends entirely on configuration and training. Out of the box, Log Entries are free-form. If your district hasn’t standardized log types, subtypes, and categories, you’ll end up with “Cell Phone,” “Phone Violation,” and “Electronics” all describing the same behavior — and reports that can’t group them. Districts that get good data out of Log Entries invest time up front in defining a clean, limited list of types and subtypes and retiring duplicates.
There’s no built-in investigation workflow. A Log Entry is a note, not a case. There are no participant roles, no victim or witness records, no structured evidence attachments, no review stages. For anything that requires an investigation — bullying allegations, threats, anything that might lead to suspension — Log Entries alone leave gaps.
State reporting support varies. This one matters, and it genuinely differs by state. Some state reporting implementations in PowerSchool allow certain discipline data captured in Log Entries to be mapped for reporting purposes. Others rely almost entirely on Incident Management for reportable discipline. Before you decide anything about your behavior workflow, check your state’s PowerSchool state reporting documentation and your state education agency’s requirements. Districts should follow their state’s guidance and their own board policy — no blog article, this one included, overrides that.
Free-text descriptions age poorly. A log entry that says “talked to student about behavior” tells a future administrator nothing. Districts that rely on Log Entries usually pair them with brief documentation standards: what happened, when, what was done, who was contacted.
Understanding PowerSchool Incident Management
Incident Management is the structured, formal side of PowerSchool behavior tracking. Where a Log Entry is a note about a student, an Incident is a documented event — one that can involve multiple students, multiple roles, evidence, and a sequence of administrative decisions.
An Incident record is built around participants. A single incident can include one or more offenders, victims, witnesses, and reporters — each attached with their specific role. That structure matters: a fight between two students, witnessed by three others and reported by a hall monitor, is one incident with six participants, not five disconnected notes on five student records.
Beyond participants, incidents capture:
- Behavior codes — the specific conduct involved, usually aligned to district and state discipline code lists
- Actions taken — consequences and responses, such as detention, in-school suspension, out-of-school suspension, or referral to counseling, often with begin/end dates and duration
- Objects and attributes — things like weapons or substances involved, and contextual details many states require
- Attachments — statements, photos, and other evidence, where district configuration allows
- Times, locations, and descriptions — the who/what/when/where of the event
In most implementations, Incident Management lives on the administrative side of PowerSchool. Teachers generally don’t create incidents directly; they report behavior (often through a Log Entry or a referral process), and an administrator or designated staff member creates and manages the incident. Access is controlled through security settings, and many districts deliberately limit incident creation to deans, assistant principals, and district student services staff. As with everything in PowerSchool, districts can configure this differently.
Advantages of Incident Management
Structure produces defensible records. When a suspension is appealed or an expulsion hearing happens, an incident record with defined participants, behavior codes, actions with dates, and attached statements holds up in a way a paragraph of free text doesn’t. The audit trail is the feature.
It handles multi-student events properly. Fights, bullying situations, and group incidents are inherently multi-participant. Incident Management models that reality; Log Entries can’t.
It’s built for state reporting. In many states, PowerSchool’s state reporting extracts pull reportable discipline data — offenses, actions, durations, weapon involvement, and similar fields — from Incident Management. If your state requires discipline reporting, there’s a good chance Incident Management is where that data is expected to live. Again: verify against your state’s requirements, because implementations differ significantly from state to state.
It supports investigation workflows. Serious events aren’t documented in one sitting. An incident can be created when the event is reported, then updated as statements are collected, evidence is attached, and actions are decided. The record grows with the investigation.
It standardizes discipline data. Because incidents use defined behavior and action codes rather than free text, district-level discipline reports — suspension rates, disproportionality analysis, behavior trends by building — become far more reliable.
Considerations When Using Incident Management
It takes longer. Creating a complete incident with participants, behaviors, actions, and descriptions takes real time. That’s appropriate for a suspension; it’s overkill for a dress code reminder.
It requires training. Staff need to understand participant roles, behavior codes, action codes, and — where applicable — which fields feed state reporting. Districts that roll out Incident Management without training end up with incomplete records that fail state validation later.
It’s more than teachers need for daily classroom behavior. Most teachers neither want nor should have incident creation access. When districts try to make Incident Management the tool for everything, teachers stop documenting minor behaviors altogether — which destroys the early-warning data MTSS teams depend on.
Coding decisions have consequences. Because incident data often feeds state reporting, a miscoded behavior or action isn’t just messy — it can produce reporting errors. Districts should decide who’s allowed to select reportable codes and review incidents before state submission windows.
Log Entries vs. Incident Management: Side-by-Side Comparison
| Category | Log Entries | Incident Management |
| Primary purpose | Quick documentation of student-level notes and minor behaviors | Structured documentation of significant behavior events |
| Ease of use | Very simple; minimal clicks | More involved; multi-step entry |
| Documentation detail | Free-text with type/subtype fields | Structured: participants, behaviors, actions, objects, attachments |
| Teacher adoption | High — teachers can submit from PowerTeacher in most configurations | Low by design — usually admin-only |
| Positive behaviors | Excellent fit (PBIS recognition, positive citizenship) | Not the intended use |
| Minor behaviors | Ideal (tardies, phone violations, disruptions) | Usually more structure than needed |
| Major behaviors | Insufficient on its own | Designed for exactly this |
| Parent communication records | Common and effective use | Not the intended use |
| Flexibility | Very high — district-defined types cover almost anything | Focused on discipline events |
| Investigation workflow | None built in | Participants, evidence, actions, ongoing updates |
| State reporting | Varies — some states support mapping certain log data; many do not | Primary discipline reporting source in many state implementations |
| Reporting capabilities | Good, if types/subtypes are standardized | Strong for discipline analytics and compliance reporting |
| Customization | High (types, subtypes, categories, page customization) | Configurable codes and settings within a defined structure |
| Time required | Under a minute | Several minutes to much longer, depending on the event |
| Best users | Teachers, counselors, office staff, PBIS teams | Deans, assistant principals, principals, district student services |
On the state reporting row: resist the urge to treat this as a yes/no question. Whether Log Entries can satisfy any reporting requirement — and whether Incident Management is mandatory for reportable offenses — depends on your state’s PowerSchool reporting implementation and your state education agency’s rules. Your state reporting documentation and your PowerSchool state reporting contacts are the authority here.
The Recommended Approach: Use Both, With Clear Rules
The districts with the cleanest behavior data almost always use both tools, separated by a threshold everyone understands. A workable default looks like this:
Log Entries handle:
- Minor classroom disruptions and low-level behaviors
- Positive behavior recognition and PBIS acknowledgments
- Teacher observations and academic concerns
- Parent communication records
- Counselor meetings and restorative conversations
- Intervention documentation for MTSS
Incident Management handles:
- Repeated behaviors that have escalated to formal administrative response
- Bullying and harassment investigations
- Fights and physical aggression
- Weapons, drugs, and threat assessments
- Any behavior resulting in suspension or expulsion
- State-reportable discipline, per your state’s defined workflow
The dividing line most districts land on is something like: if it requires an administrative investigation, involves multiple participants, could result in suspension, or is state-reportable, it’s an Incident. Everything else is a Log Entry.
Why does this split produce better data? Three reasons.
First, it keeps Incident Management clean. When incidents are reserved for genuinely significant events, your discipline reports mean something. A building with 40 incidents had 40 serious events — not 12 serious events buried under 28 dress code write-ups.
Second, it keeps teachers documenting. Teachers will log a disruption in 45 seconds; they will not complete a multi-step incident form for it. Give them the fast tool for the frequent behaviors and you capture the early-warning data that predicts bigger problems.
Third, it makes escalation visible. When minor behaviors live in Log Entries, an administrator reviewing a student can see the pattern before the major event — which is the whole premise of MTSS and PBIS.
What This Looks Like in Practice: A Realistic District Example
Here’s a scenario that plays out in some form in nearly every district.
A seventh-grade math teacher notices a student repeatedly disrupting class — calling out, distracting neighbors, refusing redirection. The first week, she handles it in the classroom and submits a Log Entry: Classroom Disruption, with two sentences describing what happened and what she did.
Over the next three weeks, the behavior continues. She submits two more Log Entries and adds a Parent Contact entry after calling home. The science teacher, seeing similar behavior, logs an entry of his own.
Now the assistant principal opens the student’s record. Instead of a vague sense that “this kid has been a problem lately,” she sees five dated entries from two teachers, a documented parent call, and a clear escalation pattern. She meets with the student, and the following week the student shoves another student in the hallway during an argument.
That event crosses the threshold. The assistant principal creates an Incident: the student as offender, the shoved student as victim, two witnesses attached, statements uploaded, behavior coded, and a one-day in-school suspension recorded as the action. She references the log history in the incident description.
A parent meeting follows. The MTSS team reviews the combined record — log entries plus incident — and assigns a check-in/check-out intervention, documented going forward with its own log type. Over the next two months, the log record shifts: fewer disruption entries, several positive recognition entries from both teachers.
Notice what made this work. The teachers had a fast tool they actually used, so the pattern was visible early. The administrator had a structured tool for the serious event, so the discipline record is complete and defensible. And the intervention team had both datasets, so their decision was based on evidence rather than hallway impressions. Neither tool alone tells this story.
Common Mistakes Districts Make
After enough implementations, the same problems show up repeatedly:
Using Incidents for everything. Some districts, often after a compliance scare, mandate incidents for every behavior. Within a semester, teachers stop reporting minor behaviors entirely, and the district loses exactly the early data that prevents major incidents.
Never documenting positive behaviors. If your behavior data is 100% negative, your PBIS program has no data and your student records read like rap sheets. Positive documentation is cheap insurance and genuinely changes how intervention meetings go.
Inconsistent or duplicate log types. “Cell Phone” and “Phone Violation” as separate subtypes will haunt every report you run for years. Audit your log types annually and retire duplicates.
No written standards. If the rule for “log entry vs. incident” lives in the dean’s head, it changes every time the dean changes. Write a one-page decision guide and put it in the staff handbook.
No training beyond the tech. Staff need to know more than where to click — they need to know what a good entry looks like, what belongs in each tool, and what never belongs in either (editorializing, speculation about home life, diagnoses).
Over-documenting minor issues and under-documenting major ones. Ironically, these often coexist: fifteen log entries about gum chewing at the same school where a bullying investigation produced a single vague note. Documentation effort should scale with severity — that’s the entire logic of using both tools.
Ignoring the data after collecting it. Behavior documentation isn’t filing; it’s supposed to drive decisions. If nobody reviews behavior trends monthly, you’re paying the documentation cost without collecting the benefit.
Best Practices for a District Behavior Documentation Process
If you’re building or rebuilding your process, this sequence works:
- Write district standards first. One page: what goes in Log Entries, what triggers an Incident, who creates each, and turnaround expectations. Get building administrators to agree before touching configuration.
- Standardize log types and subtypes district-wide. A short, clean list beats a long, precise one. Every type you add is a decision every staff member has to make correctly.
- Align incident codes to state requirements. Work through your state reporting documentation and make sure behavior and action codes map correctly before the school year starts, not before the submission deadline.
- Train by role. Teachers learn Log Entries and the referral threshold. Administrators learn Incident Management, coding, and state reporting implications. Counselors and PBIS coordinators learn both, plus reporting.
- Build positive behavior tracking in from day one. Create the positive log types, tie them to your PBIS framework, and report on them alongside corrective data.
- Review data on a schedule. Monthly building-level review of behavior trends, repeat students, and time/location patterns. Quarterly district review. If a report never gets read, either fix the report or stop pretending it matters.
- Monitor the escalation pipeline. The most valuable report you can build is the one that flags students accumulating log entries before an incident occurs. That’s where documentation becomes intervention.
- Audit annually. Each summer, review log type usage, retire what’s unused, fix inconsistencies, and update the standards document based on what actually happened during the year.
Frequently Asked Questions
What is the difference between PowerSchool Log Entries and Incidents?
Log Entries are quick, flexible notes attached to a single student’s record — suited for minor behaviors, positive recognition, parent contacts, and general documentation. Incidents are structured event records that support multiple participants (offenders, victims, witnesses), behavior and action codes, evidence attachments, and administrative investigation — suited for serious discipline events and, in many states, state reporting. Think of it as notes versus case files.
Can teachers create Incidents?
In most district configurations, no — and most districts prefer it that way. Teachers typically document behaviors through Log Entries or a referral process, and administrators create incidents when events warrant them. PowerSchool security settings control who can create and manage incidents, so districts can configure this differently, but limiting incident creation to administrators keeps discipline coding consistent and protects state reporting accuracy.
Should positive behaviors be documented in PowerSchool?
Yes, and Log Entries are the natural place. Districts running PBIS often create dedicated positive log types (Positive Recognition, Positive Citizenship, PBIS Acknowledgment). Documented positives give intervention teams a complete picture of a student, give PBIS coordinators real data on positive-to-corrective ratios, and change the tone of parent meetings considerably.
Can Log Entries be used for state reporting?
It depends on your state. Some state reporting implementations in PowerSchool allow certain discipline data from Log Entries to be mapped for reporting; many states rely primarily or entirely on Incident Management for reportable discipline. Check your state’s PowerSchool state reporting documentation and your state education agency’s requirements before building your workflow around either assumption.
When should a Log Entry become an Incident?
Common thresholds: the behavior requires an administrative investigation, involves multiple participants, involves safety (fights, weapons, threats, bullying, harassment), could result in suspension or expulsion, or is state-reportable. A useful pattern is documenting the escalation itself — the incident description can reference the accumulated log history that preceded it.
Can districts customize behavior categories?
Yes, in both systems. Log types, subtypes, and categories are district-defined, and the log entry page itself can be customized. Incident Management behavior and action codes are configurable within the structure PowerSchool provides, though state reporting requirements often dictate how certain codes must be set up. The bigger challenge is governance: deciding on a clean list and keeping buildings from drifting apart.
What’s the best behavior documentation workflow?
For most districts: teachers document minor behaviors and positives through Log Entries; a defined threshold triggers administrative review; administrators create Incidents for events that cross it; and MTSS/PBIS teams review both datasets on a regular cycle. The specifics should follow your district policies and state requirements — the constant is that everyone knows the rules and applies them the same way.
Can administrators report on Log Entries?
Yes. Log entry data can be queried and reported through PowerSchool’s reporting tools, and many districts build regular reports on log counts by type, student, teacher, or building. The catch: reporting quality depends entirely on how consistently log types and subtypes are used. Standardization first, reporting second.
Can both systems be used together?
Not only can they — they should be. They’re complementary by design. Log Entries capture the high-frequency, low-severity documentation that reveals patterns; Incident Management captures the low-frequency, high-severity events that require structure and defensibility. Districts that force everything into one tool lose either their early-warning data or their audit trail.
How do successful districts typically implement behavior tracking?
The pattern is consistent: written standards adopted district-wide, a short standardized list of log types, incident creation limited to trained administrators, codes aligned to state reporting before the year begins, role-based training, positive behavior tracking from day one, and scheduled data review that actually informs interventions. None of it is technically difficult. All of it requires someone to own the process.
Does using Incident Management replace the need for Log Entries?
No. Even in districts with mature Incident Management practices, Log Entries carry the everyday documentation load — parent contacts, counselor notes, minor behaviors, positive recognition, intervention records. Retiring Log Entries would mean either forcing that volume into Incident Management (which staff won’t sustain) or losing it entirely.
How long should behavior documentation be retained?
Follow your district’s records retention policy and applicable state law — retention requirements for discipline records vary by state and by record type. What PowerSchool administrators can control is making sure documentation is complete and accurate at the time it’s created, because incomplete records can’t be fixed years later when they’re needed.
The Bottom Line
Log Entries and Incident Management aren’t competitors, and the question was never really “which one?” Log Entries are the fast, flexible tool for the everyday documentation that makes patterns visible — minor behaviors, positive recognition, parent contacts, intervention notes. Incident Management is the structured tool for serious events that demand participants, evidence, coded actions, and a defensible record — and in many states, it’s where reportable discipline lives.
The districts that get real value from PowerSchool behavior tracking share one trait: clear, written, consistently applied standards for which tool handles what. Build that standard around your district’s policies and your state’s reporting requirements, train staff by role, track the positives alongside the negatives, and actually review the data you collect. Do that, and the tools take care of themselves.
About PureData
PureData has worked with hundreds of PowerSchool schools and districts since 2011, and behavior documentation comes up in a large share of those engagements. Over the years, we’ve helped districts extend PowerSchool’s native behavior tools where their workflows needed more — including enhanced behavior management and referral workflows, PBIS and positive behavior tracking, multi-student behavior entry, custom behavior dashboards, automated parent notifications, and behavior analytics and trend reporting built for administrators and MTSS teams.
If your district is rethinking its behavior documentation process — whether that means standardizing what you have or extending what PowerSchool provides — we’re always glad to compare notes on what’s worked in districts like yours.
