Join us and discover the new Winter ’20 Release features for developers. We know each release brings with it lots of amazing new functionality, and there can be a lot to digest. With Learn MOAR, we’re packaging the release and delivering feature highlights curated just for you.
It’s easy to get started. First, dive into the Trailhead trailmixes with key release highlights for Developers or Admins, or both! (Don’t forget to hit Follow.)
Then, check in over the next few days (September 20-26) to read our favorite Winter ’20 Release features on both the Salesforce Admin and Salesforce Developer blogs.
Lastly, find your local Trailblazer Community Group and attend a meeting to learn about the release in person. Learn, network, and share your experience with us using #LearnMOAR.
Be sure to follow and complete the trailmixes by October 31, 2019 to earn a special community badge and unlock a $10 donation to FIRST®, a non-profit robotics community that prepares young people for the future.
Dive into developer features
As a new Salesforce Developer, I found myself inadvertently creating lots of dependencies. These dependencies made it much harder to update or modify individual pieces. Understanding what those dependencies were was always the biggest challenge when coming to a new org. That’s the reason I’m so excited about Metadata Dependency Queries. While this feature is in beta, it checks all three of my awesome feature boxes: something to try, a way to resolve technical debt, and a new perspective on my org.
With Metadata Dependency Queries, developers can write a SOQL query specifying some metadata and receive back a list of metadata that depends on it. For instance, if you had an Account custom field Lifetime_Account_Revenue__c, you could write a SOQL query like this:
In return, you might see this:
Note the records array. In this case, we can see that the Report ‘acctLifetimeReport’ relies on the field we specified. Finding metadata that depends on a field is useful and powerful, but if we tweak our where clause just a bit, we can identify metadata that depends on an Apex class!
Keep in mind
Like all good things, there are some things to keep in mind as you try it out. For one, the query can only return 2,000 results. This means best practices for SOQL apply to these queries as well. Be sure to be as specific as possible. Narrowing it down with Type and Name is a good start. Keep in mind that there are restrictions on the SOQL query; namely, that you can’t filter on MetadataComponentName or RefMetadataComponentName. Additionally, only the =, != operators, along with AND and OR operators, are allowed in the where clause. The full list of query considerations is available here.
So, what do I do with it?
Metadata Dependency Queries give us a new tool to understand our org. They not only help us understand the dependencies between pieces of metadata but also give us data we can use to visualize and understand where things are tightly or loosely coupled. This gives us a new way to view our org, with the understanding that groupings of tightly coupled metadata make excellent candidates for unlocked packages, especially when these groupings are loosely coupled to other groups.
While the ability to determine where a field is used is incredibly useful, Metadata Dependency Queries are bigger than that. By using this type of query (and a bit of elbow grease), you can create dependency graphs—illustrations that show you where a logical package boundary could be. If you’re working to untangle your org(s) or move to unlocked packages, this is a critical tool for understanding just where to draw those package boundaries.
Love this? Want to learn more? Keep an eye on this blog for more information and check out the official documentation. Did you build something cool with Metadata Dependency Queries? Let us know!
#LearnMOAR and share
Share what you love about the Winter ’20 Release with #LearnMOAR.
About the author
Kevin Poorman is a Developer Evangelist at Salesforce. He focuses on Testing, Mobile, and Integrations on the Lightning Platform. You can pester him on Twitter @codefriar.