Simplify the process of managing incoming emails, creating conversations, and handling tickets by using DevRev’s Email integration snap-in. DevRev integrates with a variety of providers like Google Workspace, Microsoft Outlook, Yahoo Mail, Zoho Mail, and custom domains, allowing efficient handling of any organizational email directly within the app.
For configuration instructions, refer to Email snap-in configuration.
For more information, refer to the Email snap-in on the DevRev marketplace.
Conversation and ticket creation for emails
When an email is received, DevRev checks if the sender is linked to your workspace and creates a conversation or ticket. If a sender is not recognized, DevRev creates a new user profile to track interactions (Support > Inbox for conversations and Support > Tickets for tickets). All replies are sent from your organization’s own email addresses, maintaining a professional and personalized customer experience that strengthens your brand and fosters better engagement. This method builds trust with mailbox providers and recipients across any email service, reducing spam flags and protecting your brand identity by adhering to DMARC standards.
You can choose for an email address that messages to it create either a conversation or a ticket, but not both simultaneously. Whether to create a conversation or a ticket depends on the nature of the emails received at a specific email address.
Read more about conversations and tickets to decide which is more suitable for your use case.
When needed, you can link a conversation to a ticket. This is particularly useful if you decide to use conversations for all your communication requirements.
The visibility and interaction capabilities with a ticket in DevRev are determined by the user's role and how they were added to the email thread.
End users
-
Original sender
Added to: Reported by or Email members field.
Is able to: View the ticket on the portal and reply via email.
-
An end user in the same organization
Added to: To or CC fields in the email thread; Reported by field, Email members field, or @mentioned in the DevRev app.
Is able to: View the ticket on the portal and reply via email as an email member.
-
A customer admin for the same workspace
Added to: Customer Admins group.
Is able to: View the ticket on the portal once their workspace is updated on the ticket.
-
An end user outside original sender's organization
Added to: To or CC fields in the email thread, or mentioned in the DevRev app (adds them to CC).
Is able to: Reply to the ticket via email. They cannot view the ticket on the portal, as they are added to the Email members field but not to the Reported by field.
Employees
-
With DevRev account (added to email thread)
Added to: To, CC, or Email members field.
Is able to: View the ticket on DevRev, reply via email, and receive in-app notifications. If they make changes to ticket attributes, they remain subscribers.
-
Manually added subscribers
Added to: Subscribers field.
Is able to: View the ticket on DevRev and receive in-app notifications.
-
Without DevRev account
Added to: Email members field as subscriber.
Is able to: Reply to the ticket via email.
Email deliverability status
The sender of an email is able to view the status of an email. Additionally, the sender can view if their email has bounced, along with details about the bounce event.
Below are the various possible states of an email.
- In Transit: This email is now queued for outbound. DevRev is attempting to send this email, and the process is currently in progress.
- Sent: DevRev has successfully sent this email. At this point, the email is on its way to the intended recipient.
- Delivered: DevRev has successfully delivered this email to the recipient's email server.
Even if DevRev delivers the email, the recipient's email server may quarantine the email, or it may end up in the recipient's junk or spam folder. Despite this, DevRev still registers a Delivered event, as the email has reached the intended recipient's server.
- Bounce: The recipient's email server rejects the message, which can happen for several reasons. These may include the email address no longer existing, a typo in the address, or the email failing to meet the recipient server's security policies. The specific reason for the bounce is detailed in the Bounced event. The sender is notified whenever their email bounces.
Email experience from an end user perspective
Customers can initiate communication in two ways:
- By emailing your support address: Automatically creates a ticket or conversation in DevRev.
- By submitting a ticket via the DevRev Customer Portal: Generates email notifications for replies.
Depending on the source channel (email or portal), email behaves slightly differently:
Even when a reply comes via email, it’s always synced into the customer’s portal view.
Email experience from an support agent perspective
With DevRev’s email integration, support agents can seamlessly handle email conversations within the support interface—replying to customer messages, managing threads, and configuring personal email settings. Here's a breakdown of key tools and capabilities available to agents:
Email notifications
Agents can configure how and when they receive email notifications through Settings > Notifications.
- Each notification type—such as being assigned, mentioned, or when a customer esponds—can be toggled for both in-app and email delivery.
The email composer in Tickets
Inside every ticket, under the Customer Messages tab, agents can access a fully featured email composer. This allows direct email communication with customers from within DevRev.
Here’s what the email component supports:
If a user doesn’t belong to the organization or is deleted, ensure to remove them from the Reported By field to avoid delivery errors.
Email Bounce Prevention Tip
If an email fails to deliver, it may be due to:
- A deleted user listed as a reporter
- Invalid or unverified recipients in the To or Cc
Threading
Email integration preserves threading by using the References and In-Reply-To email headers and by correlating the email Subject field and the ticket title. If either the ticket title or the email subject is changed at any point after ticket creation, follow up emails may cause a new ticket to be created.
Once a ticket is created from an email, it is recommended to avoid changing the email subject or the ticket title.
Specifically, threading breaks when the order of words in the subject is changed, when words are replaced, or when words or symbols are inserted in the middle or appended. Threading is maintained if the subject change is limited to the addition of words before :, words between [], words between ##, or common prefixes, such as Re or Fwd.
Rate limiting
To ensure that your support system is protected from potential spam attacks as well as from issues arising due to mail loops, the email integration has the provision to specify user-specific email limits. By default, the user-specific limit is set to 30 emails per 10 minutes.
If a user sends 30 emails in a 10-minute time frame, this particular user is marked with the tag spammer. Once marked as a spammer, the user can only send 100 emails in a 24-hour period. All of these emails are marked as spam by the system. Any emails beyond the 100 spam email default limit are dropped, and the blocked tag is added to the user. The user can be removed from the spam list by navigating to the contact and removing the spammer tag from the contact.
If you want to allow a user to send emails without rate limits, add the power-user tag to the user.
By providing explicit tuning for specifying the rate limit, DevRev ensures that legitimate support emails are not affected by potential spam attacks or mail loops.
