Back in Dreamforce 2015, i told the audience in a session dedicated to Custom Metadata that i estimated it would take around 5 days to perform the retro fit from Custom Object to Custom Metadata. Well i’m pleased to say i have come in a little under that, and also retained support for using Custom Object’s to store rollup definitions for now.
“Custom Metadata is like Game of Thrones, its addictive, great value for money and I just keep wanting more of it!”
In this blog i’ll talk about what support for Custom Metadata means for users of the tool and also a bit about how technically the retrofit was coded.
Before getting into the coding side, lets quickly discuss the new feature and what you can expect…
What is so good about Custom Metadata then?
Well if you have not heard by now, its basically a huge time saver for anyone using apps that have adopted it. As the configurations you make are no longer treated as data but a metadata.
What that means is like other configurations you make under the Setup menu, your rollups in this case are treated like any layout, Custom Field, Validation Rule, Flow etc you have also added, when it comes to migrating to production via Change Sets or building out an extension package and packaging rollups. In addition if your refreshing a configuration only Sandbox, your rollups get copied over as well! No more rekeying rollups or using Data Loaders to transfer them.
Install vs Upgrade
If your familiar with the tool but installing for the first time in a new org you’ll notice some changes to the default tabs (as shown above), though worry not, the old tabs are still present. So if you’d rather catchup with this stuff later just continue as normal setting up your rollups via the Lookup Rollup Summaries tab.
If your upgrading things will remain the same and you’ll have to go to All Tabs to find the new tab above. When you select the new tab you will be presented with a small info message, a link to the old tab and a means to dismiss it once read from appearing again in the future.
Tip: You can edit the Declarative Lookup Rollup Summaries app tabs under Setup to remove the new tab and replace with the old until your ready
Why a new Tab and not the native Custom Metadata UI?
The platform provided UI for Custom Metadata is for sure a much appreciated addition, with Layout support its certainly wins out over Custom Settings for sure! In this case however I still found myself wanting in terms of the user experience…
When editing Custom Metadata based rollups I wanted two core peaces of functionality currently available when using the Custom Object based UI. Mainly validation (the existing Apex Trigger / Domain logic) to check field names, allowed activation etc and also make available the various buttons to manage the child object trigger and start/schedule calculations. So, as per the info message above, you can use the native Custom Metadata Types under Setup if you wish, but be advised for now at least, you’ll be bypassing validation.
The design is based on my earlier proof of concept described in this blog.
Does the new tab do all the stuff the old one does?
Almost! Take a look at the Pilot limitations section (see v2.0 release) in the README.
Can i mix and match between using this new feature and existing?
Yes you totally can. Just make sure if you copy over an old rollup to deactivate it once you activate the Custom Metadata based one to avoid duplicate processing.
Is there a means to automate copying my old rollups over to Custom Metadata?
Not currently. This is possible and something i wanted to build for this release, i just ran out of available time, so is now on the backlog as a future enhancement.
I see this is Pilot, are there any known limitations?
Take a look at the Pilot limitations section (see v2.0 release) in the README.
How did you go about coding this retrofit to Custom Metadata?
The Apex Enterprise Patterns and Separation of Concerns most definitely helped me perform the update here. Especially as i wanted to effectively support two storage options, that shared the same fields, but leave the core functionality intact.
If you review the GitHub History around the few days i was working on this (22nd to 24th) you can see more or less that i took the following approach. Also after each set of changes ensuring all unit tests where still working was key.
- Created the Custom Metadata object, as per the approach i took in my original proof of concept, this is mostly a copy paste from the Custom Object with some tweaks.
- Create a Apex wrapper class around the Custom Object and Custom Metadata representation of the rollup definition, RollupSummary class.
- Updated the Selector to return RollupSummary lists instead of Custom Objects. At this stage i just wanted to complete a sweep to address compilation issues (primarily in the Service layer). I had not plumbed in querying for Custom Metadata yet.
- Decoupled tracking the Calculation Job Id from the rollup definition (this after all is operational information) and created a new Custom Object to track this, that both modes would use.
- Updated the Domain class to support both storage options by utilising the RollupSummary wrapper class within its core logic, to retrieve field values and set field errors etc. Thus the Domain class logic has been abstracted away from the underlying storage type. Apex Trigger behaviour is totally unaffected.
- Developed the new UI based on the proof of concept from my earlier blog. Some new RollupService methods also leveraged the CustomMetadataService to perform CRUD operations on Custom Metadata Objects via the Salesforce Metadata API also highlighted in the same blog.
- New Service methods have been added to expose operations to callers such as the new UI controller above. These methods also delegate to the Domain class onValidate methods to ensure the same validation as applied to the Custom Object via its Trigger is reused consistently.
Custom Metadata is like Game of Thrones, its addictive, great value for money and I just keep wanting more of it!