Roles and permissions

Five people need the Leads list and only two of them should see everybody’s leads. The storeman who writes off damaged stock should not be the one who posts the write-off. Your accountant needs every invoice in the business and none of the payroll. Those are the same question asked three times: who may open a screen, what they may do on it, and whose records they see. A role is where you answer it.

What a role is

A role is a named list of grants. One grant covers one screen — crm.lead, sales.invoice, inventory.adjustment — and says two separate things about it: which actions are allowed, and which records those actions reach. Roles live at Settings › Roles & permissions.

A person can hold more than one role. There is no primary role and no ranking between them: every role somebody holds is read on every request and the results are added together. A person with no role holds nothing, and every screen refuses them.

A person’s record in Settings › Users also carries a Permissions tab: what that one person may do when they have no role. A role replaces it entirely. Roles are the tool; the procedure for a person’s own permissions is further down.

Opening the screen

app.jaicrm.ai

1. Go to Settings › Roles & permissions. Opening it needs Roles & permissions: View.
2. The Roles tab lists every role as a card with the number of people on it, a Preset badge where the role ships with the product, and a Portal badge on the two outside logins.
3. Click Open on a card for the role dialog: name, description, Reports to, Share data with peers, Portal role, the permission grid, and the warehouse restriction.
4. New role needs Roles & permissions: Create. Saving an existing one needs Edit. The Data sharing settings tab opens on View; changing an organisation-wide default or writing a sharing rule there needs Manage.
5. The other three tabs are Organisation tree, which draws the reporting chart, Who can do what, which lays every role out against every screen, and Data sharing settings, which holds the organisation-wide defaults and the sharing rules.

The "Who can do what" tab

app.jaicrm.ai

This is the tab that answers the question people actually ask. Every role is a column, every screen in the modules your plan includes is a row, and each cell says how many actions that role holds there and at what scope — a dash where it holds none. It is the one view that answers “who can delete an invoice?” without opening five roles one at a time. Each cell is worked out the way a request is, so a module-wide row and a Manage tick read as access rather than as a dash. The two portal roles are left out: the columns are your staff roles, in the order the Roles tab lists them.

The permission grid

app.jaicrm.ai

The grid lists every module in the product. Click a module name to expand it and you get one row per screen inside it. Each row is one grant.

• Four tick boxes are shown by default: View, Create, Edit, Delete.
• Show every action at the top reveals the rest — Export, Import, Approve, Share, Print, Convert and Manage — on the rows that offer them.
• All access at the end of a row ticks every action that row offers. All access on the module heading does the same to every row inside it, and writes a module-wide row of its own as well — which is worth knowing about, and is the last note on this page.
• A dropdown appears at the end of a row as soon as one action is ticked. That is the data scope, and it is a separate question — see below.

What each action means

What "manage" actually confers

Manage is the configuration action: creating a GST return record, setting a transaction lock, connecting Shopify or IndiaMART, adding or removing a branch, editing a sharing rule, setting one person’s permission overrides. It appears only on the rows where there is something to configure — the settings screens, the per-module preference rows, GST summary, transaction locking, the integration setup pages. Changing the business profile itself is not on that list: the name, the address, the GSTIN and the rest ask for Business profile: Edit. What asks for Manage on that row is adding or removing a branch, and the handful of organisation-wide settings stored alongside the profile — one of which is in the organisation tree section below.

Each integration has its own set-up permission on a role, such as IndiaMART setup or Tally set-up. Anybody holding at least one of them sees Settings › Integrations, where all six integrations are set up.

The part people get wrong: holding Manage on a row turns on every other action on that row. The permission check is written that way in both the API and the browser — if the grant carries Manage, every question asked about that row is answered yes. Ticking Manage on Settings › Users and leaving View, Create, Edit and Delete clear gives that person all four anyway. It also counts as holding everything for the “you can only give away what you hold” check further down.

So Manage is the widest tick in the grid, not a niche one. Tick it when you mean “this person runs this area”, not when you mean “this person may change a setting”.

What "approve" actually confers

Approve means two different things depending on where you tick it, and only one of them is what the word suggests.

On the modules where an act is the sign-off, Approve is the gate on that act. Posting a stock adjustment asks for it. Dispatching a stock transfer, receiving one and closing one short all ask for it. Confirming and releasing a manufacturing order ask for it, because committing materials and machine time to a job is a sign-off, not a correction. Posting a manual journal, paying a payroll run, approving or blocking a vendor, approving a timesheet, sending from the notification queue, issuing a debit note: all of them. So does approving an expense in Books: Approve sits beside Pay on an expense that is still owed, and the person who recorded it is told. A purchase bill is one record: it is listed under Procurement, Purchase bills, and under Books, Purchase bills only for a business without Procurement, and either way it is the same list under the Purchase bills permission. Somebody without Approve on those rows can raise the document and cannot commit it.

On the eight sales document types, Approve gates nothing about sending, and it does not decide who may rule on an approval either. Sending a quotation or an invoice asks for Edit, deliberately: gating it on Approve would read as a tighter control and work as “Sales cannot sell”. What Approve does on those rows is let somebody read the approvals queue — a request comes back to whoever raised it, to whoever the waiting step names, and to anybody holding Approve on that module. Reading the queue is the whole of it.

The four data scopes

The dropdown at the end of each row answers a different question from the tick boxes. The tick boxes say what; the scope says whose. There are four values. Three are in the dropdown; the fourth is what a row with nothing ticked resolves to.

Nothing

There is no “Nothing” option in the dropdown because clearing every tick box is how you say it — the row disappears from the role’s grant map. Give the Warehouse assistant role nothing on Leads and Vikram Joshi’s sidebar has no Leads row; typing the address by hand returns “You do not have permission to view leads”.

Their own records

This is the default on every new grant. Somebody sees a record when any one of these is true: they own it; they created it; their name is in Assigned to; their name is in Mark to; somebody in a role that reports to theirs owns it; a peer on a role that shares sideways owns it; a sharing rule reaches them; or the module’s organisation-wide default is set to anything but Private.

Worked example. Rakesh Meena at Shree Balaji Traders, Jaipur, holds Sales executive. Leads is set to Their own records. He opens Leads and sees his own 42, plus the 3 Priya assigned him, plus 1 she marked him on. Sunita Khandelwal’s 51 leads are not on the list and searching for one by name returns nothing. The lead he was only marked on he can read and cannot change — being copied in is not being given the record.

“Their own” falls back to whoever entered the record wherever there is no owner, and that is a general rule rather than a short list of exceptions. Items, Expenses and Payments are named in the code because their answer is the creator even though an owner column might be expected; everywhere else the server looks for an owner column, then for a creator column, and narrows by whichever it finds first. So journals, stock movements, transfers, goods receipts, packages, assemblies, bills of materials and quality inspections are all narrowed by whoever entered them.

Their team's records

Everything above, plus every record owned by anybody who shares a circle with them (Settings › Circles). Circles only — a group is a project roster and may hold a client contact or a supplier, and being named on the same project is not a reporting line.

Worked example. Priya Nair holds Manager, set to Their team’s records. In the shipped tree, Sales executive, Accounts, Stores & inventory, Quality, Production and Read only all report to Manager, so she sees the leads, quotations, expenses and stock adjustments owned by everyone holding any of those — Rakesh’s 42 and Sunita’s 51 both. She is also in the circle “Jaipur desk” with Anil Sharma, who holds Accountant, a role that reports to Administrator and not to hers. Because they share a circle, his journals appear on her list too. Adding somebody to a circle widens what every other member of that circle sees.

Everything in the business

Every record in the module, whoever raised it, with no ownership test run at all.

Worked example. Meena Agarwal holds Accounts, whose Invoices row is set to Everything in the business. She sees all 1,180 invoices — ₹4.62 crore of them — Jaipur and Udaipur, including the ones Rakesh’s quotations became. That is the right setting for a bookkeeping job: an invoice register narrowed by who typed it is not a register.

Two of those three can be narrowed the other way instead. Warehouses and work centres both record a place, so they can be ticked under the warehouse restriction further down this page. Job cards can be narrowed neither way: no owner, no creator, no warehouse and no branch, so everybody holding the grant sees all of them.

Scope and actions are separate questions

Nothing in the grid pairs an action with a scope. One scope governs every action ticked on that row.

Give Rakesh Delete on Tasks at Their own records and he deletes what that scope reaches: his own tasks, the ones he created, the ones he is assigned, and anything owned by somebody on a role beneath his. Not “his own and nobody else’s” — a task his manager assigns him is a task he can delete, and it was never his. Being marked on one is the exception: Mark to grants reading and stops there. Change only the dropdown to Everything in the business and the same tick box deletes anybody’s task in the company. The reverse holds too: Everything in the business with only View ticked lets somebody read all 1,180 invoices and change none of them. Both halves are checked, separately, on every request — the action at the door, the scope on the record.

How two roles combine: the wider wins

When somebody holds two roles, each row is merged like this: the actions are added together, and the widest scope is kept. The two halves are merged independently. The scope that came from one role attaches to the actions that came from the other.

Worked example. Rakesh holds Sales executive, which grants Leads: View, Create, Edit, Import and Convert at Their own records. You want him to see the rest of the desk’s pipeline, so you add a second role, “Jaipur desk lead”, granting Leads — View, Export at Their team’s records. You have granted reading twice and writing once.

What he actually holds is View, Create, Edit and Export at Their team’s records. He can now edit and reassign every lead the desk owns, including Sunita’s 51. Neither role said that. The role that gave Edit said “their own”; the role that gave “team” said view only. Merging does not keep them paired.

What to do instead. Leave him on one role and write a sharing rule in Data sharing settings › Sharing rules from Sunita’s role to his, set to Read Only. A rule grants reading without granting writing, and the product holds the line: opening one of her leads works, changing it answers “You can see this lead but not change it — it is shared with you for reading.”

Two more merge rules worth knowing. Field-level restrictions work the opposite way round — a field is hidden only if every one of the person’s grants hides it, and read-only only if every grant makes it read-only, so one permissive role shows the field. And a person’s own overrides from Settings › Users are merged on top in the same way.

One person's own permissions

Since 3 October 2026 the rule is simple, in every business: a role replaces a person’s own permissions. Somebody with one or more roles gets exactly what those roles give, nothing more and nothing less. Somebody with no role gets exactly their own permissions. Ticking or unticking a role never changes or deletes their own permissions: they are kept, and apply again the moment the last role is removed.

1. Go to Settings › Users, open the person, and choose the Permissions tab. It is there while you are inviting somebody too.
2. Tick what this person may do and save. It is a plain grid of their own, the same as on a role, with nothing from any role mixed in.
3. If a role is ticked on the Details tab, an amber note says Not in use: this person has a role. What you set is kept for later and applies only if every role is removed.

The roles that ship with the product

Twelve preset roles are created with every business, already arranged into a reporting tree. The tree is not decoration: “Their team’s records” reads it, so a manager with nothing beneath them would see only their own work.

Each of these earns a sentence, because several are not what their name suggests.

• Manager is “team”, not “everything”. Two managers of two desks see nothing of each other’s work, because neither reports to the other. A senior manager above both sees both. Where two managers should see each other, say so deliberately — tick Share data with peers on a shared role, or write a sharing rule between the two roles.
• Manager keeps View on Users and Circles at Everything in the business, so somebody arranging cover can find a name outside their own desk. That grant reads names, not records.
• Accounts is “Everything in the business” on purpose. A bookkeeping job has no owner to narrow by. It does not carry payroll or the employee list.
• Accountant has no payroll and no employee list either, deliberately: somebody who files GST has no business reading everybody’s CTC and PAN.
• Salaries are the Administrator’s alone. No other preset opens Payroll or the employee register, Manager and Read only included. Give them to somebody by ticking them on that person’s role.
• Sales executive cannot export or delete. It converts and imports leads, and imports customers and companies, but a list of leads leaving the business in a spreadsheet is the leak most owners worry about, so Export is left for the roles above it.
• Stores raises adjustments and cannot post them. The role has View, Create and Export on Adjustments and not Approve — a write-off signed off by the person who wrote it is not a control. Somebody with Approve has to post it.
• Quality reads the rules and cannot edit them. Activating a quality rule — the act that makes it gate production — asks for Edit on Quality rules, so withholding it genuinely stops an inspector switching off their own gate.
• Production moves stock while holding only View on it. Starting a works order consumes components, completing one produces finished goods and cancelling returns them; all three ask for Edit on Manufacturing orders and no inventory permission at all. That is the module’s design. If you do not want this role moving stock, do not give it Manufacturing orders.
• Production holds Approve on manufacturing orders, because confirming and releasing ask for it. A junior operator role can be given the rest of that list without it.
• The two portal roles have no superior on purpose. Putting a customer into the staff tree would make them somebody’s subordinate, and therefore reachable by whoever sits above them. They are also left off the organisation chart altogether and out of every Reports to list, so you will not find them there to move.

Where customers and vendors sign in

The two portal roles are for outside logins. Give one in Settings, Users, Invite user: set Kind to Customer portal or Vendor portal, choose their customer or vendor record, and send the invitation. They set a password from the email and sign in at app.jaicrm.ai/login, the same page as your staff, and go straight to their portal at app.jaicrm.ai/portal. A portal login reaches its portal and the files you share with it, and nothing else.

The portal has a tab for each thing it shows: Overview, Documents, Statement, Files (what you shared with them in Documents) and, for a customer, Projects (their own projects, to read). Files appears only while their role holds Documents: View, and Projects only while it holds Projects: View, so taking either off the Customer portal role takes the tab away. On a phone the tabs sit in a bar along the bottom of the screen.

A preset is yours to change

Open a role with the Preset badge and the dialog says: “This role ships with the product. Change what it grants here and it changes for everybody on it.” Its permission grid and its warehouse restriction change like any other role’s, for anybody with Roles & permissions: Edit, and the change reaches everybody on the role when you save.

Two things stay as they ship. The Portal role tick is locked, because it decides whether the role is an outside login at all. And a preset cannot be deleted: there is no Delete button, and the API refuses with “Manager ships with the product and cannot be deleted. Change what it may do instead, or make a copy.”

A change you make to a preset stays made. Each release tops the presets up with anything new that ships with them, such as a new screen, and it only ever adds what the role does not mention at all. A screen you untick is saved as no access rather than left out, so the next release leaves it off.

Put back as it ships, in the same line, fills the grid and the warehouse restriction with what the role ships with. Nothing changes until you press Save, so you can look and then Cancel. On Administrator the line adds that the business owner keeps full access whatever the role says: the owner’s access never comes from a role, so changing Administrator cannot lock the business out of its own settings. It does change what everybody else on Administrator may do.

Everything else on a preset is yours as well: its name, its description, its Reports to, and Share data with peers. Rename Manager to “Area sales manager” and move it under whatever you like.

Copying a role

Copy a role when some of the people on it need something different from the rest. Change the copy and give it to them; the original stays as it is for everybody else.

1. On the Roles tab, click the copy icon on the preset’s card. You need Roles & permissions: Create.
2. A new role appears called Manager (copy), with the same permission grid, description, portal flag, Reports to, Share data with peers and warehouse limit, and no Preset badge.
3. Open it, rename it, change the grid, and save.

Who may change a role

Anybody with Roles & permissions: Edit may change a role, and may add to it only what they hold themselves: a tick they do not have, or a wider reach than their own, is refused with the list of what they lack. That holds on every role, their own included, so the right to edit roles is not a way to give yourself more. Renaming a role, taking something away, or saving a role that already holds more than you is never refused. Somebody confined to their own warehouses or branches cannot lift that limit from a role either. The business owner is never limited, and Administrator as it ships holds every tick, so its holders may add anything.

The organisation tree

Every role has a Reports to. The Organisation tree tab draws the result, with the business at the root, the number of people on each role, and a Peers badge on the roles that share sideways.

• Reach runs down only. Everybody above somebody in the chart reads their records. Nobody reads upwards, and nobody reads sideways.
• Two people on the same role are strangers to each other unless Share data with peers is ticked on that role.
• A role left without a superior sits at the top. A role created from New role without one is placed under the top role automatically, and a copy reports to whoever the original reports to.
• The two portal roles are not on the chart at all. They are filtered out on purpose, so “a role left without a superior sits at the top” is true of every role but those two, which are not there to sit anywhere.
• A role cannot report to itself, or to anything already beneath it. The save refuses with “That role already reports to this one, so this would make a loop”.
• A role cannot be deleted while anybody holds it or while another role reports to it. The delete refuses and names what is in the way, so the chart cannot be broken from underneath.

Above the chart sits one setting that decides what reaching down actually permits: What a superior may do to a subordinate’s records, either Edit and delete them (the default, and what the product has always done) or Edit them, but not delete. Reading is not on the menu — everyone above somebody reads their records either way. Changing it needs Business profile: Manage. The dropdown is offered to anybody with Edit and the save then refuses them with “You do not have permission to manage business profile”, so give whoever sets this Manage on that row — remembering that Manage there turns on every other action on it.

Restricting a role to particular warehouses

Ownership cannot express “the Sanganer store and not the other four” — a stock balance belongs to a place, not to a person. So there is a second narrowing, set in two halves that must both hold.

1. On the role, under Restrict to the person’s own warehouses, tick the modules to narrow. Only modules whose records carry a warehouse or a branch are offered: the server works that list out from the schema and sends it with the roles, so the screen cannot offer you a module the lists could never honour. Saving one anyway is refused when you edit an existing role. Creating a role does not run that check, so an integration posting a new role can write a module that narrows nothing.
2. On each person, in Settings › Users, tick which warehouses and branches they hold. A branch brings its warehouses with it, so you do not tick both.

Worked example. Vikram Joshi holds Stores & inventory, whose scope is Everything in the business. You tick Stock movements, Transfers, Goods receipts and Packages on the role, and give Vikram the Jaipur and Sanganer warehouses on his record. He now sees stock, transfers, receipts and packages in those two sites and nothing from Udaipur — even though his scope still says Everything in the business. The two narrowings are AND-ed: a record has to pass both.

• It applies on top of the data scope, not instead of it.
• Somebody with no warehouses ticked is not restricted to none — they are simply not restricted.
• A transfer is matched on either end, so the in-charge at the sending site and the one at the receiving site both see it.
• A record with no place recorded on it stays visible, so a draft nobody has filed yet does not strand whoever is writing it.

You can only give away what you hold

The check runs when a role is put on a person, not when the role is written. If the role includes anything the person doing the assigning does not hold — an action, or a wider scope on an action they do hold — the save is refused and names what exceeded: “You cannot give somebody the Administrator role, because it includes things you do not have yourself: settings.user: manage, settings.role: manage …”

• The Roles list on somebody’s user record only offers the roles you could hold yourself. A role already on that person stays visible whoever is looking, so saving an unrelated change does not silently strip it.
• The same rule covers places: somebody confined to two warehouses may staff those two; somebody nobody has confined may grant any of them. Branches work identically.
• Holding Manage on a row counts as holding every action on it for this check, as everywhere else.
• The account owner and an administrator hold everything, so nothing changes for them.
• The last Administrator cannot be demoted, by themselves or by anybody else: “This is the last administrator. Give somebody else the Administrator role first.”

What changes the moment you save

• Everybody holding the role is affected on their next request. Saving a role clears the server’s permission cache, so nobody has to sign out and in.
• An entry is written to Settings › Audit log of type permission change, reading “Changed the role Manager”, carrying the whole grant map before and after.
• The sidebar is built from permissions, so modules with no grant stop being in the menu the server hands out.
• Approval rules that route to “whoever they report to” follow the tree immediately, because they resolve the role’s superior on each request rather than storing a name.
• Sharing rules that name a role start reading the new membership at once — a new joiner in that role is covered without editing the rule.

What it will not do

• It changes nothing retrospectively. Somebody who loses Delete keeps the records they already deleted deleted, and the audit log keeps their name on them.
• It does not move records. Narrowing somebody from Everything in the business to Their own records does not change who owns anything; the records stay where they are and stop appearing on that person’s list.
• It does not reach the account owner. The owner holds every action at Everything in the business by definition and cannot be restricted by a role.
• It does not switch a module on. Modules your plan does not include are stripped after everything else is worked out, so ticking one grants nothing until the module is on the plan.
• It does not override the organisation default. Data sharing only ever widens. Narrowing a role cannot take back what Public (Read Only) gave everybody.
• It does not control fields. The grid has no per-field control; which fields appear on a form is set in Fields & rules.
• The person’s own screen does not redraw. The browser loads the permission map once per page load, so somebody signed in keeps the sidebar and the buttons they had until they reload. The server enforces the new rules immediately either way — the buttons are there and refuse.

The one that catches people out