Skip to main content
Permissions answer what action a user is allowed to perform after the broader workspace, plan, product-area, and record-scope checks have already passed. This separation is what lets a small team share Lynka without giving every user the same level of control.

​
The access chain

When a user asks “Why can’t I do this?”, check the layers in this order:
  1. Is the workspace active?
  2. Does the current plan include the capability?
  3. Is the product area enabled for the workspace?
  4. Is the user allowed to open that product area?
  5. Is the record inside the user’s allowed scope?
  6. Does the user have the action permission?
  7. Does the backend lifecycle rule allow the action on this particular record?
A failure at any one layer can correctly block the action.

​
LeadGen

LeadGen run access is separate from ordinary Marketing visibility. A user may be able to open Marketing without being allowed to start a LeadGen run or use the workspace allowance. This means a user can potentially have broad Marketing visibility without being allowed to spend LeadGen allowance.

​
Sales

Important Sales permission examples include:
  • lead.create
  • lead.edit
  • lead.delete
  • lead.assign
  • lead.view_all
  • deal.create
  • deal.edit
  • deal.assign
  • deal.reopen_closed
  • deal.view_all
Visibility permissions such as view_all expand which records a user can see. They do not automatically grant create, edit, assignment, or close actions.

​
Agreements

Examples include:
  • quote.create
  • quote.edit
  • quote.void
  • quote.view_all
  • invoice.create
  • invoice.manage
  • invoice.post
  • invoice.view
  • invoice.view_all
Posting an Invoice is intentionally separate from simply creating or viewing one because posting can have Accounting consequences. Payment capture, posting, voiding, and refund behavior can also depend on plan entitlements and record state, not only one permission key.

​
Inventory

Inventory uses permissions around Products, Suppliers, Purchase Orders, and Goods Receipts. product.manage is one verified product example, while procurement actions use their own permission families. A finance user can have read-oriented Inventory access without receiving the same write access as an operations user.

​
Accounting

Examples include:
  • journal.create
  • journal.post
  • journal.reverse
  • journal.delete
  • bill.create
  • bill.post
  • bill.void
  • period.close
  • period.reopen
These permissions are separated because the risk is different. Viewing a Journal is not equivalent to posting it. Posting a Journal is not equivalent to reversing history. Closing a period is a higher-control action than entering a draft transaction.

​
Support

Examples include:
  • ticket.create
  • ticket.edit
  • ticket.assign
Ticket visibility, assignment, SLA controls, and automation can still depend on the user’s Support access and data scope.

​
Reports

report.view controls report access and report.export controls export actions where exposed. Financial reports can have additional finance-specific permission checks. A dashboard chart does not imply full Reports permission.

​
Teams

team.manage protects team-management actions. Access control, approvals, membership, product-area overrides, and permission administration can have additional controls in the relevant settings surfaces. Do not give team.manage to a person simply because they need to see their teammates.

​
Role defaults

The current role defaults are designed as starting patterns: Those are defaults, not a promise that every user with that label will always see the same thing. The workspace plan, enabled areas, overrides, and record scope still matter.

​
User-level overrides

A user can be an exception to the role default. Where the resolver defines it, a user-level deny can override a broader role grant. Use overrides for genuine exceptions. If every person in a role needs the same exception, change the role or access design instead of creating a pile of one-off rules.

​
When the screen and the result disagree

Lynka applies the final access decision when an action is submitted. If a button is visible but the action is refused, refresh the page and check the workspace, role, scope, and record state. If the result still does not match the access shown in the app, contact support with the affected area and action. Do not work around the refusal by changing unrelated permissions.

Roles and permissions

Design sensible defaults for a small team.

Product area access

Control which parts of Lynka a person can open.

Record scope

Control which records appear after the user enters an area.

Troubleshoot permissions

Diagnose a real blocked action.
Last modified on September 7, 2026