Email Scrubber

Before we delve into the Email Scrubber solution, let’s review how Email Messages are stored.

Take a simple example.

Let’s take a simple example of a client looking for some refrigerator support.

The client initiates a support request by sending an email to the support email address (1). The email is routed to email-to-case which creates a new case and a related email message record.

The support agent responds to the original client email (2). The original email body is copied into the response. The entire conversation history is stored in a new email messages record related to the original case.

The conversation thread continues until the support representative sends an email response indicating that the replacement part has been shipped (7). This email conversation thread has created a total of 6 email messages (each containing the prior’s entire conversation history).

During the email exchange, another support representation starts a new conversation history by sending a response to the repair request (5). This starts a new conversation branch (which can be lost in the clutter).

Is this really an issue?

Is this an issue? If your conversations histories do not typically branch and your data storage is adequate, then no, its not necessarily an issue. The problem arises when you notice Email Messages growing exponentially and consuming the majority of your data storage. Worse, when Email Message growth requires the purchase of additional data storage.

But its just an email. Why does it take up so much space?

As mentioned previous, the entire email conversion history is saved over and over again. This creates a large volume of redundant data. But its not the only factor:

  • Modern HTML emails are simply bloated.
  • In order to comply with email requirements, both the plain text and HTML version of the email body are stored in email message records. However, this is really only a short-term requirement.
  • Many of the data fields in the email body, envelop, and email header(s) are extracted into fields.
  • Email Header(s) are stored on the Email Message. (see Should I save email header(s)? Honestly, in most implementation, storage of email header(s) is given too much credit for consuming data storage).

Ok, got it. But if we run out of space, I’ll just purge data.

Purging data is absolutely a viable solution if your use case and compliance processes allows for purging. But if you want to be more precision with your purging (or more precision with your solution), we recommend Email Scrubber.

Ok, I’ll bite, what’s the Email Scrubber solution?

Glad you asked. Email Scrubber crawls through email message records to classify email messages are Current (i.e. have the most recent conversation history data) or Redundant (i.e. the conversation history data is contained in a future email message record).

In our previous example, Email Scrubber will determine that (5) and (7) are current, while (1), (2), (3), (4), and (6) are redundant.

Email Scrubber will flag these records accordingly for further processing.

Interesting. What does further processing mean?

Well, further processing could mean a number of things based on your implementation needs. Some standard options include:

  • Precise Purge: Only purge email messages flagged as redundant along with your own custom purging criteria. For example, purge all the redundant email messages on cases closed more than 3 months (keeping the current email messages intact).
  • Precise Archive: Only archive email messages flagged as redundant along with your custom archiving criteria. For example, archive all redundant email messages on cases closed more than 6 months for product X.
  • Simplify Data Storage: Migrate simplified redundant data into a custom related object. For example, move only the HTML body of the email into a custom related object.

Ok, I’m officially interested.

Interested? Give us a ping to learn more. Schedule a free analysis and impact estimate of your implementation. Or check us out on the App Exchange.