Approvals inside Teams with item-level permissions

An internal request system is the simplest thing you can build and the one most often built wrong. The list goes up quickly, so does the form, and then permissions sink the project.

The real requirement

An employee submits and sees only their own requests. A manager sees their team's. HR sees everything.

The common mistake

Breaking permission inheritance per item. It holds up for the first month. Then the list grows to thousands of items, each carrying its own permissions, auditing becomes impossible, and performance degrades.

What I do instead

Item-level permission comes from the list's own settings: the setting that limits each user to reading and editing what they created. One switch that lives in one place.

Sensitive information gets its own list or site with clear permissions, which spares the main list from broken permissions across thousands of items.

The approval flow

The employee submits from inside Teams without opening another system. The request goes to a role, not to a named person, otherwise the whole thing stalls the moment that person travels.

The manager decides in one click, and the decision lands on the row itself: who approved and when.

The trap

Do not let the form write using only the user's permission. Some steps need higher rights, such as notifying another department. The fix is a flow that runs under a service identity with a defined scope rather than under the employee's identity.

The signal that the system succeeded

Requests stop arriving in chat. As long as someone is sending their request in a conversation, the system has not been adopted, and the usual reason is friction: submitting costs more effort than a quick message. Missing features are rarely the cause.

Related reading