When one owner per record stops working for multiple assigned users in EspoCRM
Teams that share an account, an opportunity or a case often end up forcing several people into one Assigned User field, so the second rep is tracked in a description note or a custom text field. That workaround hides ownership from reports, filters and assignment rules. EspoCRM's multiple assigned users feature addresses this by letting a record carry more than one assignee. According to the EspoCRM documentation, as of v9.0 the feature is enabled per entity type in the Entity Manager, not globally, so the first decision is which entity types genuinely need shared ownership. Opportunities shared by a sales pair may qualify, while entities that are always handled by one person may not.
Before enabling anything, plan for the default maximum of 10 users per record. Confirm whether that limit fits your largest realistic team on a single record, and check with your EspoCRM version and any extensions that rely on the single Assigned User field. The documentation also states that existing values in the Assigned User field are not transferred to the new Assigned Users field. Any records you have today will therefore show no assignees in the new field until you migrate them, and your reports, list views and access rules must be checked against that gap. Treat this as a cutover task with a verification step, not a background change.
Work out the sequence before the build starts: confirm the entity types, agree the cap, define who may change assignees, decide how historical assignments move across, and identify which layouts, filters and automations read the old field. A small test instance with a copy of representative records is the safest place to check these, and the result should be documented so that the production change can be repeated and reviewed.
Configuration options and when each fits
This table compares the ownership models a team can choose for a record in EspoCRM, from a single Assigned User to Multiple Assigned Users and Teams-based sharing. Read each row against the record type it will cover, and note that the 10-user default cap is the only limit this topic confirms.
| Option | When it fits | Trade-off |
|---|---|---|
| Single Assigned User only | Records with one accountable owner, such as a lead that one representative works end to end | Simplest to report on and maintain, but co-owners must be tracked through teams, notes or stream mentions |
| Multiple Assigned Users on selected entity types | Records shared by a small group, such as an account handled jointly by sales and customer success | Adds a new field alongside the existing Assigned User, so reports, filters and layouts must be checked for each entity type |
| Multiple Assigned Users on all entity types | Broad rollouts where most teams need joint ownership of records | Wider change to layouts, list views and permissions; harder to test and roll back than an entity-by-entity approach |
| Teams-based sharing | Access that follows a department or region rather than named owners | Grants visibility to a group but does not name individual owners on each record |
| Keep the default 10-user cap | Teams where no record needs more than ten owners, which is the documented default | Simplest option to govern; any record needing more owners requires a different design |
| Confirm a different limit | Only when a documented need exceeds ten owners and the limit can be verified in your version | Requires confirming the setting and its effect on performance, layouts and data entry with your EspoCRM version before rollout |
| Existing Assigned User values | Entity types already in use with populated Assigned User fields | Existing values are not transferred to the new Assigned Users field, so a migration step is needed before go-live |
How to enable multiple assigned users step by step
This sequence takes a team from an EspoCRM instance that already runs a supported version to records that carry several owners, with a check at each stage so problems surface before users depend on the change.
Confirm the EspoCRM version is 9.0 or later
An administrator opens the About or system information view in the admin area and records the installed version. Multiple assigned users is available from version 9.0 onward, so an instance on an earlier release needs an upgrade planned and tested before this change. Check that the version number is 9.0 or higher before moving on. If the instance is older, stop here and plan the upgrade first, since the rest of the sequence will not work on earlier releases.
Enable multiple assigned users in the Entity Manager
An administrator opens Administration, then Entity Manager, and selects each entity type that needs several owners, such as Lead, Opportunity or a custom entity. The multiple assigned users option is switched on for that entity type only, so other entities keep the single Assigned User field. Save the entity and confirm the new Assigned Users field appears on a record of that type. Only proceed once the field is visible on a test record.
Check the default 10-user maximum on a test record
On a non-production record, a administrator or test user assigns users to the new Assigned Users field until the limit is reached. The documented default maximum is 10 users per record, so the eleventh selection should be refused. Record the result and note whether your organization needs a different limit. Confirm with your EspoCRM administrator or the vendor documentation how the limit can be changed in your version before planning around it, since the default is a starting point rather than a guarantee for every design.
Confirm how existing assignments will be handled
Existing values in the original Assigned User field are not transferred to the new Assigned Users field. The team should export current assignments, decide which owners move to the new field, and write a migration step, such as a scripted update or a CSV import in Update Only mode, that copies them across. Test that migration on a copy of the data. The check is a sample of migrated records showing the same owners in the new field as in the old one.
Adjust list and detail layouts so the field appears
In the Entity Manager, the administrator edits the list layout and the detail layout for each enabled entity type and adds the Assigned Users field where users need to see it. Layouts are per entity and can differ between roles if your design requires it. Open a record as a standard user and confirm the field shows in list views, detail views and edit forms. Missing fields at this stage usually mean the layout was not saved.
Verify role permissions for the new field
Review the roles that create, edit or read records of the enabled entity types. Confirm that users who need to assign or see several owners have the permissions required on the entity and on the field, and that users without those rights cannot widen ownership. Test with at least one account from each role. The check is a test user from each role who can perform exactly the actions the design allows and no more.
Verify filters, searches and reports
Test list filters, saved searches and any reports or dashboards that previously used the single Assigned User field, because they may not return the same records once owners are stored in the new field. Compare results for a set of known records before and after the change. Note any dependent automations, such as workflows or formulas that read the old field, and update them. The check is a documented list of tested views with matching results.
How to migrate existing Assigned User values
Values in the old Assigned User field do not transfer automatically to the new Assigned Users field. Once you enable multiple assigned users for an entity type, existing records will show an empty Assigned Users field until someone fills it. That gap matters most for records that drive routing, reporting and access, so the team needs a dated data step before go-live rather than a clean-up after users notice missing owners. Start by listing which entity types have Multiple Assigned Users enabled and, for each, counting records where the old field is populated. Export the record IDs, the current owner and any teams involved, so you have a baseline to check against after the backfill.
Decide how the new field will be populated, then confirm the method in your own environment. A CSV import in an update mode may be suitable for simple one-owner-to-one-owner copies, and the EspoCRM import documentation describes the update modes and field mapping available. Any more complex logic, such as copying owners across linked records, would need a planned script, and you should confirm with EspoCRM's current documentation and your own tests whether the required approach is supported on your version. Run the entire process on a copy of the production database first, check a sample of records by hand, and record how long the run took. Do not assume the import results are correct because the job completes.
Next, review everything that reads the old field. Reports, workflows, Formula Script logic, list filters and access rules that refer to Assigned User may not behave the same way once the new field is the source of truth. Confirm, for each one, whether it should keep reading the single owner, switch to the new field, or be reviewed by the business owner. Plan the cut-over window so that workflows do not fire on partly migrated data, and decide how new records created during the window will be assigned. Keep the old field values until the reports and access checks have passed in the test copy, and document who signs off that the migration is complete.
What changes in layouts, workflows and reports
Once an entity allows several assigned users, every feature that reads the assigned user has to be reviewed, not just the field itself. The cards below cover the parallel areas that change, and each one names the check to run before users see the new model.
Detail and list layouts
The single Assigned User field is replaced by an Assigned Users field on entities where the setting is enabled, so layouts that place the old field need updating. Confirm that the new field appears in the detail and list layouts for each role that works those records, and that users can read the full set of owners without opening the record. Check the field order on mobile layouts too, since a long owner list can push other fields out of view.
Mass update and import behavior
Mass update and CSV import can write owner values in bulk, and the rules for adding or replacing several users need to be tested with real files. Run a small import into a staging copy with the duplicate matching and update modes your team plans to use, then confirm which owners end up on each record. Existing single-owner values are not carried over automatically, so decide in advance how historical owners will be restored.
Workflows and formula logic
Formula scripts and workflows that refer to the assigned user were written for one owner. Any condition, assignment step or notification that reads the old field must be rewritten to handle a list of users, including records with no owner or with several. Test each before-save script and workflow against a record with zero, one and several assigned users, and confirm the outcome is what the process owner expects.
Reports and filters
Reports, saved filters and grid views that group or filter by the assigned user may return different rows once a record has several owners. Review every report that counts records per owner, because a record can now appear under more than one user. Agree with report owners whether they want primary-owner logic, all-owner logic or a separate view, and verify totals against a known sample.
Access rules based on ownership
Permissions that depend on ownership, such as own-only record access for a role, must be checked against the new multi-owner model. Confirm that a user added as a second owner gets the access the business intends, and that removing one owner does not remove access still needed by another. Test with a non-admin account in each role, since administrator access hides these gaps.
User dashboards
Dashboards built around a user's own records show those records through the assigned user relation, so a co-owned record may now appear on several dashboards. Review each dashboard template that counts open items or lists tasks for a user. Check that workload figures do not double count the same record for every owner without that being the intent, and confirm the dashboards load with real data volumes.
Questions buyers ask before enabling multiple assigned users
Can our own team enable multiple assigned users without a partner?
Yes, a team with EspoCRM administration experience can enable Multiple Assigned Users per entity type in the Entity Manager. The setting itself is a small change. The work that takes time is deciding which entities need it, checking how existing records and layouts behave afterward, and testing permissions with real roles. Teams without an administrator who has built layouts and roles before usually benefit from an outside review of that design before changes reach production.
What drives the cost of enabling multiple assigned users?
The cost follows the amount of configuration and testing, not the checkbox. The main drivers are the number of entity types that need multiple owners, how many layouts, list views, filters, workflows and formula scripts reference the Assigned User field, how many roles and teams need to see shared ownership, and whether existing ownership must be migrated. Each of these adds design and verification work. Ask any provider to price these items separately in the written scope so you can see what each one covers.
How long does the work take for a typical instance?
No duration can be stated without knowing your instance. Duration depends on data volume, the number of entity types in scope, how many layouts and automations depend on the single Assigned User field, and how many roles must be tested. A small instance with one entity type and few automations is a different project from a multi-entity deployment with workflows and reports. Ask for a timeline that lists each entity type, each dependent automation and each test cycle, and confirm which of them your team will carry out.
What happens to existing Assigned User values after the change?
Existing values in the Assigned User field are not transferred to the new Assigned Users field. This means that records which had an owner before the change may appear without assignments in the new field until you migrate them. Plan the migration as a separate step with a documented mapping, a test run on a copy of the database and a verification query or report that confirms every record has the expected owners. Confirm this approach with the vendor documentation for your EspoCRM version before you start.
What must our team provide before the work starts?
Plan to provide the following before the engagement begins: a list of entity types that need multiple owners, a role matrix showing who can view, edit and reassign records, a copy of production-like test data, named business owners who can approve test results, and access to the staging environment. Without the role matrix and test data, verification becomes guesswork. Sign-off should be written, with each entity type and each dependent layout or automation listed as accepted or deferred.
Which layouts, filters and automations usually need changes?
Anything that reads or writes the single Assigned User field is a candidate for review. This commonly includes detail and list layouts, search filters, saved views, dashboards, workflows, formula scripts and before-save scripts that set or check ownership, and any integration that writes to the Assigned User field through the REST API. Build an inventory from your instance before you enable the setting, so you can see which items must be updated, which can wait and which can be retired.
Is a fixed-scope engagement typical for this kind of work?
Fixed-scope engagements are common for this type of change because the boundaries are clear: named entity types, a defined migration, agreed test cases and a set list of layouts and automations. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and most engagements follow that pattern. Ongoing support after go-live is available as a retainer if your team wants help with later changes. Ask for a written scope that names what is excluded so there are no surprises at sign-off.
How DeployOpen scopes multiple assignment work
DeployOpen plans multiple assigned users as a fixed-scope piece of an EspoCRM implementation. Before any build starts, the written scope names each entity type that will accept more than one owner, the layouts that will show the new Assigned Users field, the rules for moving existing single-owner values, and the tests that prove the result. The quote follows from that scope, so the decisions that drive cost are visible to you before work begins. Those decisions include how many entity types are involved, how many layouts and roles must change, and how much existing data needs a migration rule.
The scope should also record who is accountable for each decision. Ask who owns the list of entity types that will be enabled in the Entity Manager, who confirms whether the default cap of 10 users per record fits your teams, and who signs off on how records that previously had one Assigned User will be handled. The fact that existing values are not transferred to the new Assigned Users field means your migration rule must be written down, not assumed. Your team also needs to confirm which reports, workflows and list filters still depend on the old field, since those are easy to miss in a scope that only lists layouts.
Ongoing support is available as a retainer for teams that want help after go-live, such as reviewing new entity types, handling later layout changes or checking behavior after an upgrade. A retainer is separate from the fixed-scope work and is priced from its own written terms. DeployOpen does not claim certifications or partner status for this work. Ask for the written scope, the test list and the retainer terms together so you can compare them with the cost of doing the same work with your own team.
How DeployOpen delivers EspoCRM assignment changes
DeployOpen plans and implements EspoCRM inside your own infrastructure, so changes to how records are assigned are scoped in writing before any work starts. The work covers the entity types you choose, the layouts and permissions that follow, the migration of existing assignments and the handover your administrators need to run it.
How we scope
- Written scope lists which entity types will allow multiple assigned users and why each one needs it.
- Scope records the current Assigned User values, the teams and roles that depend on them, and the reports affected.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work begins.
How we build
- Enable Multiple Assigned Users per entity type in the Entity Manager on a test instance first.
- Review the default maximum of 10 users per record against your team sizes and confirm whether it fits.
- Adjust layouts, filters and access rules so the new Assigned Users field behaves as your teams expect.
How we hand over
- Migrate existing single-owner values into the new field with a tested script, since the old values do not transfer automatically.
- Test assignment, permission and reporting results with your sample records before production cutover.
- Deliver written runbook notes on enabling the feature, changing the limit and reverting a failed change.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover checks of assignment behavior when EspoCRM versions change in your environment.
- Ask your support provider to confirm response terms and how changes to the 10-user limit are handled.
