How to set up an incident log in SharePoint

Short answer: make one SharePoint list where every incident, near miss and service problem gets one row. Give each row a date, a type, a severity, an owner, a status and a follow-up due date. Then add a few saved views so the open and overdue items are easy to see, and limit who can open sensitive entries. This page is a how-to for a tracking log. It is not legal, safety or HR advice. Follow your own policy and the rules of your regulators.

What this log is for

An incident log is a shared record of things that went wrong or almost went wrong at work. It can hold a workplace incident, a near miss (something that could have caused harm but did not), or a service problem such as an outage or a missed delivery. The log helps you see what is open, who has it and what is late. It also helps you see patterns over time.

The log does not decide what you must report, to whom or by when. Those rules come from your employer, your contracts and the regulators for your field. Ask the right people in your organization (for example safety, legal or HR) what you must record and how long you must keep it. Then build the log to match.

If you want the version for customer complaints, see "Customer complaints fall through the cracks: one log that closes the loop". An incident log is a different record. It tracks events inside your operation, not messages from customers.

Before you start

Spend a few minutes on three choices. They are easier to make now than after you have 200 rows.

What goes in the log. Write one sentence. For example: "Anything that went wrong, or nearly did, that affected people, equipment, a customer or a service."
Who may add a row. One way to start is to let the whole team add one, so the person who saw it can log it the same day.
Who may read each row. Some entries hold sensitive details. Decide this early. Step 6 shows how to limit access.

Also write down what you will keep out of the log. For example, keep medical details, home addresses and long personal stories out of it. Use a short factual summary and point to the proper record kept elsewhere.

Step 1. Create the list

Microsoft describes a list as a collection of data that you can share with your team and people you have given access to. You can create lists in SharePoint, in the Lists app in Microsoft 365, or in Microsoft Teams. You can start from a template, start from blank, or base a list on a spreadsheet.

Open the SharePoint site for your team, or the Lists app.
Choose the option to create a new list.
Start from blank, or pick a template if one looks close to what you want.
Name the list "Incident log".

The exact menu names may differ in your tenant. Microsoft's pages on lists point to separate "Create a list" articles for the click-by-click steps, so check those if your screen looks different.

Step 2. Add the columns

Columns are the fields on each row. Microsoft's column types page describes the types below. In the list, look for an option to add a column. For the types that are not shown first, look for "More column types" or a similar choice.

Here is one way to start:

Title (the list has this by default). Use it for a short summary, such as "Forklift near miss at dock 2". Keep it to one line. Title is required by default; rename it or turn off Require. The Single line of text type is for small amounts of unformatted text.
Date reported (type: Date and time, date only). Microsoft says the default can be the date the item was added, so the person does not have to type it.
Date of event (type: Date and time). The event may have happened a day or two before it was logged.
Type (type: Choice). Example choices: Incident, Near miss, Service problem. Microsoft says a Choice column lets people pick from a list of options that you provide.
Severity (type: Choice). Example choices: 1 High, 2 Medium, 3 Low. The number prefixes make the choices sort in order. Write a one-line meaning for each, so people pick the same way.
Location or area (type: Choice or Single line of text). Example: Warehouse, Front desk, Online service.
Owner (type: Person or Group). Microsoft says this type gives a searchable list of people and groups to pick from. Limit it to one person.
Status (type: Choice). Example choices: New, Under review, Action in progress, Waiting, Closed.
Follow-up due (type: Date and time). The date when the next action must be done.
What happened (type: Multiple lines of text). A short, factual description. Microsoft says this type holds longer text on more than one line.
Action taken (type: Multiple lines of text). What was done, and what is planned.
Follow-up done (type: Yes/No). Microsoft says this type shows as a checkbox with a default of checked or unchecked.

Microsoft also says you can mark a column as required, so people cannot add an item without entering the information. One way to start is to require Type, Severity, Owner and Follow-up due. Leave the rest optional so that logging stays quick.

Step 3. Write what each choice means

A log only works if people fill it in the same way. Put a short guide next to the list, or in the column description, with one line for each Severity and each Type. Make the lines about what happened, not about blame. For example:

1 High: someone could have been seriously hurt, or a service was down for many customers.
2 Medium: a real problem with limited effect.
3 Low: a small issue with no harm that is worth noting.

These are example words only. Your policy may already define levels. If it does, use your policy words and not these.

Step 4. Add a sample row to test it

Before you tell the team, add one fake row and check that it reads well. Mark it clearly as a test and delete it afterward. Here is a sample:

Title: Pallet fell from rack in aisle 4
Date reported: 2026-10-14
Date of event: 2026-10-13
Type: Near miss
Severity: 2 Medium
Location: Warehouse
Owner: (pick a person from the list)
Status: Under review
Follow-up due: 2026-10-21
What happened: A pallet slipped from the second level. No one was nearby. The rack was empty below.
Action taken: Area blocked off. Rack check requested.
Follow-up done: No

If a row is hard to read or fill in, change the columns now, while the list is still small.

Step 5. Build the views

Microsoft says views let you organize, sort, filter and group list data, and that creating a view does not change the list contents. A saved view means no one has to set filters every time.

Microsoft's page says that in the modern experience you open the view options in the command bar, choose to create a new view, enter a name, and pick how to show it (list, calendar or gallery). You can also sort, filter or group from the column headers or filters pane, and then save the result as a new view. The exact menu names may differ on your screen.

One way to start is with four views:

Open items. For blank and "is not equal to" filters, we also use the classic view editor (Edit current view, then Filters). That part is our advice, not a Microsoft rule. Sort by Follow-up due, ascending.
Overdue. Microsoft says [Today] and [Me] need the classic view editor (Edit current view, then Filters). For blank and "is not equal to" filters, we also use the classic view editor. That part is our advice, not a Microsoft rule. Microsoft says [Today] cannot be set from a column header. This is the view your team lead checks first.
My items. In the classic view editor, set Owner is equal to [Me].
By type and severity. Group by Type, then Severity. Use it in a monthly review.

Microsoft's page also says a personal view is seen only by you, while a public view is seen by everyone who uses the list, and you may need extra permission to create a public one. Make the four views above public if you can, so everyone sees the same thing.

Step 6. Limit who can see sensitive entries

Views are not security. A filtered view only changes what is shown on screen. Someone who can open the list may still be able to reach other items through another view. Use permissions for access control.

Microsoft's page on customizing permissions for a list or library gives these steps:

Open the list.
Open Settings (the gear icon), then List settings.
Under Permissions and Management, choose Permissions for this list.
Choose Stop Inheriting Permissions. Microsoft says Grant Permissions only appears after you do this.
Choose Grant Permissions, enter the names of people or groups, and pick a permission level, such as Read or Edit.
To undo it later, choose Delete unique permissions.

Things to know, all from the same Microsoft page:

Breaking inheritance is supported within reasonable use, but Microsoft does not recommend it, and it adds work to manage.
Microsoft advises using built-in SharePoint groups, or managing team site permissions through the Microsoft 365 group.
Sharing a single item breaks inheritance for that item only. Later changes to the parent do not apply to it.
Removing a person removes their permissions from all children, including items with broken inheritance, and Microsoft says this cannot be undone.

One way to start: make a separate list just for sensitive incidents and give it its own small group of readers. This is easier to keep track of than many items with their own permissions. Ask your IT or SharePoint admin to check the setup, because you may not have the rights to change permissions on your site.

Step 7. Start using it and review it

Tell the team where the list is, what goes in it and who may add a row. Then set a rhythm:

Each week, the lead opens the Overdue view and asks each owner for a new date or a close.
Each month, open the By type and severity view. Look for the same type or area showing up again and again.
A row closes only when the follow-up is done. Do not close a row just because the issue went quiet.

For late alerts, see "Late tasks nobody notices: setting up late alerts".

What to avoid

Too many columns. If logging takes more than a couple of minutes, people will skip it. Start small and add later.
Free text for everything. Use Choice columns for Type, Severity and Status so you can filter and count. Put number prefixes on Severity (1 High, 2 Medium, 3 Low) so it sorts in order.
No owner. A row with no owner is not being handled.
Blame words. Describe what happened and what the system allowed. Keep names of people who were involved out of the title.
Private details in the open. Keep medical and personal details out of the log. Use a short note and point to the proper record.
Relying on views to hide things. Views are not security. Use permissions.
Treating the log as the whole process. The log tracks work. It does not replace your reporting duties, your safety program or your HR process.
Never reviewing it. A log that nobody reads becomes a pile of old rows.

Not legal, safety or HR advice

This page explains how to build a tracking list in Microsoft 365. It is not legal, safety or HR advice. Your duties to record, report or keep records come from your own policy, your contracts and your regulators. Check with the right people in your organization and follow their rules.

When to get help

You can build all of this yourself in Microsoft 365. If you would rather have it built and tested for your team, I do that. A tracker like this is a fixed price: $5,000 for one, built in 2 weeks. See "What a SharePoint tracker costs". Bring one example of the problem to a free call.

Tell me what's still manual

I am Al Davies. I run 250 High Street LLC and build SharePoint trackers and Power Automate flows for operations teams. I work remotely. The first call is free, and I will not try to sell you anything.

See trackers I built: Tools I built

FAQ

Can I build an incident log in Excel instead?

You can, but a SharePoint list gives you choice columns, saved views and permissions in one place. See "SharePoint list vs Excel for team tracking: which one fits?".

Who should be the owner of a row?

One named person who will do the next step. Not a team name. The owner can hand it off later, but the column is never empty.

Should near misses go in the same list as incidents?

One way to start is yes, with a Type column that tells them apart. Near misses are often where you learn the most.

Can I hide a row from most people?

Views do not hide rows from people who can open the list. Use permissions, or a separate list with its own readers. Ask your SharePoint admin to help.

How long should I keep rows?

This page cannot say. Ask your policy owner or regulator what applies to you.