Roles & Permissions

How access is decided

Three things decide what someone can do in Plenix, and all three must allow it:

• Your plan decides which modules your workspace has at all. A role can never unlock a module your plan doesn't include.
• Their access role decides which modules and screens that person can use, and what they can do on each one.
• Their own exceptions, set on their employee record, override the role for that one person.

Modules, screens and actions

Access goes down two levels below the module:

• Module, for example Accounting.
• Screen, one page inside the module, taken from the menu: for example Accounting → Invoices, Accounting → Bills, Accounting → Tax Rates or Accounting → Reports. Ticketing, RMM, CRM, HR and every other module list their own screens the same way.
• Action on a screen:

Action	What it allows
View	Open and read
Create	Add new records
Edit	Change existing records, including send, close and assign
Delete	Delete or remove records
Admin	Approve, void and configure the module

Any action includes View.

For each module or screen, pick one level:

• No access: the screen is hidden from the menu and the server refuses it.
• View: read only.
• Edit: view, create, edit and delete.
• Full control: Edit plus Admin.
• Custom…: tick exactly the actions you want. For example, create and edit invoices, but never delete.

A screen follows its module unless you set it separately. That lets you give someone Bills but not Invoices: set Accounting to No access and Bills to Edit. Or give the whole of Accounting and set Reports to No access.

Where your access applies

Screen access isn't only about the menu. The same rules apply everywhere records appear:

• Pages: on every screen in every module, New / Add, Edit and Delete buttons only appear when the person has that action. For example, New Invoice appears only with Create on Invoices.
• Items inside a record: adding or removing things inside a record, such as milestones and risks on a project, notes on a disciplinary case, or time entries and requesters on a ticket, needs Edit on that record.
• Tabs on a company record follow their own screen. The Deals tab only offers New Deal to someone who can create deals, and the Tickets tab follows Ticketing.
• Dashboard widgets: a widget can only use data from screens the person can open. Someone with Bills but not Invoices can build bill widgets, but Invoices isn't offered as a data source, and a shared invoice widget tells them their access doesn't include it.
• Headline figures on the main dashboard, such as open deals, leads and contacts, only show for people who can open those screens.
• Search: global search and AI search only return records from screens the person can open.
• Reports: reports built on a screen the person can't open are hidden, and they can't run them.
• Pay figures: salary totals and averages in widgets are limited to HR Admins, HR Managers and Administrators, whatever the role grants.

The server enforces all of this, so a direct link or API call doesn't get around it.

Creating a role

1. Go to Settings → Roles & Permissions and click New Role.
2. Name it for the job, not the person: IT Engineer, Finance, Accounts Payable.
3. Set a level for each module the job needs. Open a module to set its screens one by one.
4. Save.

Editing a role changes access for everyone who has it, immediately.

Seed Default Roles adds the built-in roles: Administrator, Director, Manager, Technician, Field Engineer, VoIP Engineer, IT Engineer, Sales, Finance, HR Manager, HR Admin and Viewer. Viewer is always read-only, whatever modules it lists.

Exceptions for one person

1. Open HCM → Employees → [the person].
2. In Module Access, open a module and set a level for the module or for any of its screens.

An exception beats the role, in both directions. No access on one screen takes it away even when their role gives the whole module. Edit on one screen gives it to someone whose role doesn't include that module. The card shows how many exceptions the person has. The person needs a login account first; invite them if they don't have one.

Who can change access

• Administrators (and Plenix Super Admins) are the only people who can create or edit roles, assign a role to someone, set exceptions, or turn someone's sign-in on or off.
• HR Admins and HR Managers can edit employee records and invite people, but they can't change anyone's access.
• Everyone else, including Directors and Managers, sees people records read-only.
• These rules follow the person's actual role, not its name. A custom role called "Admin" gets no extra powers.
• Only a Super Admin can change a Super Admin's record.

Tip: Grant the minimum that lets someone do their job, then add on request. It's easier than starting broad and trimming later, and it's safer.