CRMOnline: The Case of the Rolling Roll-ups
CRMOnline. I personally (and professionally) love it. I use it. I have many clients that use it. It’s a great thing. Because of many factors, but probably mostly because of pure scale, CRMOnline gets updates on a rolling basis. With on premise we do roll-ups on our own: we get notice, we download, and we push go. But since Microsoft hosts the online instances, they do those things on our behalf. Not a bad deal really. (In my head I imagine some big huge server room with a drone that moves from machine to machine pushing go on the updates and just an ever moving update machine until all instances have been updated and then the drone starts all over again.)
This is normally no problem. These updates for the most part are subtle. We got a load (LOAD) of updates in November, but other than that, really not things you’d notice unless you were waiting for them. I want to think that is by design. CRMOnline is a solid product, but why not use the technology available to implement those tweaks, hot-fixes, upgrades, etc on a more regular basis. Most CRMOnline users don’t juggle several instances like I do. But as more and more xRMy things are out there, more and more people will have a development environment and a production environment. It’s the smart way to work when you do things of any scale.
I had a “simple” data conversion and implementation gig last week. The firm was pretty much CRM for the sake of CRM. Add a few basic custom attributes here and there, but no special code or anything that would make you think twice about possible hiccups. I did the customizations, a few text fields, some money items, some dreadfully long picklists. Customer logged into our dev environment said the customizations looked perfect, push to production. It’s what we all love to hear.
So I export. On my attempt to import I get this error.
Ugly ain’t it?
It didn’t make any sense. I wasn’t doing much, especially to leads. It was a dozen or so new attributes and no changes to mappings. So I quit. Try it again, maybe it was a wrinkle in the matrix at that exact moment in time and it would be fine on my next try. No such luck. Ok, re-export and try again. Yes, I was beginning to curse.
The error talks about mappings. I now do a line by line compare of the mappings between the sending and receiving instances. Low and behold, the sending CRM has more items mapped, system mappings. This tells me that the receiving system had not yet gotten the same updates at the sending system. Ugh.
Submit support ticket. The folks at support are great, but I get the feeling they had never encountered such a problem. Oh, this is a holiday week AND the client had a hard stop on their old system that was 4 days away. Several frustrating communications and escalations later, we had determined it is not mappings, it is address fields. The error mentioned address fields, but it was at the end after what looked like gobbly-goop (there’s your lesson in reading the entire error message).
Support suggested that I make sure sending and receiving instances have the same field length for address lines 1, 2 and 3 on Lead (address1_line1 and so on). Ok, done. Re-export. Try to import. Grrr, no go again.
I was able to de-select Lead, Accounts and Contacts from my import and that worked. But I still needed those customizations to Leads, Accounts and Contacts. Then came the epiphany (I seriously heard trumpets and saw a white light). Leads feed into Accounts and Contacts. They probably all had to have matching lengths for the address fields. So, I go in to the sending org, make all lines 1, 2 and 3 for address1 for Leads AND Accounts AND Contacts all the same (for this instance is was 400 characters, yours might be different). Save, publish, re-export. It worked. With 1 day to spare.
Phew.