A 60-person consulting firm we spoke with last year had exactly one permission level in its CRM: full access, for everyone. A contractor brought in for a three-week engagement with one client could open every other client's contract terms, retainer pricing, and internal margin notes. Nobody decided that on purpose. It was just the default setting nobody had gotten around to changing, and it stayed that way for four years and two acquisitions. That is the normal state of most agencies and consulting shops, not the exception. Role-based permissions fix it, but only if you build actual roles instead of bolting on one-off exceptions every time someone complains.
In this guide
What a flat permission model actually costs you Build roles, not a pile of one-off exceptions The situations that break most permission setups Rolling this out without breaking how people work Frequently asked questions
What a Flat Permission Model Actually Costs You
Nobody sets out to give a junior consultant read access to every client's invoice history. It happens because setting up individual permissions felt like extra work in month one, and by month eighteen there are 40 people, three tools, and no one left who remembers what access was supposed to look like. The risk isn't theoretical. Client MSAs increasingly include named clauses about who inside your firm can view their financial data, their contracts, or their proprietary project files, and "our whole delivery team, by default" is not an answer that satisfies a procurement or legal reviewer at a mid-size enterprise client.
There's also a quieter cost: internal trust. When a project manager can see the margin on a deal she wasn't staffed on, or a support rep can browse contract terms for accounts she has never touched, people start treating the system as a place where nothing is actually private. That erodes the discipline you need for accurate time entry and honest status reporting, because if the data isn't protected, why would anyone protect it. A permission model isn't just a security control, it's what makes the rest of the system trustworthy enough to use consistently. Autovella's permissions and access controls are built around this exact idea, restricting by role and by client record rather than an all-or-nothing switch.
Build Roles, Not a Pile of One-Off Exceptions
The mistake most firms make isn't skipping permissions entirely, it's building them reactively. Someone asks for access to one report, IT grants it, and six months later there are 30 individual permission overrides that nobody can explain. Start from the job function, not the org chart, and define a small number of roles before you ever touch a settings screen.
- Owner/Admin, full visibility across every client, project, and invoice, reserved for founders and a handful of ops leads, not "anyone senior enough to ask"
- Delivery Lead, full access to the accounts and projects they run, including margin and rate data, but nothing outside their book of business
- Consultant, can log time, see project scope and files for engagements they're staffed on, no visibility into pricing, margin, or client accounts they aren't assigned to
- Contractor, everything a consultant has, scoped to a single named client or project, with an access window tied to the contract end date
- Finance/Billing, full visibility into invoices, rates, and payment status across all clients, no access to delivery notes, internal chat, or project files
- Client Portal, the client themselves, sees only their own project status, files, and invoices, nothing about your internal margin, staffing, or other clients
Six roles cover a surprisingly wide range of firm sizes, from a 15-person shop to a 200-person consultancy. The number of roles doesn't need to scale linearly with headcount, what scales is how many people sit in the Consultant and Contractor tiers.
The Situations That Break Most Permission Setups
The role list above handles 80% of your team on day one. The other 20% is where permission models actually fail, usually in three specific ways.
First, cross-staffing. A consultant staffed on two accounts at once needs access to both, and only both. If your system only supports a single flat role rather than per-account or per-project scoping, you end up granting broader access "just to make it work," which quietly undoes everything the role structure was supposed to prevent. Second, subcontractors who work through an agency rather than directly for you. They need the same time-limited, single-client access as a direct contractor, but often get forgotten because they're not in your HR system at all. Third, and by far the most common failure, is offboarding lag. An employee leaves on a Friday, and their login still works the following Wednesday because deactivating access wasn't part of the actual offboarding checklist, it was something IT was supposed to "get to."
Offboarding lag is the single biggest source of unnecessary exposure we see. It has nothing to do with malicious intent and everything to do with process. If revoking access isn't a mandatory, checked step in your offboarding flow, tied to the same date as the final paycheck, assume someone left the building with a live login three months ago and nobody has checked since.
The fix for all three is the same: access needs to be scoped to the account and project level, not just the role level, and it needs an expiration date whenever the relationship has one. A permission system that only knows about roles, and not about which specific clients and projects a person is actually attached to, will always force you back into ad hoc exceptions.
Rolling This Out Without Breaking How People Work
Tightening access after the fact always causes friction. Someone who's had visibility into everything for two years will notice the day they lose it, even if they never actually used that access. The way to roll this out without a wave of complaints is to sequence it deliberately rather than flipping every switch at once.
Start with an access audit: pull a list of everyone with a login and what they can currently see, and you'll probably find at least a few surprises, an intern with admin rights, a departed contractor still active, a role nobody remembers creating. Then map every person to one of your defined roles, resolving mismatches before you change anything technical. Pilot the new structure with one team, usually finance or one delivery pod, for two weeks, and fix the scoping gaps you find there before firm-wide rollout. Finally, put a recurring quarterly access review on someone's calendar as an actual owned task, not a "someone should probably check this sometime" item. If you're evaluating platforms for this, it's worth reading through what PSA software actually covers before you commit, since access control is only useful if it's built into the same system that already holds your CRM, project, and billing data rather than bolted on as a separate tool.
One more thing worth saying plainly: role-based permissions are not a one-time project. Firms grow, restructure, and change how they staff work. A permission model that made sense at 25 people usually needs a second look by the time you hit 60, not because the original design was wrong, but because the mix of consultants, contractors, and client accounts has changed underneath it.
See how Autovella scopes access by role, client, and project
Get a live walkthrough of permissions built into the same platform that runs your CRM, projects, time, and invoicing, and check the plans that include team-level access controls.
Frequently asked
Five is usually enough to start: Owner/Admin, Delivery Lead, Consultant, Contractor, and Finance. A firm under 20 people doesn't need a role for every job title, it needs a role for every distinct level of data access. Add a Client Portal role only once you're sharing status or files with clients directly.
Scope their access to that one client record and its related projects and invoices, not to the whole CRM. Most PSA platforms let you restrict a role to specific accounts or projects rather than just a functional tier, which is exactly what a single-client contractor needs. Set an end date on the access at the same time you set the contract end date, so it doesn't rely on someone remembering to revoke it later.
Do a full access audit quarterly, and trigger an immediate check any time someone changes role, leaves, or a contractor's engagement ends. Quarterly catches the slow drift of people accumulating access over time; the event-triggered check catches the sharp, obvious risk of an ex-employee or ex-contractor still holding a login.