How to design EspoCRM roles and teams before go-live
A sales or service organization usually needs three things from its CRM at once: reps should see their own pipeline, managers should see their teams' records, and leadership should see everything. In EspoCRM, these needs are met by combining roles, which set what a user may do with each entity, and teams, which group users so that records can be shared with them. Each permission in a role is scoped to a level such as all, team or own, and a user's effective access is the combined result of their own role, the roles inherited through their teams, and the record ownership and team assignments on each record. The EspoCRM security documentation is the right reference for the exact behavior of each level, and the decision to confirm with your own administrators is which entities need team-level sharing at all.
Default roles are a reasonable starting point for a small team where everyone sees the same data. A deliberate design becomes necessary once reps must not see each other's opportunities, regional managers need visibility limited to their region, or service staff should read accounts without editing billing fields. Before go-live, write down the job functions, the entities each function touches, and the level of access each one needs for read, edit, create and delete. Then decide which teams represent sales territories or service queues, and whether team membership is maintained by hand or synchronized from an identity provider through OIDC group mapping. Those choices determine how many roles you need and how much maintenance they will require later.
Test the design before users arrive. Create a small set of test accounts, one per job function, and sign in as each one or review the access the administrator interface reports for them. Confirm that a rep cannot open a colleague's private opportunities, that a manager sees the team's records, and that leadership sees the full dataset without granting broad admin rights. Keep administrator accounts out of daily selling and service work, which the security documentation also recommends. Ask your implementation partner or internal team to document each role, its team membership rules and the test results, so that a future change to a role can be checked against the same cases.
What all, team and own access levels control
EspoCRM decides what a user can see and change by combining a role with scope levels for each entity and action. The records themselves carry an owner and assigned teams, so the scope level you pick only works if your ownership and team data match how your business actually sells and serves customers.
All scope and organization-wide reach
The all level grants a user access to every record of that entity and action, regardless of owner or team. It suits administrators, operations leads and finance users who must see the whole pipeline. Because it is the broadest setting, grant it per entity and per action rather than across the board. Before you assign it, confirm in your version which actions the all level applies to for each entity, since some actions expose fewer options than others.
Team scope and shared records
The team level limits access to records whose assigned teams overlap with the user's teams. This is the usual setting for account managers working a shared book of business. Check that accounts, opportunities and cases carry the team assignments you expect, because a record with no team, or the wrong team, will be invisible to the people who need it. Test with a sample user from each team before rollout.
Own scope and personal records
The own level restricts a user to records they own or are assigned to. It fits individual contributors who should work only their own leads and tasks. Ownership changes when records are reassigned, so decide who may reassign records and how handovers happen. Confirm how the own level treats records a user created but did not own, since teams often assume creators keep access.
Related scopes and linked records
A user's access to a record often depends on related records, such as an opportunity visible through its account. Check each entity's relationships before setting levels, because a narrow level on one entity can hide context that a user needs on another. Map the relationships your reps use every day, then test the screens they open. Confirm the exact behavior in your version, since related-record visibility differs from direct record access.
Level choice per entity and action
Scope levels apply separately to each entity and each action, such as read, edit and delete. A common mistake is granting a broad edit level while leaving read narrow, or the reverse. Build a matrix of entities against actions with the level chosen for each, then review it with the business owner. Record the rationale for every all-level grant so audits can trace it later.
How team-inherited roles shape a sales manager versus rep model
Roles assigned through teams let managers and reps share one role definition while still seeing different records. Instead of building a separate role for every seniority level, you define one sales role with the permissions a seller needs, then control visibility through team membership. A user inherits the teams a role is attached to, and the record scope on each entity (all, team or own) decides how far that role reaches. In practice, the manager and the rep both hold the same sales role, but the manager is a member of every regional team while the rep belongs only to one. Confirm in your own instance how team-inherited access is applied to each entity before you rely on it, because the effect depends on how the role is set for every entity the sales team uses.
*Illustrative example:* a sales manager and two reps. Each holds the same Sales Rep role, which allows Accounts and Opportunities at the team level and Contacts at the own level. The manager is a member of the North and South teams, so the manager sees Accounts and Opportunities owned by either team. Rep A is only in North and sees North records, while Rep B is only in South and sees South records. Each rep also sees Contacts they personally created, even if the account sits with another team. The manager sees all of their teams' Contacts. If the manager later needs read-only visibility across every region, you add a team for that purpose instead of cloning the role, and you check the result by viewing the effective access of a test user in each group before the role goes live.
Choosing a role pattern for sales, service and leadership
Sales reps usually need to work their own accounts, contacts, leads and opportunities without seeing other reps' pipelines. The common shape is an own-level scope on sales records, combined with team-level visibility on shared accounts that more than one rep works. Reps also need read access to the product and price data they quote from, but rarely edit it. Settle these points with the business before building:
- Record ownership: Who owns an account when two reps share a customer, and does ownership move when a deal changes hands?
- Shared accounts: Which accounts are worked by a team rather than an individual?
- Lead handling: Can reps see unassigned leads, or only the ones routed to them?
- Deletion and export: Should reps be able to delete or export records, and if so, which entities?
- Reassignment: Who is allowed to change record ownership, and is that a rep action or a manager action?
Check each answer against a test user in a non-production instance before rollout, using the same role your reps will receive.
Sales managers typically need visibility across their team's records and the ability to reassign, review and report on them, without taking on administrative rights over the system. The usual shape is a team-level scope on sales records, with managers placed in the team they lead so that the scope follows the reporting line. Managers often need broader read access than their reps but narrower write access than a system administrator. Questions to settle with the business:
- Team boundaries: Does each manager see exactly one team, or do some managers oversee several teams or regions?
- Cross-team deals: How should a deal shared between two teams be visible to both managers?
- Reassignment rights: Can managers reassign records within their team only, or across teams as well?
- Forecast and reporting access: Which records and fields must managers see to run forecasts, and which should stay hidden from them?
- Escalation: Who approves a manager's access to records outside their team?
Confirm the manager role against the team structure in your own environment, because the team membership you define drives what the manager can see.
Service agents work on cases and the customer records attached to them. Their access is usually organized around the queue or team that handles a case type, not around the individual sales owner of an account. This tab matters because service data is often more sensitive than sales data, since cases can contain support history, attachments and personal details. The common shape is team-level access to cases and the related accounts or contacts, with restricted access to fields that the service team does not need. Questions to settle:
- Queue structure: Which teams own which case types, and can an agent belong to more than one queue?
- Account visibility: Should agents see the full account record, or only the contacts and cases linked to their queue?
- Sensitive fields: Which fields on contacts or cases should be hidden from agents outside a specific team?
- Escalation paths: How do cases move between tiers, and does the role need to change when they do?
- Customer communication: Who may send email from the system, and which templates may they use?
Test the agent role with a case that spans two queues, because that is where team-based visibility most often surprises people.
Executives usually need read access to aggregated or team-spanning data, with little need to edit records directly. Administrators need to configure the system, but the design should keep them out of daily sales and service work. The EspoCRM security guidance recommends avoiding admin accounts for daily work, so the administrative role should sit with separate, named accounts. For executives, the design usually means a broad read scope on reports and dashboards, with write access removed. Questions to settle:
- Executive visibility: Do executives need every record, or only reports and summaries?
- Admin separation: Which people hold administrative rights, and do they also need a regular user account for daily work?
- Sensitive configuration: Who may change roles, teams and integration settings, and who approves those changes?
- Audit needs: Who must be able to review who changed access, and how often?
- Break-glass access: Is there an emergency administrative path, and who controls it?
Keep the number of administrative accounts small and document each one, because broad admin rights bypass most of the scope rules described elsewhere in this design.
How to build baseline roles and teams in EspoCRM
This sequence turns your sales and service structure into teams, a common baseline role and role-specific permissions, then proves with test users that each person sees only the records they should. Each step ends with a check you can repeat after later changes.
Map teams to your business structure
Before touching the admin panel, list the groups that own customer records, such as regional sales, account management, support queues and leadership. For each group, note who leads it, which records it works on and whether anyone needs to see another group's data. Your CRM administrator and a sales or service lead should sign off on this list, because every later permission depends on it. The step is done when each active user maps to exactly one primary team, and the exceptions (people who work across teams) are written down with a reason.
Create the team records
In Administration, open Teams and create one team for each group from your map, using names your users will recognize. Keep the list short; a team should represent a group that shares records, not a single person or product line. Record the team lead in the team's description or a naming convention so reviewers can see ownership later. The check is a simple export or list view showing every team from the map, with no duplicates and no leftover test teams.
Build the baseline role for everyone
Create one role that every internal user receives. Keep it restrictive: give read access only where the whole company needs it, such as shared knowledge or the user's own profile, and leave create, edit and delete at none for sensitive entities. Set the baseline so that record access is limited to own records unless a higher level is granted in a role-specific role. Assign the baseline role to a pilot group first. The check is a test user with only the baseline role who cannot open a colleague's account, opportunity or case.
Layer role-specific roles on top
Create additional roles for each job function, such as sales rep, sales manager, support agent and operations. Grant team-level access to the entities that group works on, and all-level access only where a documented business need exists, for example a manager who reviews the whole region. Reps usually need own or team access to opportunities and accounts, while managers may need team access to their reps' records. Keep role names descriptive and record the business reason beside each permission. The check is a permission review where each role's entity grid matches the written job description, with no entity granted by accident.
Assign users to teams and roles
Assign each user to their primary team and attach the baseline role plus only the job-function roles they need. Confirm that team-inherited roles behave as intended: check whether a role granted to a team applies to its members, and whether your version handles that inheritance the way your documentation describes. Avoid giving administrator rights for day-to-day work. The check is a user list filtered by team, showing each person's roles and no user holding a role that their job does not require.
Test effective access with representative users
Create or use test accounts for at least one rep, one manager and one user from another team, then log in as each one and open the same records. Verify that a rep sees only their own and team records, a manager sees the team's records as designed, and the cross-team user cannot see the records of the other team. Repeat the checks for the actions each role should block, such as editing, deleting and exporting. Ask the business owner to confirm the results. The step is done when every test matches the written design and the results are saved for the change record.
Document the model and schedule reviews
Record the final team map, role matrix, exceptions and test results in a document your administrators can find. Include who approves a change to a team or role, and who removes access when someone leaves or changes function. Confirm with your own team how often reviews should happen, since DeployOpen does not set that interval for you. The step is done when a new administrator can read the document and reproduce the test results without help from the original builder.
Which access design option fits your organization
This table compares three ways to structure EspoCRM roles: one role per job function, team-inherited roles on a shared baseline, and a small set of broad roles that rely on record ownership. Read each row against your own sales and service structure, then check the maintenance column to see how the design will change as teams and users change. The main takeaway is that the more access depends on job titles, the more roles you will maintain, and the more it depends on teams and ownership, the more you must keep team membership accurate.
| Design option | When it fits | What it costs to maintain |
|---|---|---|
| One role per job function | Job functions differ clearly in the entities and fields they need, and each function has few members who change often. | Each new job function or permission change needs a role edit. Role count grows with every exception, so review the list on a fixed schedule. |
| Team-inherited roles with a shared baseline | Reps and managers work in defined teams, and teams own their accounts and opportunities. A common baseline covers what every user can see. | Team membership must stay accurate, because access follows the team. Baseline changes affect everyone, so test them before editing. |
| Few broad roles with strict record ownership | Users need similar entity access and differ mainly by the records they own. Headcount is small enough that individual ownership is easy to govern. | Low role count, but ownership rules carry the security load. Reassigning records during staff changes becomes a recurring task that needs a clear owner. |
| Combined design | Your organization has a shared baseline and a few functions with distinct needs, such as a sales manager who sees team records that reps cannot. | Two layers to review: the baseline and the function roles. Document which layer grants each permission so reviewers can trace access. |
How to check a user's effective access before go-live
Before go-live, test what each role actually allows, not what the design document says it should allow. Create one test user per role in the design matrix, assign each to the team and role combination it is meant to hold, and log in as each one. For every entity that matters (accounts, contacts, opportunities, cases), confirm which records appear in list views, which can be opened, edited or deleted, and which fields and tabs are visible. Record the results in a grid that uses the same rows and columns as your design matrix, so any gap is visible at a glance. Ask the vendor or your own administrator to confirm how the current version evaluates team-inherited roles, since that behavior is where most surprises occur.
Seed each team with sample records before testing. Create at least one account, opportunity and case owned by a user in each team, plus one record owned by a user with no team, and one record that a team member has been assigned to as a secondary user if your model uses that pattern. Then check each test user against this dataset. A sales rep should see their own records and their team's records at the levels the matrix specifies, and nothing from other teams. A sales manager should see the wider scope the matrix grants. Illustrative example: if a rep can open an opportunity owned by a colleague in another team, the failure is usually a role granted at the all level by mistake, not a layout problem, and the fix belongs in the role, not in a list filter.
Repeat these checks after any change to roles, teams, team membership, the identity provider's group mappings, or the layouts that expose fields, and again before every major upgrade. Major upgrades can change permission handling and extension behavior, so a test run that passed on the previous version is not evidence for the next one. Keep the test users, the sample dataset and the results grid under version control or in your change records, so an auditor or a new administrator can see what was tested and when. Your team should own this routine after handover, and a partner's fixed-scope engagement can include the initial test matrix and run, with the ongoing repetition handled by your own staff or a retainer.
Access design mistakes that expose customer data
Most EspoCRM access problems come from a small set of habits: granting broad access by default, working in admin accounts, and letting changes accumulate without review. Each card below names one of these mistakes, explains how it shows up in a role or team design, and gives the check that catches it before customer records are exposed.
All-level access granted by default
An all-level permission lets a user read or edit every record of an entity type, whatever team owns it. It is often added to a role during testing and left in place, so a rep can see accounts across every region. Review each entity type in each role and confirm that all-level access is limited to people whose job requires it, such as operations or finance reviewers. Team and own levels should be the default for sales and service roles.
Admin accounts used for daily work
The EspoCRM security guidance recommends avoiding admin accounts for daily work. When a sales manager edits records, runs imports or opens customer data from an admin login, every action carries full system rights and any session theft exposes the whole instance. Give administrators a separate account for configuration and use standard role-based accounts for everyday selling and support. Check the admin user list for people who log in to admin accounts routinely.
Team changes that widen access
Teams control which records a team-level permission reaches. Adding a user to an extra team, or adding a team to a record, can silently expose accounts that user should not see. A reorganization that merges two sales territories can have the same effect. Before changing team membership, list the records each affected team can reach and confirm the change matches the intended territory. Keep a written record of who approved each team change.
Roles copied without review
Cloning a role is fast, but a copy keeps every permission of the original, including ones added for a past project or a former team. Over time, a rep role can accumulate export, mass update or delete rights that no current user needs. Treat each cloned role as a new design: remove permissions the new job does not require and document why each remaining permission is there. Compare the role against the baseline the business agreed on.
Effective access never checked
A role can look correct on its own but produce a different result once team membership, portal status and inherited team roles are combined. Teams often assume a rep sees only their own accounts, when a team-inherited role grants wider reach. Pick representative users for each role, log in as them in a test instance, and confirm which records and actions they can see. Repeat the check after every role or team change.
Questions buyers ask about EspoCRM access design
How much does it cost to design EspoCRM roles and teams?
The cost depends on the written scope, which DeployOpen agrees before work starts, and DeployOpen does not publish a price list. The main drivers are the number of teams, the number of entities that need access rules, how many exceptions the business wants (for example, managers who see across regions or reps who share accounts), and how many roles already exist that need reworking. Ask for a quote that lists each team and entity in scope, the roles to be built or revised, the test cases used to verify access, and whether a follow-up review is included. Licensing is a separate line item: the open-source edition can be self-hosted for free, while EspoCRM Cloud is priced per user per month on the EspoCRM pricing page.
How long does it take to set up roles and teams in EspoCRM?
No duration is published for this work, so the timeline should come from the written scope. Effort rises with the number of teams, entities, and exceptions, and with how much agreement is needed from sales, service and compliance owners on who should see what. A small structure with a few teams and clear reporting lines is quicker to settle than a matrix where reps cover several regions. Ask for milestones that separate the design workshop, the role build, and the verification pass, and confirm who signs off each stage.
What do we need to provide before the access design starts?
You need an organization chart with reporting lines, a list of teams and the records each team owns, and the list of entities in use (accounts, contacts, opportunities, cases and any custom entities). You also need the decisions that drive access: which roles can see all records, which can see only their team's, and which can see only their own. Confirm which staff need admin rights, which integrations will use API users, and whether any portal audiences exist. Clear answers to these questions cut back-and-forth during the workshops.
Can our internal team design EspoCRM roles without a partner?
Yes, an internal administrator can design roles if they understand how EspoCRM combines role permissions with team membership and can test the result. The work is mostly decision-making and testing rather than coding. The risk is in the details: a role that grants access at the all level by mistake, or a team-inherited role that exposes records to more people than intended. A partner is useful when the access model is complex, when the business needs an independent review before go-live, or when the internal team has no time to build and verify test accounts for each role.
What goes wrong most often with EspoCRM access levels?
The most common problem is a permission set that is broader than intended, usually because an all level was granted for convenience or a shared team gives reps access to records they should not see. Another frequent issue is an admin account used for daily sales work, which hides access errors because admins see everything. Teams also run into trouble when new staff are added to a team without a matching role review. Test each role with a real user account in a non-production instance before rollout, and recheck access after any org change.
How do we check what a user can actually access in EspoCRM?
Check the effective access of a user by logging in as a test account with the same roles and team membership, then opening records across each entity and confirming what appears in lists, search, related panels and exports. Repeat the test for each role and for the edge cases, such as a rep moved between teams or a manager who needs cross-team visibility. Keep a written test matrix so the results can be repeated after upgrades or configuration changes. Confirm with your own administrators how they prefer to record the results, since EspoCRM does not issue an audit report.
Does the access design need to be revisited after an EspoCRM upgrade?
Yes, it is wise to retest roles after any upgrade, extension change or new entity, because permissions can interact with new features and custom fields. The retest effort scales with the number of roles and entities, so keep the test matrix up to date. Ask any partner whether re-verification is part of the scope or a separate retainer, and confirm how upgrades will be tested before production. Plan the review alongside your upgrade process and the EspoCRM release notes for the version you are moving to.
How DeployOpen scopes and delivers EspoCRM access design
DeployOpen plans, builds, tests, documents and supports EspoCRM access inside infrastructure you control. We start from how your sales, service and management teams actually see customer records, then turn that into roles, teams and a verified effective access model that you can hand to your own administrators.
How we scope
- The written scope lists the teams, record types and access levels to be designed for your EspoCRM instance.
- It names which roles are baseline roles, which are team-inherited, and which portal or API users are out of this piece.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before the design work starts.
- The scope states which users you will test with and which evidence you will receive at handover.
How we build
- We map each team's record access needs to all, team and own levels, then draft the role matrix for review.
- We configure baseline roles, team assignments and team-inherited roles in a non-production copy of your instance.
- We test sample users for sales manager, sales rep and support accounts, checking what each can see, edit and delete.
- We record each test and the reason behind each permission so later changes can be reviewed against the design.
How we hand over
- You receive the role matrix, team structure, baseline role definitions and the test results in documented form.
- Administrators receive a short runbook covering how to create a new role, add a user to a team and check effective access.
- We walk your administrators through the effective access check so they can repeat it after handover.
- Changes to the design are logged, so your team can see why each permission exists.
How we support
- Ongoing support for role changes, new teams and access reviews can be arranged as a retainer.
- Retainers can include periodic re-testing of effective access after EspoCRM upgrades or extension installs.
- Confirm with us during scoping how your own administrators will request changes and who approves them.
- Ask for the support terms in the written quote, including what is covered and how requests are handled.
