Product area access gets a user through the door. Action permissions decide what the user can actually do with records inside that area.
Lynka applies role permissions within the current workspace and combines them with product-area access, record scope, and record-state rules.
Why permissions are granular
The same person may need to view a record without being allowed to change its financial or lifecycle state.
Examples from the live permission model include:
Sensitive permissions to review carefully
Posting permissions create ledger consequences and should usually be limited to finance or authorized owners.
Reopen permissions change a previously final lifecycle and can alter historical reporting.
View-all permissions broaden record visibility beyond ordinary ownership or team scope.
Assign permissions let a user change who owns operational work.
Export permissions can move workspace data outside Lynka, so access should match your data policy.
Testing an access change
After changing permissions, test with the affected user account or a controlled role test. Check both navigation and the actual action. The server must reject a forbidden operation even if a stale frontend button is still visible.
After changing access, refresh the affected page before testing every surface so the new decision is displayed consistently.
Related articles
Last modified on September 7, 2026
