Skip to main content
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.
Last modified on September 7, 2026