A journey through a legacy Salesforce org’s schema
One of the most painful experiences I have had in recent times with anything ‘Salesforce-y’ happened today.
As part of an upcoming project, we really needed a high level Entity-Relationship Diagram (ERD) – sounds simple enough.
Firstly, what is an ERD? In its simplest form, it is a diagram which allows you to illustrate how different tables in a database connect to each other. In Salesforce, these connections are the Master-Detail or Lookup field types we can add to an object.
The in-built Schema Builder within Salesforce is generally a good tool for a select number of tables and while viewing online. When you are trying to view all objects within an org this becomes quite difficult.
Likewise I tried a two products from the AppExchange. One wouldn’t load at all, and the other was unreadable when attempting to print it out as a PDF or view it in a image program like Microsoft Paint. *sigh*
After a bit of googling, I spent most of today setting up the ODBC connector for Visio 2010 from Progress (find out more here). Once installed you can use the Reverse Engineer feature of Visio to build an ERD.
But warning, it wasn’t straight forward and the most painful part was the fact the import wizard pulls through all custom permissions/metadata types/settings & system metadata, in addition to standard and custom objects. Scrolling through the wizard to tick/untick all items which aren’t actually objects was painstaking!
But a good workman never blames his (or her) tools.
What was the lesson of the day, where did the pain actually start?
The main issue here is actually the fact it is a legacy org (10+ years). Simply put the instance of Salesforce we needed to run it on has too much junk in it and has become really ‘cluttered’.
The biggest learning here was to ensure you have governance in place to clean your instance of Salesforce as you go. Some of the questions we had to answer included:
- Does the business still need those custom fields that were added for that team, but were never actually used
- Do you need that custom object called ‘ABC’ for admins to test/train themselves how to setup fields instead of using a sandbox? (the answer here should be no!!)
The legacy org I was working in, has had multiple admins and people who shouldn’t have had admin ‘super powers’. A number of teams have tried their best to administer the system over the life of the org but didn’t really have the time to learn the capabilities of Salesforce.
In circumstances like this, and without proper governance, it is very easy to just keeping building and configuring new objects/fields. When you look back in the rear-view mirror, you could be left scratching your head as to why the system was configured that way…
What’s the oldest instance of Salesforce you have managed? Do you have any suggestions for maintaining a legacy Salesforce org?
Update 16/2: I have also found this post from Jeff Douglas today which mentions an alternate solution. I also stumbled upon the SF Toolkit which might help with this task. I might give it a try tomorrow and see if it is any smoother 🙂