Organizations, roles and permissions

MyERPZ has three layers of access: the organization your data lives in, the roles that grant permissions, and the users assigned to those roles.

Organizations

An organization is the outermost boundary. Every record — lead, customer, project, booking, payment, document — belongs to exactly one organization, and nothing crosses that line.

This is enforced in the database, not only in application code, so a query that forgets to scope returns nothing rather than returning another organization’s data. There is more on why that distinction matters in how multi-tenant data isolation works.

Roles

Permissions attach to roles, and users are assigned roles. Permissions are never granted directly to a person.

This matters when someone changes job or leaves. With role-based access you change their role and their access follows. With per-user permissions you are relying on somebody remembering every individual grant, which is how ex-employees keep access for months.

A role controls two things:

• What actions a user can take — view, create, edit, delete, export
• Which records those actions apply to — their own, their team’s, or the whole organization

Planning your roles

Three roles cover most teams starting out:

Role	Sees	Typically can
Sales user	Records they own	Create and edit their own leads, customers and activities
Manager	Their team’s records	Everything a sales user can, across the team, plus reports
Administrator	Everything	Configure the organization, manage users and roles

Start there. Add more roles when you hit an actual case the three do not cover — not in anticipation of one.

A useful test for any proposed role: name a person who needs exactly this and nothing more. If you cannot, you do not need the role yet.

Common mistakes

Giving everyone administrator to avoid friction early on. It is quick, and it is very hard to walk back once people are used to seeing everything. Start restrictive.

Creating a role per person. That is per-user permissions wearing a costume, with all the same problems.

Forgetting export. The ability to export is the ability to take a copy of the data out of the system, where none of your controls apply. Treat it as a separate, deliberate grant.

How this applies to AI

The AI assistant operates inside the signed-in user’s permissions. It does not have its own, broader access.

The chain is: organization → user → role → permissions → data access → AI context.

In practice: if a sales user cannot open another team’s customer record, asking the assistant about that customer will not surface it either. The assistant is not a way around the permission model. Details on the security page.