Stardate about 2 weeks ago… I was working happily on an integration, moving data from a legacy system into a shiny, brand new, CRM 2011 in the cloud instance. All the columns were mapped and methodically tied together; the attachments being moved were ready for transport. This integration job may as well have been wrapped in a pretty red metaphorical bow with shiny lettering reading “NCC-1701”. “Ready to depart,” I had thought.
The integration was off at maximum thread count!
Complete! The job finished quickly enough. After initial inspection, all the records were accounted for, with status set appropriately. Heck, after doing a 1-to-1 compare in Excel from the legacy system to the new system, everything was to the character (as I would expect…)
Until I opened a handful of sample records. A bug had popped up. All the text in the body of the email was wrapped. All carriage returns aka new line, aka line feed, aka break line, aka CRLF, etc. had been removed!
How could this be? That code was so good it may as well have been written in stone!
Before we go any further into the issue at hand, a little bit of background…
The legacy system housing this data did not store it in html markup (formatting). What we did find (upon further analysis) was that there were a specific number of spaces that indicated a carriage return. So, we had done a replace on that sequence to give us our desired results. We used “\r\n” to replace the specific number of spaces. This had worked splendidly on a handful of draft test records we created.
Fast forward to our current bug. The next step was to see how widespread this issue was. After more research, it appeared to be across the board. So, the next logical step was to step through the creation of one of these records. While stepping through, we found the results again to be correct. At the same time we noticed incoming emails using the Outlook add-in were maintaining their formatting just fine.
After an attempted bug fix, our next thought was to turn the document body of the email into html formatting. Easy enoug, right? First we would add the appropriate html wrappers, and then, instead of using the “\r\n”, we would use “< br />” which is a line break. “If Outlook can do it, so can we,” we thought.
Needless to say, this attempt also did not work. Back to the drawing board!
We stepped through the code and sample record being created and noticed something peculiar. When the record was created, it kept all of the formatting just fine. It was only when the record was being marked with a status of “sent” that our masterfully placed carriage returns were being removed.
So, we tried changing the status of the email record to “draft” from “sent” to see if formatting was kept after being marked as “sent”. To our surprise, the formatting was kept. This meant was there was no loss in terms of the information being stored in CRM.
“Fascinating is a word I use for the unexpected.” –Spock
This was fascinating, as defined by Mr. Spock, a most unexpected result. I decided to investigate, using Internet Explorer to review a record missing its beloved carriage returns. (To do this, open the record and press “F12”. This should bring up an additional window that allows you to browse the HTML, CSS, Script, etc..)
Side Note / hat tip: Should be the same key across IE, Firefox, & Chrome (gotta love cross browser support)
Upon further investigation, one line of css stuck out in particular “White-space: normal;”. Upon consulting wc3 schools, the normal tag is the default for white-space property. When you remove this tag from the default css the document body is formatted normally.
- White-Space tag: The white–space property specifies how the white-space inside an element is handled
- Normal option: Sequences of whitespace will collapse into a single whitespace. Text will wrap when necessary
The solution to this problem should now start to become clearer. The html in the document body must include a tag that negates the white-space tag from the default crm css. To accomplish this, add the style=“white-space: pre;”.
While this situation is probably just an edge case, it is quite vexing.
Have you run into this issue? Did this article help you out? Feel free to leave a comment, or contact us.