AI Knowledge Hub

How should Product and Engineering design permissions for a new feature?

Quick answer

Design feature permissions by listing the actions, resources and user contexts the feature supports, then deciding who may perform each action. Product defines legitimate user needs and exceptions; Engineering implements and tests authorisation at the trusted service boundary. Deny access by default, check each request against the relevant object and role or policy, and review how permission changes affect existing users.

What to remember

Key takeaways

Define access in terms of actions on resources, including ownership and organisation boundaries.
Separate what the interface displays from what the service authorises.
Test denied, cross-account and changed-permission cases.
Name an owner for exceptions, audit needs and later policy changes.

A new sharing, approval or administration feature often introduces access questions late in delivery. If the team only decides which buttons to show, users may still reach data or actions through an API, saved link or altered request. Permissions need to be shaped as part of feature behaviour.

Describe the access decision

List each action: view, create, edit, approve, export or delete. For each, record the resource, who owns it, user role, organisation boundary and any state that affects permission. Ask whether a person can act on their own item, another team’s item or an archived item. Product explains the intended user task and exception process; Engineering identifies data and technical boundaries. Security or privacy specialists review high-consequence cases.

Use explicit policies and trusted checks

Role-based access can be a practical starting point, but some features need ownership or resource attributes as well. Create a compact permission matrix and decide the default for combinations not listed. Enforce authorisation on every relevant server-side request and check the particular resource, not only whether the user is signed in. Keep UI visibility consistent with the policy for usability, while treating service-side enforcement as authoritative. Avoid duplicating contradictory rules across services.

Test real transitions and abuse cases

Test allowed and denied actions for each meaningful role and resource state. Include direct API calls, changed ownership, removed access, expired sessions and cross-organisation identifiers. Check what happens to existing records when permissions change. Automated tests catch known cases; security review and exploratory testing can identify missing assumptions. AI can suggest test cases from the matrix, but it must not define the policy or certify the implementation.

Operate the permission model

Record who may grant access, how exceptions are approved, what is logged and how inappropriate access is revoked. Limit stored sensitive data to what the feature requires and check applicable obligations with specialists. Review actual permission patterns after launch and simplify roles that create confusion. A new capability may need support guidance so staff do not bypass controls to resolve a user request.

Example

Hypothetically, a team adds approval of expense claims. Product identifies submitter, manager and finance actions, including what happens when a manager changes. Engineering defines server-side checks against the claim and current assignment, then tests direct API requests from another department. The team agrees an audited reassignment route before release.

FAQs

Is hiding a button enough to restrict an action?

No. The service must enforce the rule for every relevant request and resource.
Do we need a role for every exception?

Usually not. Model the action and context first; uncontrolled role growth can make policy difficult to maintain.
Who decides whether support staff may override access?

Product and the relevant control owners should define the business need; Engineering implements a constrained, auditable route if approved.