1
Check workspace access
The workspace must be active for an ordinary user. A locked workspace can block the whole app before role permissions matter.
2
Check plan capability
The current plan must include the product area or paid capability. Permission cannot make a capability available when the workspace is not entitled to use it.
3
Check installed product areas
The workspace must have the area enabled. An allowed plan area can still be hidden when the workspace has not installed or enabled it.
4
Check role or user area access
Role defaults and user overrides decide whether the person can enter Sales, Accounting, Reports or another area.
5
Check record scope
The record must fall inside Mine, selected user, team or workspace scope available to that user.
6
Check the action permission
The user may still need a specific permission such as create, edit, assign, post, reopen, export or manage.
Example: user sees Invoices but cannot post
The Agreements area may be available and the invoice may be visible, whileinvoice.post or the workspace posting entitlement is missing. Giving broader record scope would not fix that problem.
Example: user can edit deals but cannot see another rep’s deal
The action permission can be valid while record scope remains restricted. Check team or workspace visibility permissions such asdeal.view_all rather than changing the edit permission.
Example: Reports is missing entirely
Check the Reports entitlement and enabled product area before changingreport.view.
If the button exists but the backend rejects the action
Refresh the page and check the workspace, role, scope, and record state. Lynka applies the final access decision when the action is submitted. If the result still does not match what the screen shows, report the affected area and action to support.Permission reference
See common permission families and examples.
Record scope
Understand Mine, team and workspace visibility.
Product area access
Manage which parts of Lynka a person can enter.