Goodbye Unneeded Custom Object

For a long while now I've known that my Org had an unneeded custom object (Deal Database). I do believe 'If it ain't broke, don't fix it', but eventually the scales tip toward getting rid of that unneeded object. That occurred in my Org when we ran into reporting issues and users were constantly adding in duplicate information to an object that was related to our Opportunities.

I knew the timing was right when I had already cleaned up the standard objects in my Org and had moved all lookups to master-detail relationships where possible. I had optimized layout and worked with internal teams to improve the overall UX. Conversations began to move from 'Is this field populated?' to 'How are we going to use this data to make decisions?' The time finally had come to get rid of that unneeded object and since there was SO MUCH to consider and plan out, it made sense to let all of you benefit from my experience!

My first step was getting access to a CRM Committee of internal users. These users are critical to vet the changes that I wanted to make in the Org. They make sure I understand all facets of their team processes and that I don't build a new process that doesn't flow with their deals.

TIP: Make sure that you're building in enough time for the planning phase and data migration of a move like this. You'll need to have a set plan in place AND be able to still handle the daily questions/issues of your users during the transition phase.

In working on Win/Loss analysis and trying to roll-up Industry data to our Parent Companies, I realized that this unneeded object was actually impacting our ability to fully report on trends. This object was called a 'Deal Database' object and was an overview of transaction details when one of our client deals was fully processed through to the end sale of the entity. The object was also used to track deals that employees worked on before their time at the firm. The first challenge was how do I collapse this object back into Opportunities where the detail belongs, when there is no Opp for the records that pre-date someone's start date?

The answer was to create a master-detail relationship for a new history object. This object would only track records for each new employee to maintain their background and experience. This removed the issue of past deals getting included in pipeline reports by accident. It also locks down access for other users to make edits to these records. I created the new fields, locked down access to the old object and then moved the data over. Anytime you are moving multiple data fields, you can (and should!) first analyze which fields are truly needed. There's no need to move bad data over to this new object. It's also a great opportunity to identify data quality issues as well. This can typically lead to validation rules that you put in place for future records. I utilized 'Field Trip' to run this analysis and pulled over just a fraction of the fields that I needed to maintain for the deal history.

TIP: Contact Salesforce Support to maintain the 'Created Date' of any records that you are moving to a new object.

With that portion done, I updated access to the History object as View All. Since I am the only one creating those records, users should not be able to edit or create additional records under that object. This verifies and maintains the process from a compliance standpoint.

The next portion was the hardest part. I needed to take an object (Deal Database) that users were infrequently using and integrate it into an object (Opps) that users were interacting with every day! I turned again to 'Field Trip' and ran a field analysis on the Deal Database object. While that was running, I completed a full object export using Data Loader and saved that with my backup reports. This is a best practice in case I need to unwind this process in the future or if something goes wrong in my data migration! I recommend doing this as a Data Loader export and also a Salesforce Report. That way, the Data Loader export is showing IDs for all of your lookups, and the Salesforce report is showing the actual Account and Contact names.

I then determined which fields needed to be created on our Opportunities. After creating the fields, I made sure that I did not add them to the current layouts that my users were actively working with. I didn't want to disrupt their Salesforce experience with a half-completed process and no one likes surprises in their Org! To avoid this, I created a new record type that only the Admin profile had access to and enabled all of my new fields on that layout. I then mapped all of my exported Deal Database fields to my Opp fields. This layout will encompass all of the Opportunity fields and will be helpful for Admins to use moving forward.

Two items to note here - this is a great opportunity to correct the issues of the past. I updated field names to be consistent with the data being pulled (i.e. instead of listing 'City', I listed 'Buyer City' and 'Client City'. Previously these fields were confusing when you were building a report. One was 'City' and the other was 'Company City'. Not much help, right? Be sure to name your fields in a similar naming convention. That way when you're building a report and type 'Buyer', you will see 'Buyer City', 'Buyer State', 'Buyer Revenue', etc.) The other key item to keep in mind is to create an ID field that you map to your old object. Adding 'Deal Database ID' allows me to audit fields easily AND in case I forget to map something or need to pull another update, this ID field allows me to easily connect to the old record. It's a great safety net to that old object while you are transitioning the object out of your Org.

I migrated the data and used my Admin layout to compare and audit a handful of records. Here are some additional tips to keep in mind when moving data on a large scale:

*Turn off any alert emails tied to the object you are updating

*Add Profile <> "Admin Profile ID here" so that your Data Loader job doesn't error out on validation rules

*Save your field mapping. Nothing is more annoying than getting bumped out of Data Loader or tripping an error and you have to manually map 50+ fields AGAIN

*Create a list of Org reports that are using the old 'Deal Database' object. Set up a plan for new reports to replace these for your end users

*Using Conga Templates? Be ready to update templates that reference the old object

*Dashboard reports using the old object? Those need to be updated as well

*Notify your users about the transition. Highlight the benefits for them!

*Remove redundant fields between the old object and new object

*Use formulas whenever possible instead of asking users to manually type in data

*Roll out the updates in an all hands meeting

For this update, I utilized Process Builder to take the current Opp layout that users were used to and flip to a new Opp layout (holding all of the former Deal Database fields) when the Opp Stage becomes "Closed Won". By doing this, I'm shortening the overall page layout AND I am only changing a small portion of the user experience. Over the next few months, I will work with the CRM Committee and analyze the experience as well as the fields to determine if all are needed. The first few on the chopping block are contact fields that are not a lookup, but simply text fields. How and why are we adding those in? Can they be handled through Contact Roles? How are we planning to make decisions utilizing that data? Just a few questions to keep in mind as you push your users (and yourself) to constantly allow your Org to evolve and improve the overall experience and efficiency for your users!

When it comes to large Org changes (new object, new process, etc) I always use a weekend or holiday to update Salesforce. By doing that, I minimize the issues/confusion that a big process change could cause for my end users. Since this update was a result of my yearly Salesforce Survey (yes, I recommend a yearly survey to see what's working, what needs improvement and how the experience is for your end users) to my users, I wanted to celebrate in a fun way.

As many of you know, I don't believe in boring meetings and since this meeting was all about THEIR feelings and experience with Salesforce, I created an emoji-themed session. We focused on the new updates as well as new Global Actions in SF1 that updated old processes relating to the retired object. I included a playlist running as users came into the session and baked some tasty emoji-themed treats. (End users are probably not going to find Salesforce updates as exciting as I do, but some baked goods go A LONG WAY to having users fight to get a seat in your update sessions.) I recommend leaving the old object data as View All while you create/replace old reports. Once you're confident everything has been transitioned over, you can remove View All access to the object. I typically hide the object for ~3 months before fully deleting it from the Org. This is especially important if there are any end of quarter or year end reports that someone has forgotten about during the transition. I hope that helps and good luck with your data migrations! It's a lot of work and takes planning, but in the end it improves your overall Org and your users will thank you for it!

Here's a few songs from the 'Feelings' playlist I used in my session: