64. Salesforce Dependency API | Vladimir Gerasimov

Vladimir Gerasimov, who joins to talk about the Salesforce Dependency API, is the Director of Product Management at Salesforce.

Sponsors

This episode is sponsored by FormAssembly.

FormAssembly and Salesforce eBook – Find out how FormAssembly helps Salesforce customers optimize their data collection.

---

Main Points

• Vladimir’s self-introduction
• Salesforce Dependency API is already in Open Beta as of the recording
• What is the Dependency API and what is the “where is it used” button?
• What meta-data types are supported in the Dependency API?
• How to use and query the dependency API?
• The open-source Dependencies-CLI plugin repository
• The dependency API Future roadmap

Links

• Vladimir’s Twitter
• Dependency API
• Meta-data coverage report
• Learn MOAR – Dependency API
• SFDX Dependencies-cli plugin
• Vladimir’s Dependency API Webinar

Video Teaser on Salesforce Dependency API

The YouTube Video URL

Transcript

AI-generated, unedited.

[00:01] I'd like to welcome our sponsor, Form Assembly. Form Assembly's all-in-one web form platform lets you create forms for just about any use case. From contact forms to donation forms, all while taking advantage of useful features such as notifications, e-signatures, and more. Not only that, but you can also connect data to systems you already use. FormAssembly integrates with Salesforce, Podio, PayPal, and many other common solutions. You can find out how form assemblies help Salesforce customers optimize their data collection in a free ebook that we've linked in today's show notes. Whatever your data collection needs are, you can be sure that Form Assembly keeps your data secure with encryption at rest and in transit on all plans, plus compliance with GDPR, CCPA, and more regulations. At the end of the day, Form Assembly helps you save time, money, and effort while getting the maximum benefit out of the data you collect. And that reminds you: when you support our sponsors, you support the show.

[01:18] Hello, everybody. This is Xi Xiao. This is yet another new episode of Salesforce Way podcast. Today I'm sitting with another guest. His name is. Let me practice how to pronounce it, Vladimir Gerasimov. Almost perfect. Probably better than ninety percent of the people that I have to talk to. Okay, thanks. So I'll let you to introduce yourself. Yeah, well, thank you. First of all, thanks for having me on the podcast today. It's it's always fun to you know to get connected with the community and being able to like attend those kind of events is always inspiring. So my name is Vladimir. I'm a director of product management here at Salesforce. Hopefully, some of you know me from maybe Dreamforce, Trailhead presentations. Or any other podcast, blog posts that I've written. I'm a product manager on Salesforce platform, where I'm primarily responsible for two main areas. One is around almost anything that have custom in it, including custom field, custom objects, global picklists, and the other area is custom metadata types. So I I know I talked to a lot of admins about how awesome custom metadata types are. And my

[02:48] recent, my recent project that I've been primarily focused on for the past, I would say, year and a half now, was dependency API, and I think that's what we're gonna talk. About today, yes, yes, because it's really new, and I heard about it when I need to untangle some happy soups. And we were told, ah, this is coming the dependency API, but I didn't really know what really is about. Yeah, I think we announced dependency API first time back in the Spring eighteen at Trailhead DX. So this Trailhead DX is gonna be actually would mark two year. Since the original announcement, it took us quite some time to to to bring that API to to the state where it it was available for open beta as as today. And yeah, I'm happy to share more about it. It's open to data as of today. It's February, March, March, twenty twenty. Yeah. So, dependency has an open beta starting Spring twenty release. So if your work is on well, which is every work is on Spring twenty right now. I think the last set of works was got the Spring twenty around the end of. February. So by now, every org has an access to Depend CPI. It doesn't matter if it's sandbox or production, because in previous release we're limiting

[04:18] it to sandbox orgs only. So right now, Depend CPI is available for anyone in any any type of orgs, and it doesn't matter if it's your production org or if it's your sandbox org. So that's the last step before GA. This is going to be our last step before GA, and we are planning. We are planning a GA this year.

[04:43] I hope it's gonna come in the next couple releases. I'm not super confident about summer release. I would be. I would be transparent, and you know, forward-looking statement applies every time we talk to Salesforce product manager. But I'm. I'm. I have very high confidence about winter release, which is gonna be a release of Dreamforce. And yeah, and maybe like you know, maybe for those on on who's watching this podcast, I'll just give. Like you know, a minute overview what of what what depends API is because we're talking about how it's all available, and yet we we haven't told them what it's all about. Yeah. So the the pitch that I usually make when I'm trying to promote depends API is is something like following. You know that Salesforce recently celebrated 20th birthday. I think last year. So we are actually 21. We're old enough to drink in the United States as a company. Anyway, we celebrated 20th birthday. So it's it's a pretty big milestone for a company. And a lot of our customers, they've been with Salesforce for as many as 20 years. Some of them, and you know, they started with that simple Oracle and Salesforce. Been releasing new features, and their company been growing, and they've been growing business with Salesforce. Have been adding new. New new apps and new customizations, maybe installing new packages, building new solutions on Salesforce, and. As always, a lot of that was not properly documented,

[06:14] so a lot of companies find themselves today in a struggle of trying to understand how those things are connected. They know that it works, but they don't know if they change one simple thing, what is going to happen, because it's almost impossible from just from from perspective of your org to visualize all of those inner dependencies between different metadata components. What if I rename this custom field? What's going to happen? You probably don't know until you rename that. Well, there's been a pretty big struggle and. The other use case that you brought is around untangling orix that and probably unlocked packages as well. So for those of of you who probably trying to switch to Salesforce DX and the whole source driven development paradigm. And idea of you know putting everything small pieces into unlock packages, it's hard to understand what should go into that unlock package. What are those components that you need to bring together with something else? So Depend C P I, it's sort of an answer for that. It's a tool that can give you the answers. So it's a simple, it's a simple, and technically it's it's a it's not a separate A P I. It's an extension of tooling A P I. So in the tool and API, we have a new virtual entity, metadata dependency component, something like that. You see, I need to look. There is one virtual entity that you can query against, and that entity contains

[07:45] a simple information about how different components are connected. So it has a simple. One-to-one mappings. Each row in that table is is a component and a component referenced. So by querying, you'll be able to see like here's a component ID, a name. I don't know custom field underscore underscore c from this namespace type of custom field referenced by layout ID that name that type of layout maybe not name spaced so eight different things right two IDs of the component their names they are namespaces if they have any and their types like custom field or layout or Apex class or things like that so. It gives you like that original original idea of how things are connected, and using that API, you can later visualize it, right? If you want to build some graph or something like that, or as simple as you know, we did some we did some some declarative implementation of that API as well. With Winter 20, we did that where this field used button. I don't know if you've seen that, but in Setup today, if you go to any custom field definition page, you'll be able to see a button that says where this used. If you click it, you'll be able to see referenced all the places where that custom field is referenced, like decoratively right

[09:15] on your on in your UI. So you don't have to perform an API query when you just need to check a single custom field. So, but that that that button is built on top of dependency API. And that button is actually GA because it's some sort of like a special case of Dependent API that we feel comfortable about releasing into production and announcing that it's GA. While underneath API is still in beta, kind of state, so you know that's that's one of the like you know very straightforward ideas of how you can use depends API. Except we we did it for you, but let's say we didn't release that button, you could have build your own. Custom custom button right and custom maybe Visualforce Lightning page that would do the same. The square depends API underneath it. Okay. I heard that, like the the name states, it's the dependency information, right? If we have a custom field, we want to check where that custom field is used, and this where is it used? The button that's only about the custom field. Yeah, I think within Salesforce there are multiple places where you might see the similar button. Like I think in Apex class, you would see the same button. Technically speaking, the only custom field button is built on top of the Ben's API. The rest is some legacy stuff that is not that using similar things that depends CP I would

[10:46] use, but it's not built on top of it. And we we we actually like once we you know done with GA stuff and things like that, we are thinking we are thinking about all other places where we can expose it in more declarative way. Because again, if you' not really comfortable with you know developer tools and running API queries, which is actually super simple. If you start, if you get, you you can watch some of my recordings. If you get used to use Salesforce CLI, running a a query in in Salesforce for any type of APIs. becomes really really easy, and I think it's a essential it's it's an essential thing. If you're using Workbench, it should not be way more harder to start using CLI, and it's way easier and more reliable in my opinion. Indeed, it's it's all about the mindset. If you think you are a non-tech and you don't want to see what that those like SQL query is, you just see kind of daunting, then you never get the chance to really. To learn it well, yeah, that's that's good for developer. You know, we always have our job secured. But you know, like even within Salesforce, we do not distinguish customers between admins and developers. We have all that new idea of of a Salesforce builder. And we have builders

[12:16] on a different spectrum, the ones who do more clicks and less code, and those who do more code, less clicks. But there's like you know, ideally there's no such thing as like, oh, I'm a developer, I write everything in Apex. Because if you do that, you're probably horrible Salesforce solution architect, whatever. Because you don't need to write code for everything you do. Yeah, there are a lot of declarative tools that you, as a like Salesforce developer, like that old idea, should be using. That's why we we're trying to separate that. Like developer is not the person. The builder is not the one who writes code or doesn't write code. It's a person who knows what tool to use, and some of them might not be like yet familiar with a with a. More technical tools like Apex, but they should be getting comfortable with with some of the less declarative and more like developerish kind of tools. So your your ideal your ideal career as a successful you know Salesforce implementer is somewhere in the middle. So you know how to do this and you know how to do that and you just pick the right tool for right job. Yeah, excellent, excellent. You talk about the dependency API and also the declarative where this button. But what type of metadata I can really check the dependencies? You just talked about the custom field. Is there something else I can use this API? Yeah, there, there are. There's a

[13:46] way more things than custom field in there. There's all all common metadata you can think about, like Apex classes. Apex layouts, custom objects, validation rules, and things like that. It's I I'm not gonna say it. It's all Salesforce metadata. You know the completion is one of the hardest thing. But it's like ninety percent of metadata and ninety percent of dependencies that we have in Salesforce you'll be able to track. So one interesting thing is, you know, I wish I was able to answer this question a little bit better, with more confidence and saying like, yeah, go go and you'll see all the list of supported things. What we are working on as part of our GA story and as part of like you know upcoming releases, is what we call a coverage report. And I don't know if you know about Metadata Coverage Report. Yeah, I think Chris and I talked about the same thing. He was heavily working on that as well. Yeah. So yeah. So Metadata Coverage Report for those who might not have seen the previous episode of this podcast is go Google it first of all Metadata Coverage Report Salesforce. You'll be You'll find it pretty quickly. It should be like in top few links. But idea there is that you have all the Salesforce metadata listed on one side, and you have all different channels that Salesforce has on other side. On other on other axes, so you'll be able to see.

[15:17] Let's say account is exposed in. I'm just making it up by the way. Don't don't quote me on that. Account is exposed in metadata API, in tooling API, in unlock packages, whatever whatever the channels, and you'll be able to see, you know, because it's always. Again, it's a it's a question of like what API to pick sometimes because of different coverages, and you'll be able to see like if there are any existing problems reported about particular channel. Maybe account and metadata APIs is not working today because of some known issue, or maybe there is some known issue related to some of the limitations. So we are thinking about the similar concept that we want to build for dependency API, and I don't know it might. Get incorporated into that metadata coverage report. Though it's you know there's still a lot of discussions about what it would look like from user experience, but the idea is that you can select the. Metadata. Let's say you can select custom field, and you'll be able to see all different references that we cover. Let's say you'll be able to know that, like, yeah, if Custom field is referencing layout. I'll be able to see it and depend CPI. And same would go for like we probably have them alphabetically, you know, like Apex class. So if Apex class is referencing another Apex class, you'll be able to see it and things like that. So this way you you have a better better picture of what is supported and and maybe you know maybe maybe we when make this report. As a as an API as well, so

[16:47] you'll be able to dynamically programmatically check. Oh, am I gonna receive this reference or not? Again, this is this is work, not even in progress yet. This is work in like you know in a design kind of let's think about it kind of stage. But that's where we're heading this year. Okay. How about how can we use it? You know, as a developer, let's say I I heard this, and in what ways I can use it? There, there are a lot of. Things you can potentially do, and quite honestly, I would love developers to tell me about their use cases because I'm just I have very basic use cases in mind. But every time you know we release a feature, we've been you know we've been shocked by by what what what kind of amazing things people can build. And sometimes you know you look and like oh this use Salesforce like how how in the world this is sales still Salesforce. But some of the simple things like you know. Very simple things that you don't need to build anything. You just use the Apex API for. Let's say you're doing some code refactoring. Okay, and you want to modify this Apex class. It probably you can run the you can run the dependent API to understand how those different classes are connected. So you can build like uh you can build you can build like maybe a map of different Apex classes and you can you

[18:17] can drill down and build a tree. So you know if I'm changing this basic Apex class, all of other things are gonna be affected by it. Like if you have some generic Apex class service or something like that that that is shared across multiple things. The same the same goes for any kind of change you make, right? Depends. API provide you basic thing, cause like if I'm gonna change this component, what are the immediate things that might get affected? If I'm changing this. Text field, and I'm gonna shrink it. What are the places where this text field might get populated from? Right. What does it maybe custom inter a custom UI that someone built for that text field or something like that? So any any sort of like you know impact analysis like very primitive at this point because like you know API is a tool it's not a solution but you can build a pretty pretty good impact analysis tool for for the main API and in fact like you know we we have we have one particular partner. That is already building, incorporating Dev C P A into their impact analysis solution. They have a comprehensive like documentation, back analysis. Tools that they they sell at AppExchange and they use Independent CPI to visualize the dependencies. So on each on every component, you'll be able to click. And see like a graph. So dependency give you like one level of dependencies, but they use multiple queries, and you can see, you know,

[19:47] this is custom field. The reference here, here, those things are reference here, and you can click on nodes, and it would expand into like massive tree. So you easily can just from UI and understand how those things all connected. One one use case that I did at Dreamforce when I had a small presentation for ISV partners was how you can combine how you can combine Apex Metadata API and Depends API together to build more rich setup experiences. Let's say you develop the package. That brings that has a it has a custom field on account, right? Pretty common scenario or any on any other object, right? So your customer installs the installs the installs the package, and the next step they need to do is they'll have to go and add that custom field to multiple layouts they have. Right, because as part of package installation, fields are not being added to layouts in a subscriber order. So you can do it programmatically. You can add fields programmatically using. Apex Metadata API. You can you have that ability. It supports very limited set of metadata, but layouts is one of them. So you can write a post install script that would do that. But at that point, you probably don't know what which layouts you should be adding this field because that decision should be up to for subscriber, right? You don't want to just dump your field on all the subscriber layouts. They'll be quite mad about it.

[21:18] But let's say you install they install the first version of your package, they pick the layout they want to and they add that custom field. So when they install a second package version, maybe you add another custom field on the account. What you can do, you can use the plan CPI to query where the first custom field get what the what are the layouts where the first custom field get added to. So you know that in the previous iteration, customer added your field to five different layouts. So you can build a setup that would tell, hey, based on What we see in the org, you added one of our fields to these five layouts. Do you want to add the new field to all of them? You just click OK. It's done. So you can you can you you can use the Pen's API to like take like a look inside the subscriber org and build it. You know, rich setup experience for your app that like you know sort of like a smart experience instead of just saying like here's like. 500 account layouts. Select which one you want to add it to. You can say like, you know, here's 500 layouts you have. Here's the five you actually used for for for previous custom fields that we we brought as a part of package. Do you want to just like add it to those five? Way way better user experience. Yeah, it's like one more dimension of data, so that user can use. Yeah, yeah. So you you you don't operate you don't you no longer operate in

[22:48] in in dark within within the how is it metadata in subscriber is all connected. So I see a lot of I see a lot of like application around specifically like you know setup experiences. Because that's a way you can programmatically inspect subscribers metadata and. Do some propose some actions. So do some actions based on how things are connected. Let's see. Okay. Good. Um, how can I really use the custom metadata type? Can I use Apex to query? Can I use SOQL to query? What are the way? You mean depends API? Yeah, yeah, yeah. You said custom metadata type. I'm just projecting my other features to you. So as I said, yeah, depends API is a is an extension of tool and API. So um, you if. Whatever tool use that supports tooling API queries would work. What I use, what I what I personally use is I like to like when I do my demos for simplicity, I use a SF DX CLI query command, and you can specify dash dash to use tooling API flag there, and then just regular SOQL query. But that SOQL query needs to go through Tooling API, so you will not be able to perform a direct SOQL query against this object. It has to be Tooling API query. So that's one one of the things.

[24:18] So in Apex, you will be able to do it. It's not as straightforward because you know, in order to do a API calls from Apex, you need to do a call out. So, but there are ways you can you can you you can query a Tooling API from Apex. It's just not. You just like query an external API from that. I understand. So it's not a real SOQL query. It's just using the syntax. Yeah, yeah. Like tool and API can use SOQL SOQL syntax, but it still needs to it needs to go through tool and API endpoints. Okay. Okay. In addition to all these, I also see in the Force. com GitHub repository there's dependencies CLI, right? It's open source project. Yeah, yeah. There are a couple plugins that are built by originally by Andy Fawcett and then been been extended by a couple more people that would give you like some some some. Provides a little bit more usability into into dependent API, so I would definitely oh it's it's a good point. I would definitely suggest you to go and check some of the plugins that we have, because some of them like might be exactly what you look in like some of the one of the plugins, one of a Salesforce employee built as. To do like visualization, and they even have a Heroic project where you can upload the data from Salesforce CLI and build like a beautiful map right in your

[25:48] browser that you can interact with, or some other simple things would just generate a graph, you know, like with Open Open Graph plugin. So generate graphs that you can save as a picture, like print it, put it behind your computer, and look at how beautiful your work is. Okay, could you send me the link later, and then I will put it in our show notes. Yeah, we definitely can do that. In addition to the metadata coverage report for the dependency API, what other features do you have in your roadmap? Yeah, so for some of you who probably already been using Depends API, you probably know that it comes with some limitations, and most dramatic limitation that we had to introduce, we had to limit the amount of dependencies you can get back in one in one call. So if you if you call if you query for something, you will not get more than two thousand dependencies at at a time. So you cannot use the Pen API today to query like org-wide query, right? Like select all from Aura kind of thing. That that that would work only. You'll get whatever random 2,000 dependencies. So you always have to narrow your query down to like a specific maybe component ID. So one of the things that we have on the roadmap to store the address set. Because we understand that some of the people they they don't know where to start, and they just like well

[27:19] I just want to see like maybe. The whole work and try to figure out something out of it, or maybe I have that super mega component that like reference in like ten thousand places. So depends basic depends CPI. Like I have to do like too much work to to like you know to filter it by type of different components and stuff. Stuff like that. So we we are introducing what we call bulk dependency API, and pretty much we exposing the tooling API entity that we have that powers dependency API in a bulk to do all. So you will be able to query dependent CPI using bulk to . All and there will be no limit on on amount of records you can get back. Ah, if you want to get the entire, you can get entire work. The only the only. Downside or limitation is that bulk to the tool is asynchronous, so it's no longer synchronous process. You cannot just Submit a query and get results right away. It would take time, based on like you know how big is your work, what's going on with overload on this maybe server and things like that. We're not talking about days to wait, but we're talking about some some time between you submit query and sometime and um and and and time when you receive your results. So it's not synchronous, but it's perfect for like you know if you need that results maybe in CSV file. to to to upload it to some third party tool

[28:49] to to do the analysis, or use it somewhere like whatever whatever whatever tool you want to use it with that or whatever processing like Excel spreadsheet I don't know whatever you feel comfortable with so that that is our most

[29:06] the the the the closest thing on our roadmap, and I think right now we're on track for this to get. We're going to release it straight to beta, so we're not going to do pilot. Pilot's super painful, and I know a lot not a lot of people like to go through the legal aspects of pilot, signing the agreements and stuff like that. So we're going to go. Again, forward-looking statement directly to beta, and current plan is that we're gonna make it available in sandboxes only, just for like you know, precautious measure. But it will be available for everyone, so you don't need to activate it, and you can run it in your sandbox. Hopefully summer twenty, so the next release. So next coming release, that's our big big item on our roadmap that we're trying to deliver. Excellent. So I think that's all I want to talk to you about this dependency API. Do you still have something else you want to share with us? No, I think we covered pretty much everything. I would just, you know, encourage everyone. There, there is a. I've done a recent webinar on Depend C P I. It was internal developer webinar. I'll I'll try to send you a link so we can add it. It gives like I talk more about like just Depend C P I, a little bit more formal way, and I can actually show it at demo. So, if any of you know of you who is listening or watching this podcast today, want to follow up and get more information,

[30:36] that's a good start because it's. It's pretty straightforward. Twenty minute like of a demo that you can watch, you know, on your lunch break, or waiting for a build to build, or I don't know, commuting somewhere. Excellent, Vladimir. It's it's great to talking to you today, and I will put all the information, all the links you shared with us to our show notes for people to check. Yeah, thank you. Was a pleasure to be. Um, hopefully, I'll have more features, and we can meet again. Yeah, for sure. Yeah, talk you next time. Bye bye. Thank you.

[31:15] Hi, I'm constantly looking for good guests. If you have any guest recommendation, please reach me out. I'll make sure they are joining to the show to share their knowledge. Otherwise, thanks for listening to the show. I'll see you next Thursday.