Setup Roles & Permissions

Permissions in eFirm answer two separate questions: what a person can do, and which records they can do it to. Both are set on the role, not on the person, at Firm › Teams & Members › Roles & Permissions.

Roles, not people

Two roles are built in — SUPER ADMIN and User — and the rest are the firm's own. Create one with + Add Role. Most firms end up with Partner, Associate and Paralegal, because those match how they already work; a role is meant to describe a job, not an individual.

Permissions attach to roles, not to people. Change the role and everyone holding it changes with it. That is the whole reason to spend twenty minutes getting the role set right rather than editing members one at a time — and it is also why an administrator testing a restriction on their own account usually concludes, wrongly, that it does not work.

The permission matrix

Each role is granted module by module, with a different set of verbs per module. An associate can have full run of matters and tasks while seeing nothing in Financial beyond a read-only view.

Export is a separate verb from View for a reason: reading a client list on screen and walking out with it as a spreadsheet are different acts, and a firm can permit the first without the second.

Record scope: who sees which records

The matrix above decides what a role can do. A second setting, on the same screen, decides which records it can do it to. The two combine: a role can hold Edit on Legal Matters and still only ever reach its own matters.

Scope is set per module, not per person, so one role can be firm-wide on Calendar and On records on Financial. Set it on the role, then apply it to the group that role belongs to — you are not editing people one at a time.

Worked example: associates should not see each other's time

A firm bills by the hour and does not want associates comparing timesheets, or seeing what the partners logged. Open Roles & Permissions, select the role the associates hold, find the Timesheet module and set its scope to On records. Save with Update role.

Each associate now opens the timesheet list and sees only entries assigned to them. Partners on a Full access role still see everything, and firm-wide reports are unaffected — the restriction is on what a person can reach, not on what the firm can measure.

Hiding individual fields

Scope controls which records a role reaches. Field visibility goes one level finer and controls which columns it sees inside them. The clearest case is money: monetary amounts on the Chart of Accounts can be hidden for a role, at Firm › Settings › Roles & Permissions › Chart of Accounts, so the role can still navigate the account structure and file against the right account without seeing the firm's balances.

Firm-wide visibility, and where it is set instead

Two visibility settings are deliberately not on this screen, because they apply to the whole workspace rather than to a role: Calendar View Permission (Restrictive, meaning role-based, or Permissive, meaning everyone sees every calendar) and Task View Permission. Both live at Firm › Edit Workspaceand are covered in Settings and Customizations. If a role looks correctly restricted and a calendar is still visible to everyone, that pair of toggles is why.

Seats

A HAQQ subscription includes a set number of seats, and each active team member uses one. Current usage is visible in the account administration panel — 25 used out of 50 available, for instance — and seats are added from the subscription management panel. See Manage subscription.

Scaling for a mandate. A firm that wins a large mandate and needs five contract lawyers for three months adds five seats, creates a Contract Lawyer role limited to assigned matters with no financial access, and invites the five against it. The team is working the same day. When the mandate ends, removing them frees the seats and leaves their work on the file.

Troubleshooting

What this model does and does not cover

Roles, record scope, field hiding and seats are the access controls a firm administrator configures. They are enforced on the routes themselves, so a member only reaches what their role allows rather than merely not seeing a menu item. Two things sit outside them:

• Per-document access. A single file can be restricted to the matter team, and download permissions control who can take it out of the system. That is set on the document, not on the role — see Documents.
• Workspace isolation. Nothing on this page crosses a workspace boundary. A role grants access inside one workspace only; separating data between entities is a workspace decision, not a permissions one. See Data Architecture.