When EspoCRM collaborators solve shared-record access
A sales or service team often needs a colleague from another team to follow one account, case or opportunity without taking it over. The owning team keeps the record, its assignment and its workflow, while the colleague needs to see what is happening and contribute to the conversation. In EspoCRM 9 and later, collaborators solve this case directly: an added user can view the record and read and post to its stream. They cannot reassign it or take over its ownership, so the owning team's accountability stays intact.
Collaborators are available per entity type, and the documented list includes custom entities as well as Task, Case, Account, Contact, Lead, Opportunity, Document, Knowledge Base Article and Target List. Confirm the exact list for your EspoCRM version in the collaborators documentation before you design around it, and enable the feature only for the entity types where a cross-team reader genuinely needs stream access. The decision is usually clearer when you compare the alternatives. Use teams when a whole group should see and work a set of records every day. Use assignment when one person must act on the record. Use broader role permissions only when someone needs wide read access across many records, because a role grant applies to everything the role covers, which is harder to audit than a per-record share.
Before rollout, have the business owner list which people need collaborator access, which record types they need it on and what they should be allowed to post. Then test with two non-admin users: confirm that the collaborator sees the record and its stream, cannot change ownership, and that the Shared filter in list views returns the records they were added to. Ask your implementation partner to document this test as part of the role design, so that future changes to teams or roles do not quietly widen or narrow who can see a record.
Configuration options and when each fits
This table compares the sharing choices an admin makes for a record outside its owning team: enabling collaborators per entity type, using them on custom entities, and relying on the Shared filter, teams or assigned users. Read each row as a trade-off between who can see a record, who can post to its stream and how much ongoing maintenance the choice creates.
| Option | Visibility effect | Posting and maintenance | When it fits |
|---|---|---|---|
| Collaborators on a supported entity | Added users can view the record without joining the owning team | Added users can read and post to the stream; each addition is a per-record decision | A few colleagues need occasional access to specific accounts, leads or opportunities |
| Collaborators on a custom entity | Available once the custom entity is set up for collaborators, per the feature docs | Confirm the entity's setting and layout before rollout; test with a non-admin user | Your own record types need the same ad hoc sharing as built-in entities |
| Entity types left switched off | No collaborator option is offered for that entity type | No extra per-record upkeep for that entity | Records that must stay within one team or follow strict ownership rules |
| Shared filter | Lists records shared with the user; it does not itself grant access | Users find records quickly; no permission change is made | Users need a fast way to find records others have shared with them |
| Teams | Grants access to every record assigned to the team under the role rules | Maintained through team membership; changes affect many records at once | A group of colleagues needs ongoing, consistent access to a whole area |
| Assigned users | Assigned users own or work the record; access depends on the role | Maintained per record through the assigned user field | One person or a short list is responsible for handling the record |
| Shared filter versus collaborators | Collaborators grant view access; the filter only helps users locate records | Collaborators need upkeep per record; the filter needs none | Confirm with your role model that the filter and collaborator access work together as you expect |
How to enable collaborators and verify access
This sequence turns on collaborators for the entity types you need, adds a colleague to a test record, and proves who can see and post to it. It ends with checks on the Shared filter and on a user who should be blocked, so you can confirm access before you change live records.
Confirm your EspoCRM version
Collaborators are available in EspoCRM 9.0 and later, so start by confirming the version of the instance you plan to change. Check the version in the administration area or your deployment records, and use a non-production copy if your team has one. Your administrator should also confirm that the entity types you plan to share are in use and that no custom role changes are pending. The check is complete when the version is recorded in your change ticket and matches 9.0 or later. If the version is older, stop here and plan an upgrade first.
Enable collaborators for each entity type
An administrator turns on collaborators for each entity type that needs shared records, such as Account, Contact, Lead, Opportunity, Task, Case, Document, Knowledge Base Article, Target List, or a custom entity. Set only the types your process requires, and confirm the exact menu location for your version in the official collaborators documentation. Save the change and open a test record of each type. The check is complete when a collaborators control appears on that entity's record for an administrator. If it does not appear, review the entity's layout and the administrator role before moving on.
Add a collaborator to a test record
Create a test record in a team-owned entity, such as an Opportunity owned by a sales team, and add a named user from a different team as a collaborator. Use a standard user account rather than an administrator, so the result reflects day-to-day permissions. Do not use real customer data in the test. The check is complete when the added user appears in the collaborators list on the record and the owning team's record still shows the same owner. Repeat this for one record of each entity type you enabled.
Confirm the collaborator can view and post
Sign in as the collaborator and open the test record directly. Read the existing stream entries, then post a short test note in the stream. Ask the record owner to sign in and confirm the note appears in the same stream. The collaborator should be able to view and post, but the scope of other actions depends on the role and permissions that apply to that user. Record which actions succeeded. The check is complete when both users see the same post and the collaborator's note is attributed to them.
Check the Shared filter returns the record
While signed in as the collaborator, open the list view for the same entity type and apply the Shared filter. The test record should appear in the results. Repeat the check for each entity type you enabled, because the filter should be confirmed per type. For background on how collaborators are described, see the official EspoCRM collaborators documentation. The check is complete when the record appears in the filtered list for every entity type tested. If it does not, confirm that the collaborator setting was saved for that type.
Confirm a user without the grant is blocked
Sign in as a user from the same team as the owner who was not added as a collaborator, or from another team with no grant. Try to open the test record directly, search for it by name, and apply the Shared filter on its list view. The record should not appear in the search or the filtered list, and direct access should not display its details. Record each attempt and the result. The check is complete when none of the three attempts reveals the record. If access succeeds, review the role permissions for that user before you proceed.
Record results and remove test data
Write down the version, each entity type tested, the users involved, and the result of each check in your change record. Remove the test collaborator from the test records, then delete or archive the test records according to your data handling policy. Confirm the removal by viewing one record as the former collaborator, who should no longer see it. The sequence is complete when the change record contains the results and the test data no longer grants access to anyone outside the owning team.
How collaborators interact with roles and teams
Collaborator access is an addition for specific records, and it does not replace anything else in EspoCRM. A collaborator gains the ability to view a record and read and post to its stream, on the entity types where collaborators are enabled. The user's role still decides every other action: whether they can create, edit, delete or export records, which fields and panels they see, and which entity types they can reach at all. Team membership and the record's assigned user keep their existing meaning, so a collaborator is not made an owner, a team member or an assignee by being added. Plan the sharing model with that separation in mind, because a reader who assumes collaboration widens the role will grant too little or too much.
The risk to plan for is accidental widening. Because collaborators are added per record, a user with a narrow role may be able to see a record through sharing that their role would otherwise hide from list views, and they may post comments that other users then read. Before rollout, create a test user with a restricted role, add them as a collaborator on one sample record for each enabled entity type, and confirm what they can open, search, update and see in the Shared filter. Then repeat the check with a user on a team that already has access, to confirm that the team's visibility did not change. Record the results so that a later role edit can be checked against the same cases.
Confirm the exact behavior in your EspoCRM version before writing the test plan. The collaborator documentation describes what collaborators can view and post, but how it interacts with your own role scopes, such as the level of access granted for list and read actions, and with any custom permission settings on your instance should be checked in a staging environment. Ask your implementation partner or your own administrators to document each role that will be used alongside collaborators, and keep that list with the sharing rules so that future role changes trigger a review of the affected entity types.
Security risks of sharing records
Collaborators give colleagues outside the owning team a view of a record and the ability to post to its stream. Each sharing decision widens who can read customer data, so the risks below tend to appear together when sharing is handled informally. Review them before enabling collaborators on any entity type.
Over-sharing through broad collaborator lists
Adding many colleagues as collaborators on a record gives each of them read access to the full record and its stream, even when they only need one field or one conversation. Teams often add collaborators to resolve a short-term question and forget to remove them. Ask who is currently a collaborator on your most sensitive entities, and whether each person has a current business reason to see the record. Confirm how your role and team permissions interact with collaborator access in your own test instance before rollout.
Sensitive notes in shared streams
The stream of a shared record is visible to every collaborator, and collaborators can post to it. A note about a pricing concession, a complaint or personal data can therefore reach people who were never meant to see it. Set a rule that personal and confidential details stay in restricted fields or on the owning team's records. Review a sample of recent stream posts on shared records to see what has been written.
Retained access after role changes
A collaborator added during one project keeps access after that person changes team, leaves a deal or moves to a role with no business need for the record. Access granted through collaboration is separate from the team and role structure that administrators review, so it can be overlooked during offboarding and role changes. Include collaborator lists in access reviews and in your leaver checklist.
Missing audit of who was added
Without a regular review, nobody can say who was added as a collaborator, when, or why. This makes it hard to answer a customer or auditor question about who could see a record. Ask your EspoCRM administrators how collaborator changes are logged and recorded in your own environment, and agree on a periodic export or review of shared records for your highest-risk entity types.
Admin hygiene and access restriction
The EspoCRM security docs recommend avoiding admin accounts for daily work, requiring two-factor authentication, and restricting access by IP address. These controls matter more when collaborators widen the set of users who can reach a record. Confirm that administrators who manage collaborator settings use separate accounts, that two-factor authentication is enforced for every user who can view shared data, and that your IP restrictions cover the users you intend to share with.
Questions teams ask before enabling collaborators
How much effort does it take to configure collaborators in EspoCRM?
For a single entity type, configuration is a small change in the admin settings, followed by a check of roles and layouts. The effort grows with the number of entity types you open up, how many roles need the change, and how much your team has customized layouts and workflows around ownership. Your own administrator can make the first change in a test instance to see what the record looks like for a collaborator. Confirm the exact steps for your EspoCRM version against the collaborators documentation before you plan the work, because the settings and permissions involved are version-specific.
Can an internal admin enable collaborators without outside help?
Usually yes, for a simple setup. An internal administrator who knows the Entity Manager, roles and teams can enable collaborators on the entity types you choose and test the result. Outside help becomes more useful when the rules are complex, such as mixing collaborators with team-based access, portal users or custom entities that have their own permission logic. Be clear about who will own the rules after go-live, since a collaborator change that is not documented tends to be undone or misread later.
What does a partner scope for collaborators typically include?
A fixed-scope engagement usually covers the entity types in scope, the roles and permissions that govern who can see and post, the layout and Shared filter changes users will see, and a test pass with representative users. It may also cover documentation for administrators and a short handover. Ask for the scope in writing, including which entity types are included, how many roles are reviewed, and whether custom entities are part of the work. DeployOpen plans and implements these changes in the client's own EspoCRM instance and provides a quote based on that written scope.
How long does a pilot take to validate collaborators?
The length of a pilot depends on how many entity types and roles you test, how many user groups must confirm their access, and how quickly your team can gather realistic test records and reviewers. Pilots that cover only one entity type with a small group of users run faster than pilots that test several types across sales, service and marketing. Agree on the test cases before you start, such as whether a collaborator can open a record, read the stream, post a note and find the record through the Shared filter. Confirm the expected duration with your implementation partner or internal project lead.
What must our team provide before a collaborator pilot starts?
Your team should provide a test or staging EspoCRM instance, a list of entity types you want to share, the role matrix that describes who currently sees what, and named reviewers from each team who will confirm results. You will also need a sample of records that reflect real ownership patterns, with owners, teams and any existing assigned users. Access to an administrator account for the test instance is needed, and someone should be able to approve the change for production. Missing reviewers or unclear sharing rules are the most common cause of delays.
Which entity types support collaborators?
As of EspoCRM 9.0, collaborators are available for custom entities and for Task, Case, Account, Contact, Lead, Opportunity, Document, Knowledge Base Article and Target List. Support is set per entity type, so you enable it only where a business need exists. Check the collaborators documentation for your exact version before you finalize the list, since the supported types can change between releases.
How do collaborators differ from teams and assigned users?
Assigned users own or work a record, teams group users for access and assignment, and collaborators are individual users added to one record so they can view it and read and post to its stream. A collaborator does not become a team member or an owner. Teams usually govern broad access across many records, while collaborators are a record-level exception. Use teams for standing access by department and collaborators for named colleagues who need one record, and review both together so access does not spread without a clear reason.
Limits to confirm in your EspoCRM version
Collaborators are a per-entity, per-version feature, and several of its edges depend on how your instance is configured. The cards below list the behaviors to test in your own environment rather than assume, so the access model you sign off on matches what EspoCRM actually does.
Entity types outside the supported list
The documented collaborator support covers custom entities plus Task, Case, Account, Contact, Lead, Opportunity, Document, Knowledge Base Article and Target List. Any other entity type added by an extension or a custom build should be treated as unsupported until tested. Check whether the Collaborators option appears in the Entity Manager for each type you plan to use, and confirm what a collaborator can see on that type before you grant access to real customer data.
Interaction with the Advanced Pack
Workflows, Business Process Management and reports are provided by the Advanced Pack, and they may create, update or read records on behalf of users. Confirm whether a workflow that assigns or updates a shared record behaves as expected for collaborators, and whether report results for a collaborator include only the records that user can already view. Test one workflow and one report with a collaborator account before rollout.
Custom layouts and field visibility
Collaborators see a record through its layout, so a field hidden or restricted for a team may still appear once a colleague is added as a collaborator. Review detail, list and stream panels on each shared entity type with a test collaborator account. Confirm that sensitive fields, such as contract values or personal data, stay hidden where you need them to be.
Exports and mass actions
Ask whether exporting records, running mass updates or mass emails on a list view includes records that are visible only through collaboration. Test each path with a collaborator account. If a collaborator can export or mass-update records they could not otherwise edit, decide whether that matches your policy or whether role permissions must be tightened.
Version-specific behavior after 9.0
The feature is documented from version 9.0, and EspoCRM 10 changed several areas, including upgrade handling. Confirm the collaborator behavior in the exact version you run, and retest after each upgrade, because stream permissions and entity options can change between releases. Record the version used for your acceptance tests so later changes can be compared against it.
Performance at high record volumes
Collaborator checks add access rules to every list and stream query. Ask the implementation team to measure list load times, stream loading and search on a dataset close to your production volume, with the collaborator count you expect per record. Confirm indexing and cron-driven jobs are sized for that load before enabling the feature on large entity types.
Governing shared records after go-live
Start with a pilot on one entity type, chosen because the sharing need is concrete and the record volume is manageable. Account or Opportunity is a common candidate in a sales team, while Case suits a support team that hands work between tiers. Enable Collaborators for that entity type only, add the permissions and layout changes it needs, and run the pilot for a fixed period agreed with the business owner before widening it. Confirm in your own instance which entity types the Collaborators setting exposes in your version, since the feature list in the EspoCRM documentation is the authoritative reference for v9 and later and may change in later releases.
Decide who may add collaborators before users start doing it. Collaborators can view a record and read and post to its stream, so adding someone is an access decision, not a convenience. Write down which roles may add collaborators, whether record owners or team leads must approve additions, and how external or contractor users are handled. Review collaborator lists on a fixed cadence, for example at each quarterly access review, by exporting or reporting on records with collaborators and checking that each one still has a business reason to see the record. Use the Shared filter during these reviews so the people reviewing see the same view the users do.
Train users on what posting to a shared stream means. Anything a collaborator reads or posts is visible to everyone who can see the record, so set a short house rule that customer-sensitive detail belongs in the right fields and not in free-text comments. Record the final decision in your access model: which entity types allow collaborators, who approves additions, the review cadence, and who owns the list. Tie that document to your roles and teams setup so that a later change to roles, or an upgrade to a newer EspoCRM release, is checked against the agreed rules rather than discovered by users.
What a DeployOpen engagement covers for collaborators
The fixed-scope sequence takes collaborator sharing from an agreed access model to a tested configuration, documented permissions and runbooks your team can operate. Scope and deliverables are agreed in writing before work starts.
Agree scope and deliverables in writing
Before any configuration begins, DeployOpen and your team agree the scope, deliverables and timeline in a written statement of work. Your product owner for CRM and your security or compliance lead sign off on what is in and out of scope, including which EspoCRM version and hosting model the work covers. The step is complete when the signed scope is on file and every later step maps to a named deliverable.
Review the current access model
DeployOpen reviews how records are owned and shared today: teams, roles, assigned users and any sharing done through email or spreadsheets. The review identifies which cases need a colleague outside the owning team to read and post on a record, and which should stay within the team. Your team receives a short findings list covering each use case, the roles involved and the data it touches. The step closes when your team confirms the list matches how people actually work.
Select the entity types to enable
Together, DeployOpen and your team choose which entity types will accept collaborators, drawing from the standard types that support the feature and any custom entities you have built. Each choice is recorded with the business reason and the roles allowed to add collaborators. Entity types not chosen stay as they are. The step is complete when the approved list of entity types and their owners is signed off.
Configure and test in a non-production instance
DeployOpen enables collaborators on the approved entity types in a non-production instance and sets up layouts and the Shared filter. Test users from each role add, view and post as collaborators, and attempt actions they should not be able to take, such as reading records they were not added to. Failures are logged, fixed and retested. The step closes with a test record showing each scenario passed or a documented exception your team accepts.
Document permissions and Shared filter use
DeployOpen writes a permissions reference that lists each entity type with collaborators enabled, what a collaborator can see and post, and which roles can add them. It also documents how users find shared records through the Shared filter and what it does not replace, such as team-based visibility. Your administrators review the document against the test results. The step is complete when the reference is approved and stored where your team can find it.
Hand over runbooks and confirm production readiness
DeployOpen delivers operational runbooks for adding and removing collaborators, reviewing shared access and reverting a configuration change. Your administrators walk through the runbooks in a handover session and perform one change themselves in the test instance. Changes are then applied to production under the agreed plan, with your team checking the same scenarios. The step closes when your team signs the handover record and production matches the approved configuration.
How DeployOpen delivers EspoCRM access design
DeployOpen starts collaborator work with a written scope agreed before any configuration begins. For shared records, that scope names each entity type that will accept collaborators, the roles and teams that may add them, the record types that stay owner-only, and the stream behavior the business expects. Most engagements are fixed-scope, so the deliverables, the entity list and the acceptance checks are written down together. Ask for the scope to list which of the supported entity types (Task, Case, Account, Contact, Lead, Opportunity, Document, Knowledge Base Article, Target List and custom entities) are in and out, and who will own the decision on each one.
Before anything is handed over, DeployOpen tests the access model with representative users from the sales, service and marketing teams, not only administrators. Each test user receives a defined set of records, and the test checks what a collaborator can view, read and post in the stream, what they cannot edit, and how the Shared filter behaves for them. Testers should also confirm that a collaborator added to one record gains nothing on related records they do not own. Findings are logged against the written scope and retested until the agreed checks pass. Ask for the test script and the list of users who will sign off.
Deliverables include configuration documentation covering the enabled entity types, role settings, a short user guide for adding collaborators and the Shared filter, and an operations note on who may change these settings later. Optional retainers cover ongoing support, changes to entity settings as teams grow, and periodic reviews after EspoCRM upgrades. Confirm with DeployOpen what is one-time and what recurs, which party maintains the documentation after handover, and how changes are priced and approved. DeployOpen does not issue certifications or attestations for this work.
