How an EspoCRM shared inbox keeps team email tied to customer records
When replies to a customer go out from personal mailboxes, the team loses track of who answered what, and the conversation never reaches the customer record. A group email account in EspoCRM fixes this by letting a shared address such as sales@, support@ or billing@ be fetched into the CRM, linked to the right records and answered from one place. The point of the setup is that the next person handling an account can see the full thread without asking a colleague for a forwarded copy. Teams usually need this when several people answer the same address, when customers expect a consistent reply from a function rather than an individual, or when a departing employee would otherwise take their correspondence with them. A personal account is usually enough when one person owns a relationship and no one else needs the history.
Before building the shared inbox, decide which functions need their own address, who should see each mailbox, and whether replies should appear to come from the group address. In the EspoCRM documentation, group accounts are set up by an administrator, and access to what arrives in them depends on the teams and roles assigned to the users who work the mailbox. Confirm with your own environment how fetched messages are assigned to records, how followers are notified, and whether a reply sent by one team member is visible to the others in the same thread. Also confirm which mail protocol your provider exposes for the group address, since this determines the connection settings you will need before any fetching starts.
Plan for the risks that come with a shared address. Mail that arrives in a group account may contain personal data, so the access model should match who legitimately handles that data, and the mailbox credentials should be held by an administrator rather than shared on a sticky note. Test the setup with a sample mailbox before pointing it at a live address, and check that messages land on the expected records and that replies come from the intended sender. Ask any implementation partner to write the mailbox list, the team assignments and the test results into the scope before work begins, so that the design can be reviewed by the people who will live with it.
Choosing between personal, group and shared mailbox setups
A personal account connects one user's mailbox to EspoCRM, so that user sends and receives mail under their own address. The mail belongs to that person's login, which makes this setup a natural fit for account managers and sales representatives who handle their own conversations.
- Visibility: Messages are tied to the owner's account. Colleagues see a message only when it is linked to a record they can access or when permissions and teams allow it.
- Replies: Replies go out from the individual's address, which keeps one-to-one relationships personal and easy to follow.
- Authentication: Each user authenticates to their own mailbox. Offboarding must remove or disable that connection, or the mailbox stays linked.
- Coverage gaps: When the owner is on leave or away, incoming mail waits in that mailbox unless someone else has a legitimate way to read it.
Before choosing this model, confirm how your offboarding process handles connected personal accounts and whether customers expect replies to come from a named person.
A group account is one mailbox, such as sales@ or support@, configured once in EspoCRM and used by a team. Incoming mail is fetched into the system and can be assigned to the team, so several people can work the same queue without sharing a password.
- Visibility: Mail is visible to the users and teams granted access to the group account, which makes it easier to see the whole queue in one place.
- Replies: Team members can send replies from the group address, so customers see one consistent sender identity.
- Authentication: The connection uses one set of mailbox credentials held by administrators. Credential rotation and access to the stored secret need a named owner.
- Team fit: This model suits shared queues where several agents or reps handle the same stream of requests, and where no single person should be the sole point of contact.
Before relying on a group account, confirm which EspoCRM users can send from it, how replies are attributed internally and who rotates the mailbox credentials when staff change.
A provider-side shared mailbox is created in Microsoft 365 or Google Workspace, where the provider manages membership, permissions and sign-in policies. EspoCRM then connects to that mailbox as an integration, so the identity controls live with the mail platform rather than inside the CRM.
- Ownership: Membership and delegation are managed in the provider's admin console. Adding or removing a team member happens there, not in EspoCRM.
- Authentication: The connection relies on the provider's supported sign-in methods, such as OAuth through the Google or Outlook integration, rather than stored mailbox passwords. Your tenant's policies determine which methods are allowed.
- Sign-in controls: Multi-factor authentication, conditional access and audit logs apply to the mailbox at the provider level, which can simplify evidence for access reviews.
- Reply identity: Sender display names and aliases are set on the provider side, so changes made there need to be checked against what EspoCRM sends.
The connection steps for each provider are covered on the Google and Microsoft pages. Before committing, ask your administrator which connection methods the tenant permits and whether the shared mailbox supports the access EspoCRM needs.
The right model depends less on the tool than on who owns the conversation and who replies to it. Writing down the owner, the people who reply and the people who must see the mail usually points to one model, and many organizations end up combining two of them.
- Small teams with named owners: Personal accounts keep setup simple when each person manages their own customers and the team has few handoffs.
- Shared queues with many agents: Group accounts fit sales@ or support@ style inboxes where any qualified person may pick up a message.
- Central IT control or audit demands: Provider-side shared mailboxes suit organizations that already manage sign-in, membership and logging in Microsoft 365 or Google Workspace.
- Hybrid setups: A group account for public addresses combined with personal accounts for account managers is common, provided the linking rules are clear.
Before choosing, map each mailbox to its owner, its replying users, its viewers and the step that removes access when someone leaves.
Configuration options and when each fits
This table compares the main settings a shared inbox depends on, such as group versus personal accounts, fetch scope, team assignment and reply-from identity. Read each row as a decision: the first column names the setting, and the other columns say when it fits and what it costs you. Confirm exact labels and defaults in your EspoCRM version before you write the configuration down.
| Setting | When it fits | Main trade-off |
|---|---|---|
| Group email account | Shared addresses such as sales@ or support@ that several people answer and that should not depend on one person's login | Replies and sent mail can be attributed to the group, so the team needs clear rules for who answers which thread |
| Personal email account | A single owner who works a mailbox directly and needs their own history, signatures and sent items | The mailbox goes quiet when that person is away, and colleagues cannot see the thread without a manual handover |
| Fetch scope and start date | Limiting intake to recent mail so the first sync does not pull years of old correspondence into records | Mail older than the fetch start is not linked automatically, so historic threads need a separate import or manual linking |
| Folder selection | Monitoring only the folders that matter, such as the inbox and a support subfolder, and ignoring newsletters or internal traffic | Mail filed into an unmonitored folder by a rule elsewhere never reaches the CRM, which is a common cause of missing messages |
| Team assignment | Routing work to a sales or support team so that members with the right responsibility see new items | Broad team visibility spreads work thin, and narrow assignment can leave items without an owner during absences |
| Reply-from address | Replies going out under the group identity so customers see one consistent sender and thread continuity | Staff need to be trained to reply from the group context, and mixing personal and group sending can split conversations |
| Notify followers | Alerting people who follow a record or thread when mail arrives, without waking the whole team | Heavy follower lists create notification noise, and people who are not following may miss urgent mail |
| Linking to accounts, contacts, leads or cases | Attaching each message to the record that matches the sender so history stays in one place | Automatic matching depends on known addresses, so unknown senders may need manual linking or a lead or case created first |
Setting up a group email account in EspoCRM
This sequence takes a shared mailbox such as sales@ or support@ from provider access through to a trained team, with each step closing on a check you can run. The result is a group account that fetches, sends and links mail to records the way your team expects.
Confirm mailbox and provider access
Before touching EspoCRM, confirm who owns the shared mailbox, which protocol the provider supports for IMAP and SMTP, and which account will authenticate. Ask your mail administrator whether the group address needs a dedicated service login, whether multi-factor authentication applies, and whether the provider restricts connections by IP address. If you plan to use an official Google or Microsoft integration instead of plain IMAP, confirm that tenant policy allows it. Done when you can log in to the mailbox with the intended credential from a test client and see the existing folders.
Create the group account for the owning team
In EspoCRM, create a group email account for the address and assign it to the team that serves it, so visibility follows the team rather than one person. Enter the IMAP and SMTP server, port and encryption settings from your provider, and store the credential as the account owner intends. Keep daily users out of admin roles and confirm the team membership matches the people who will work the queue. Done when the account saves without a connection error and appears under the correct team in the account list.
Set fetch and folder behavior
Decide which folders EspoCRM should fetch, how far back the first fetch should reach, and whether the mailbox has an archive or spam folder that should be excluded. Set the fetch start so historical mail does not flood the team with old threads, and note that the first pass is where most unwanted volume appears. Confirm that background jobs are running on a schedule, since EspoCRM relies on cron for fetching. Done when a manual fetch brings in the expected folders and the message count matches what you see in the provider's web interface for the same window.
Test inbound and outbound mail with a known thread
Choose an existing thread that already has a customer, a related record and a prior reply. Send a new message to the group address from an outside test account, then reply from the EspoCRM group account to that thread. Check that the inbound message arrives once, that the outbound reply leaves from the group address with the correct display name, and that the reply lands in the same conversation in the customer's mail client. Done when the thread shows both messages in EspoCRM, the sender and recipient headers are correct, and no duplicate copies appear.
Verify linked records and follower notifications
Confirm that each inbound email attaches to the expected record, such as an account, contact, lead or case, and that the team can see the linked item from its own view. Add a test follower to a record, then send mail that touches it and check that the follower receives the notification and that the group address is not notified in a loop. Review whether replies from individual team members are linked to the same record. Done when linked records show the full conversation and the follower gets exactly one notification per relevant email.
Check permissions and visibility for the team
Sign in as a team member who should see the shared inbox and as one who should not, then confirm which emails and linked records each user can open. Verify that a user outside the team cannot read the group mailbox's messages or send from the group address. Confirm that personal mailboxes stay private to their owners. Done when the visibility results match the access model you wrote down in step two, and any gap is corrected before users are onboarded.
Train users on the shared inbox workflow
Walk the team through how to take ownership of a message, link it to a record, reply from the group address, and hand a thread to a colleague. Show them where follower notifications appear and what to do when a message is not linked. Give them a short written procedure they can keep next to the queue, and agree on who reviews unlinked mail each day. Done when each team member has sent one reply from the group address during training and the owner of unlinked mail is named.
How replies go out from the group address and stay linked
The reply path decides whether a shared inbox works in practice. A team member answers an incoming message from the group address, EspoCRM stores that outgoing message against the related record (a lead, account, contact or case), and other members see the exchange when they open that record. Your job before go-live is to confirm each link in that chain in your target version: that the reply is sent from the group account rather than the individual's personal mailbox, that the message is saved against the right record, and that the thread shows up for colleagues who did not write it. Treat the group address as a configured sending identity, not as a convenience alias, and test it with a real reply from each team member's login.
Sender identity and signatures need explicit decisions. Ask whether replies should show the group name only, the group name plus the agent's name, or the agent's name with the group address as reply-to. Personal signatures are typically attached per user, so confirm whether the group account applies its own signature, whether agents can insert their personal one, and whether that signature leaks into replies sent from the shared address. Also confirm how the reply is threaded: EspoCRM matches inbound and outbound messages to records using the email addresses and message identifiers it sees, so a reply from a different address, a forwarded message or a changed subject line may create a new email instead of joining the existing thread. Write down the matching rules you accept and the cases you will handle manually.
Reply threading, sender behavior and linking are version-sensitive, so they must be tested in the target version before rollout, not assumed from documentation or from this page. Build a short test script: an inbound message from an external sender, a reply from two different team members, a forwarded message, a reply with a changed subject line, and a message from an address already linked to a contact. Check the sent header, the stored record link, the visibility for followers and the notification each person receives. Confirm with your EspoCRM administrator or the release notes for your version whether any of these behaviors changed, and repeat the script after every upgrade.
Security and access controls for a shared mailbox
A group mailbox concentrates customer correspondence in one place and often one login. The cards below cover who can read that mail, how the mailbox credentials are held, and which EspoCRM controls reduce exposure. Each check should be confirmed in your own instance before the group account goes live.
Group mail visibility
Anyone who has access to a group email account can read its messages and the records they are linked to. This is by design, so the group is the unit of access, not the individual user. Before go-live, list every user, team and portal user that can open the group account and its linked emails, and confirm that no one outside the support or sales function is included by accident.
Storing group mailbox credentials
A shared mailbox usually authenticates with one password or one OAuth grant held by the instance. Confirm where EspoCRM stores the mail credentials, who can view or replace them, and whether the database and backups that hold them are restricted to the same people. Ask your team which identity owns the grant, because revoking a grant owned by a departed employee can silently stop mail flow.
Rotating mailbox secrets
Plan rotation for the mailbox password or OAuth client secret, and record who performs it and how the change is tested. Rotation should be followed by a test fetch and a test send from the group address. Document the steps in your runbook so the change does not depend on one administrator's memory.
Keeping admin accounts out of mail setup
Configuring a group account is often done by whoever holds the administrator role, which exposes the admin session to a daily mail workflow. The EspoCRM security guidance recommends avoiding admin accounts for daily work, so create a dedicated setup account or a scoped role for mail configuration, and keep the administrator login for infrastructure changes only.
Two-factor authentication and password policy
Staff who read the shared inbox should sign in with a strong password policy and two-factor authentication, since a compromised user session exposes every linked email. EspoCRM's own 2FA is not compatible with OIDC sign-in, so confirm how your identity setup covers second factors. Limit token lifetime so idle sessions on shared workstations expire.
IP restrictions on the instance
Restricting access by IP address limits who can reach the CRM login page and the API, which matters when mail is visible from many locations. Confirm the allowlist covers office and approved remote networks, and check that API users used by integrations are included in the policy. Test the rule from outside the allowed range before relying on it.
Limits to confirm before you commit to a shared inbox
A shared inbox in EspoCRM depends on what your mail provider allows, how your EspoCRM version handles threads and folders, and whether the automation you want sits in the core product or in the Advanced Pack. Confirm each item below in your own environment before you agree a scope, because the answers change the design more than the feature list does.
Provider access for IMAP and API
Your mail provider decides whether EspoCRM can read and send through the group address at all. Check whether IMAP and SMTP access is enabled for the mailbox, whether the provider requires OAuth rather than a password, and whether it applies its own connection or request limits. Ask the provider in writing, then test with a copy of the real mailbox. Provider rules change, so confirm them on the day you plan to go live.
Fetch behavior for large mailboxes
Shared inboxes such as support@ often hold years of history. Confirm how EspoCRM fetches a mailbox on first connection, whether it pulls everything or only messages after a chosen date, and how long the first sync takes. Background jobs run through cron or a scheduled task, so a backlog can delay new messages. Ask your team to agree the fetch start date before the connection goes live.
Attachment storage decisions
Decide whether attachments from the group mailbox are kept inside EspoCRM storage, moved to external file storage, or left on the mail server. Storage growth from a busy inbox can exceed what teams expect. Check your backup plan covers attachments, and confirm where personal data in attachments falls under your retention rules before the inbox starts receiving customer files.
Folder and thread behavior in your version
Folders, threading and how replies attach to existing emails differ between EspoCRM releases. Test with a sample conversation: send a reply from the group address, reply from a second mailbox, and check whether both stay in one thread on the record. Record the exact version you test on, because the EspoCRM 10.0.0 release is the baseline for any upgrade plan.
Notification volume for followers
Every follower on a busy shared address can receive a notification for each incoming message, so a team of followers may produce a large volume of alerts. Decide who follows which group account, whether notifications go to individuals or to a team, and how quiet hours or filters will be handled. Ask your team to run a one-week trial with a small follower group before rolling out to everyone.
Dependence on the Advanced Pack
Some routing, reporting and process automation around a shared inbox relies on the Advanced Pack, which provides Workflows and Business Process Management. Confirm which of your required behaviors work in the core product and which need the add-on. Advanced Pack is included in all EspoCRM Cloud plans, but a self-hosted deployment needs its own license decision, so get that answer in writing before you design the automation.
Questions teams ask before running a shared inbox in EspoCRM
What drives the cost of setting up a shared inbox in EspoCRM?
The main drivers are how many group addresses you need, how many providers they sit on, and how much the inbox must do beyond receiving and filing mail. A single group account on one provider with simple linking to records is a small job. Each additional mailbox, each provider with its own authentication rules, and each rule for who sees what adds configuration and testing. Costs are one-time for design, configuration and testing, and recurring only where someone keeps credentials, provider settings and permissions current. Ask any quote to itemize mailboxes, providers, record-linking rules and the test plan separately, so you can see which items change the price.
Can our team set up a shared inbox in EspoCRM without outside help?
A technically confident administrator can often configure a single group account by working through the EspoCRM mail settings and the administration documentation. The harder parts are the ones that are easy to get wrong quietly: mailbox authentication, which folders are fetched, how emails attach to records, and who is notified when a message arrives. If nobody on the team has tested inbound and outbound mail against the real provider, plan for that gap. Outside help is most useful for the design decisions and the verification pass, not for clicking through screens.
What do our mail administrators need to provide?
Your mail administrators need to create or confirm the group mailboxes, decide how they will authenticate, and provide the IMAP and SMTP details the provider requires. They also need to confirm that the sending address is allowed to send on behalf of the group, that any mail flow or forwarding rules do not duplicate messages, and that the account is not tied to a single person who might leave. Ask them to confirm the provider's current rules for app passwords, OAuth or basic authentication, since these change and determine what EspoCRM can connect to.
How long does testing take for a shared inbox?
Testing time depends on mailbox volume, the number of mailboxes and the provider's authentication and throttling behavior. A low-volume mailbox can be checked in a short cycle, while a busy support address needs a longer period to confirm that fetching, threading and notifications hold under real traffic. Test inbound, outbound, reply threading, attachments, notifications and what happens when a provider rejects a connection. Ask any partner to state the test plan and the volume it covers, and treat a duration without that context as unsupported.
Is the open-source edition of EspoCRM enough for a shared inbox?
The open-source edition is free to download and self-host under AGPL-3.0, and the core email features needed for group accounts are part of the platform. Whether it is enough depends on what else you need. Reports, workflows and business process automation come from the Advanced Pack, which is included in all EspoCRM Cloud plans, so self-hosted teams should check whether they need those capabilities for routing or follow-up. Confirm the exact feature set of the edition you plan to run against your requirements before you commit.
What changes when we later add email-to-case?
Email-to-case adds rules that turn inbound messages into cases, decide which team receives them and thread replies into existing cases. It also changes what your group address must handle, because replies need to go back through the group account and automatic responses need loop protection. Design the shared inbox with that path in mind: consistent group account settings, clear ownership of each address, and a naming scheme for teams. Doing this early avoids reworking mailbox settings once cases depend on them. The email-to-case topic covers the case-specific steps.
Who should own a shared inbox after go-live?
Assign a named business owner for each group address and a technical owner for its credentials and provider settings. The business owner decides who follows the inbox and what counts as a completed reply, while the technical owner handles password rotation, provider changes and failed fetches. Without both, a mailbox often breaks silently after a password change or a provider policy update. Ask any partner to describe how this ownership is handed over and what runbook the team receives.
What DeployOpen confirms before building a shared inbox
Scope for a shared inbox is agreed in writing before any mailbox is connected, because most of the later rework comes from unclear answers to a few questions. The first is the mailbox inventory: every address that will act as a group account (sales@, support@, billing@ and similar), whether each one is a true shared mailbox or an alias that forwards to a set of people, and which of them need outbound sending from the group address. The second is provider access: which mail provider hosts each mailbox, whether IMAP and SMTP credentials or an OAuth-based integration will be used, who holds the account that authorizes access, and whether the provider permits the access method your security team has approved. Confirm these with your mail administrator before the design starts, since authentication options differ by provider.
The second paragraph covers the internal rules that EspoCRM cannot infer on its own. Name the team that owns each group account and the users who may read, reply and move messages. Decide which record types an incoming email may link to (accounts, contacts, leads, cases or opportunities), and what happens when a sender matches more than one contact or none at all. Agree who becomes a follower of a conversation and which notifications they receive, and whether a reply sent from the group address should be recorded against the same record. Write these decisions down as the design baseline, because each one maps to a team, a role or a linking setting that must be configured and tested.
The third paragraph covers testing cases and commercial terms. Ask DeployOpen to list the test cases it will run before handover, such as an inbound message from a known contact, an unknown sender, a message with several recipients, a reply from a team member who is not a follower, and a message sent to the group address from a personal mailbox. Agree the acceptance criteria and who signs them off. Engagements are fixed-scope: deliverables, timelines and responsibilities are written into the agreement before work starts, and DeployOpen does not publish a price list. A quote follows from that written scope, so the more complete your mailbox inventory and rules are at this stage, the more accurately the quote reflects the work involved.
How DeployOpen delivers EspoCRM shared inboxes
DeployOpen plans, configures and hands over group email accounts in EspoCRM inside your own infrastructure, starting from how your teams actually share and answer mail. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory every shared address, its owners, its volume and the teams that answer it
- Define which mailboxes are group accounts, which stay personal and who can send as each address
- Agree in writing how emails link to accounts, contacts, leads and cases in your records
- Confirm the mail server, authentication method and folder structure before any build begins
How we build
- Configure group email accounts, folders and fetch settings in a staging instance first
- Set follower and assignment notifications so the right people see new and replied threads
- Test replies sent from the group address, including how they land in the sent folder and thread
- Document each setting and keep changes tied to a reviewed configuration record
How we hand over
- Deliver a runbook covering mailbox setup, linking rules, notification settings and known limits
- Walk administrators and team leads through daily triage, reassignment and folder use
- Record which mail server credentials, app passwords or OAuth consents belong to which owner
- Agree acceptance tests with your team before the engagement closes
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer
- Review mailbox fetch errors, notification gaps and new shared addresses on a schedule you agree
- Plan EspoCRM version upgrades with the group email configuration checked before and after
- Ask any provider for written response expectations before relying on them for customer mail
