On this page

Email

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.

icon

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 a 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.
    icon

    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.

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.

icon

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.