Let each person see only their own items in a SharePoint list

Short answer: to make people see only their own items, set the list's Read security so users have Read access only to items that they create (Microsoft's ReadSecurity value 2), or give each item its own permissions. A view filtered to the current user is not security. For access based on a column value, such as department, a Power Automate flow has to stop sharing each new item and then grant access to the right people. Both routes have limits, so plan them before you build.

The problem

You run a request list. Staff submit requests. You do not want one person to read another person's request. Maybe it is a pay question, a complaint or a private ask.

The wrong fix is a view. People add a filter on the Created By column, set it to the current user, and call it done. It looks private. It is not. The view only changes what the screen shows by default.

Why a filtered view is not security

A view is a display choice. It is not a lock. If a person has permission to read the list, they have permission to read every item in it. They can open another view, change the filter, or reach the data in other ways. A view that says "only my items" is a convenience, like sorting.

Use views to make the list easy to read. Do not use them to protect anything private. If an item must stay private, the permission must be set on the list or the item.

If you want a personal view anyway, one way to start is a view named "My items." Say plainly to your team that this view is for ease, not privacy.

Option 1. The list setting for item-level permissions

SharePoint lists have a Read security setting and a Write security setting. Microsoft's schema pages give the values.

Read security: 1 means all users have Read access to all items. 2 means users have Read access only to items that they create.
Write security: 1 means write all items. 2 means write only my items. 4 means write no items (read-only list).

A Microsoft Q&A answer from Microsoft support staff places these under Item-level Permissions in the list's Advanced settings, with the choices "Read items that were created by the user" and "Create items and edit items that were created by the user". To get there, open the list, select Settings, then List settings, then Advanced settings. Exact names may differ on your screen.

Here is what that gives you:

A requester who can only read their own items does not see the entries of other requesters.
A requester who can only write their own items cannot change other people's entries.

The Write security values have no choice for "can add, but cannot edit after." They are all items, only my items, or no items (a read-only list). If requesters should submit and then stop editing, that needs a custom permission level. Ask your admin.

Also note who is not covered. Site owners can still see all items. A Microsoft Q&A answer from Microsoft support staff says the setting applies to people with Contribute and Edit access, and that a person with Design or higher "would be able to edit all the items in the list." Microsoft says Edit can add, edit and delete lists, and that the Members group has Edit by default. So give requesters the Contribute level, not Edit, and keep the high levels for a small group of handlers.

Option 2. Per-item permissions

You can also set permissions on one item at a time. A Microsoft support page on list permissions says breaking inheritance and setting item-level permissions is not recommended, but is "a supported scenario within reasonable use". It also says to use built-in SharePoint groups or Microsoft 365 group permissions where you can, because they are easier to manage.

The page describes the steps in general terms: open the list or library settings, go to the permissions page, and stop inheriting permissions. After that, you can grant access to chosen people and remove access from others. The exact names may differ, so use the help page linked in the sources.

Know what you are taking on:

Each item with its own permissions must be managed on its own. If you change the parent later, those items do not follow.
Sharing an item with a person breaks inheritance for that item.
Removing a user or group from the parent also removes them from child items. The page says restoring them will not be possible.
When a list holds more than 100,000 items, you cannot break inheritance on the list itself.

Option 3. Let Power Automate set the permissions

Setting permissions by hand on each item does not scale. A Power Automate flow can do it when an item is created. Microsoft Learn describes three SharePoint actions for this:

Grant access to an item or a folder
Create sharing link for a file or folder
Stop sharing an item or a file

What the Learn page says about them:

To grant access or stop sharing, the flow must connect to the list with a list owner account.
Grant access to an item takes the site, the list, the item ID, the people and the permission role. You can include a message and notify the people.
It does not support granting access to external users.
Stop sharing an item removes all permissions on that item except for site owners.
Create sharing link works for files and folders in a document library. List items are not supported yet.

One way to start: when a request is created, the flow stops sharing the item, then grants access to the requester and the handlers. Microsoft's connector describes the recipients as email addresses of specific people and does not say a group works, so test a group address before you rely on it. That leaves the item visible to those people and to site owners. Test with two ordinary accounts before you trust it.

Worked example: access by Department

Row 12 in the list has Department set to Finance. Your flow runs when a row is created.

The flow uses the Stop sharing an item or a file action on Row 12. Microsoft says this removes all permissions on that item except for site owners.
The flow uses the Grant access to an item or a folder action on Row 12. It takes the site, the list, the item ID, the people and the permission role.
The people are the managers for Finance, and the role is the read or edit access they need.

Our advice, not a Microsoft rule: keep a small second list that pairs each Department with its managers, and have the flow look up the managers from it, so a change of manager does not mean editing the flow. Connect to the list with a list owner account, as Microsoft requires for these actions.

Which setting fits

Our advice, not a Microsoft rule: pick by how the access rule works.

Each person sees only what they created: the list's Read and Write security.
Access depends on a column value, such as department: a flow with Stop sharing and Grant access on each item.
A few items need special people: permissions set by hand on those items.
The whole group of items is private: a separate site with its own members.

If the setting or Grant Permissions is not there

Microsoft says that if the list or library is inheriting from the parent, you do not see Grant Permissions. Open the list's Permissions page and select Stop Inheriting Permissions first.
Microsoft's permissions page says: "When a list or library contains more than 100,000 items, you can't break permissions inheritance on the list itself."
If you cannot find Advanced settings or Item-level Permissions, ask the list owner or a site owner to check it for you.

Limits you must plan for

Microsoft's SharePoint limits page gives a number for this. The supported limit of unique permissions for items in a list or library is 50,000. The recommended general limit is 5,000. If your list will grow past 5,000 items that each have their own permissions, plan for that now.

For large lists in general, see "SharePoint list over 5,000 items: what breaks and the fix".

Steps to set it up

Create the list.
Add the columns you need: description, status, owner and due date.
Decide who handles requests. Make a group for them. This group needs to see all items.
Decide how requesters get in. Give them the Contribute level, which lets them add and edit items but not manage the list. Do not put them in the site Members group if Members have Edit. Check with your admin.
Open the list, then Settings, then List settings, then Advanced settings. Under Item-level Permissions, choose "Read items that were created by the user" and "Create items and edit items that were created by the user". Exact names may differ on your screen.
If you need requesters to submit and then stop editing, ask your admin about a custom permission level.
If your handlers must see items another way, or if you need more than the list setting gives you, add a Power Automate flow that sets permissions on each new item.
Test with two ordinary accounts. Create an item as the first one. Sign in as the second. Confirm the item is not visible. Confirm in every view and in the list search.
Test the handler account. Confirm it sees all items.
Write down who has the high permission levels. Review that list every few months.

What to avoid

Do not use a [Me] or Created By filter as your only protection. It is not security.
Do not give everyone Edit on the whole site and then hope the list setting covers it. Check what each person can do.
Do not put private items in a list that many people can manage. Owners and others with high permissions see all items.
Do not break permissions on thousands of items without a plan. The recommended general limit is 5,000.
Do not leave test accounts with extra permissions.
Do not trust one test. Test as a plain requester, a handler and an owner.

Honest limits

No setting here replaces a plan for who needs to see what. If the data is truly sensitive, ask your admin or security team whether a list is the right place. A separate site with its own members may be simpler than item-by-item rules. This guide covers lists in Microsoft 365. Names and menus change, so check the help pages in the sources before you act.

For an intake list that handlers work from, see "Help desk ticket tracker in a SharePoint list" and "Requests lost in a shared inbox: add an owner and a status". To get entries in from a form, see "Save Microsoft Forms answers to a SharePoint list".

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 to build". 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

How do I set item-level permissions based on a column value?

Use a Power Automate flow. Microsoft describes Stop sharing an item or a file, which removes all permissions on the item except for site owners, and Grant access to an item or a folder, which takes the item ID, the people and the role.

Why can't I find item-level permissions or Grant Permissions?

The item-level choices sit in the list's Advanced settings. For Grant Permissions, Microsoft says that if the list or library is inheriting from the parent, you do not see Grant Permissions. Select Stop Inheriting Permissions first. Above 100,000 items, you cannot break inheritance on the list itself.

Can Power Automate set permissions on each new item?

The flow must connect with a list owner account. Grant access to an item takes the site, the list, the item ID, the people and the role. It does not support external users.

Can I let users see only their own items?

Yes. In Advanced settings, set Read access to "Read items that were created by the user", which matches Microsoft's ReadSecurity value 2. A filtered view is not security, and site owners and people with Design or higher still see every item.

How many items can have their own permissions?

Microsoft lists a supported limit of 50,000 unique permissions per list or library, and a recommended general limit of 5,000. Plan for the lower number.