← Al Davies, 250 High Street

Change request log in a SharePoint list

Short answer: keep one SharePoint list where every change request gets one row. Each row says who asked, what they want, how big the impact is, where the request stands, who decides, when it was decided and when the change is planned. Add a few saved views so pending requests, approved changes and late changes are each one click away. This is a tracking log. It does not replace your own change policy.

What a change request log is

A change request is a formal ask to change something that already exists. It might be a process, a system setting, a contract term, a price list or a project plan. A change request log is the shared record of those asks. It shows what was asked, what was decided and what is going to happen next.

Without a log, requests live in email threads and meeting notes. Nobody can say how many are waiting. Nobody can say who approved the last one. A single list fixes that. Everyone looks at the same rows.

This guide is about requests to change something and the decision on each one. For project risks and issues, see "RAID log in a SharePoint list: risks, actions, issues, decisions". For events that happened in operations, see "How to set up an incident log in SharePoint". If sign-offs get buried in inboxes, see "Approvals lost in email: how to stop chasing sign-offs". For a record of who approved what, see "Keep an audit trail of every approval".

Step 1. Plan the columns

Write these on paper first. Eight columns is enough to start.

  1. Title: a short label, such as "Add a second approver to purchase orders".
  2. Requested by: a Person column.
  3. Description: what should change and why. Longer text.
  4. Impact: Choice. 1 Low, 2 Medium, 3 High.
  5. Status: Choice. 1 Submitted, 2 Approved, 3 Rejected, 4 Done.
  6. Approver: a Person column.
  7. Decision date: a Date column.
  8. Planned date: a Date column. The day the change should happen.

The Title column is there by default and it is required by default. You can rename it, for example to "Request", or turn off Require in the column settings. One way to start is to keep it as the short label and make people fill it in.

Why numbers in front of the choices? When you sort a view by a Choice column, it sorts by the text. With a number in front, 1 Low sorts before 2 Medium and 3 High, and 1 Submitted sorts before 4 Done. One way to start is to number every Choice you plan to sort by.

Step 2. Create the list

Microsoft says you can start with a blank list. In the Lists app, select +New list, then the Blank list tile. On a SharePoint site, use New, then List, then Blank list. Give the list a name, such as "Change requests", and select Create. Exact names may differ on your screen. Microsoft says a blank list opens with a standard Title column on the left and no other columns. See Microsoft's help page "Create a list" in the sources below.

Step 3. Add the columns

Microsoft describes adding a column like this: select + Add column, pick the column type, enter a name, fill in the settings and select Save. The settings you see depend on the column type. Exact names may differ.

Write one line of meaning for each Impact level, so people pick the same way. For example: 1 Low means no one outside the team notices. 2 Medium means other teams must adjust. 3 High means customers or money are affected. These are example words only. Use your own.

Step 4. Add a few sample rows

Add three rows before you share the list. Mark them as tests and delete them later.

Read the rows as if you did not write them. If a column is hard to fill in, simplify it now. A log that is hard to update does not get updated.

Step 5. Make the first views

A view is a saved way to show the same list. A view does not change the rows themselves. In the modern experience, you sort, filter or group from the column headers, open the view options, choose Save view as, enter a name and select Save. Microsoft says saved views also keep the columns you show or hide.

  1. Pending. Filter Status to 1 Submitted. Sort by Impact. Save the view as "Pending".
  2. Approved, not done. Filter Status to 2 Approved. Save the view as "Approved".
  3. Rejected. Filter Status to 3 Rejected. Keep it for history. Save the view as "Rejected".
  4. All by status. Group by Status. This is the view for the monthly review.

Microsoft says a view can have up to two sort criteria, such as Impact and then Planned date. In the classic experience, Microsoft describes a personal view that only you can see and a public view that everyone who uses the list can see. Make the views above public if you can, so everyone sees the same thing.

Step 6. Build the Past planned date view in the classic view editor

This view shows approved changes that are late: Status is 2 Approved and Planned date is before today. It uses [Today], so it needs the classic view editor.

Microsoft says it is not possible to use the [Today] or [Me] filters when filtering from a column header. To use them, open the classic view editor:

  1. Select the view name, then Edit current view.
  2. In the Filters section, select "Show items only when the following is true."
  3. Add: Status is equal to 2 Approved.
  4. Add: Planned date is less than [Today]. This finds approved changes whose planned date has passed and that are still marked 2 Approved, not 4 Done.
  5. Select OK, then save the view under the name "Past planned date".

Microsoft says [Today] works on date-based columns. It also says you can have up to 10 statements in a filter and that Or statements go before And statements.

One more limit: a calculated column cannot use today's date, because SharePoint blocks [Today] in formulas. So do not try to make an "Overdue" column. Use a view filter instead.

For a "Mine to decide" view, filter Approver is equal to [Me] and Status is equal to 1 Submitted. [Me] is also a classic view editor filter. Microsoft says [Me] works on people-based columns.

Views are not security. Anyone who can open the list can switch views and see every row. If some requests must stay private, use a separate list with its own permissions, or check with your admin.

Step 7. Add approvals with Power Automate

You can run the log by hand. The approver opens the row, changes Status to 2 Approved or 3 Rejected, and types the Decision date. That works for a small team.

If you want the approver to get a request and answer it from email or Teams, Power Automate has an approvals feature. Microsoft says that when you submit an approval in a flow, approvers are notified and can review and act on the request. It also says that when a new item is added to a list, a flow can start an approval to have someone review the item. That matches this log: a new row with Status 1 Submitted can start a request.

Microsoft lists these approval types: Approve/Reject where everyone must approve, Approve/Reject where the first to respond decides, Custom Responses, and Sequential approval, where approvers answer one at a time in order. One way to start is Approve/Reject with the first to respond, and one Approver per row.

Microsoft says approvers can respond from an Outlook email, a Microsoft Teams adaptive card or the Power Automate action center, if they have a Power Automate license or a qualifying Office 365 or Dynamics 365 license. Licenses differ by plan. Check with your admin.

This guide does not walk through building the flow. After the decision, the flow can write the result back to the row: Status, Approver and Decision date. For how to set that up, see "Approvals lost in email: how to stop chasing sign-offs".

Step 8. Run a short weekly review

A log only works if it is read. One way to start:

  1. Open Pending. Ask each approver: yes, no, or need more information.
  2. Open Approved. Check that every row has a Planned date.
  3. Open the Past planned date view. Ask who owns each change and whether it is on track.
  4. Set Status to 4 Done when the change has really happened.
  5. Leave Rejected rows alone. They are your history.

For reminders about dates, see "Send a reminder before a due date in a SharePoint list" and "Late tasks nobody notices: setting up late alerts".

What to avoid

Honest limits

A list does not run your change process. It shows what was asked and decided. Impact is an opinion, so two people may rate the same request differently. Agree on what High means before you start. If you must keep a full history of every edit to a row, a list alone may not be enough. See "Keep an audit trail of every approval". Menus and names in Microsoft 365 change, so check your own screen.

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

What columns does a change request log need?

One way to start is eight: Title, Requested by, Description, Impact, Status, Approver, Decision date and Planned date. Add more only when you miss them.

Why can I not use [Today] when I filter from a column heading?

Microsoft says [Today] and [Me] do not work from a column header. Use the classic view editor: select the view name, choose Edit current view, then go to Filters.

Can I make a column that shows overdue changes?

Not with a calculated column. SharePoint blocks [Today] in formulas. Use a view filter with [Today] in the classic view editor.

Do I need Power Automate for approvals?

No. The approver can change Status by hand. Power Automate adds a request the approver can answer from email or Teams. Check your license with your admin.

Can I hide some requests from most people with a view?

No. Views are not security. Keep private requests in a separate list with its own permissions, or check with your admin.

Sources