Episode 54: Custom Metadata with Neha Ahlawat

In today’s episode, I’m sitting down to talk with Neha Ahlawat. She is a former Tesla intern who learned about Salesforce when she went to a career fair. She ended up becoming an engineer with us and now she is the Product Manager for Custom Metadata. Today we’re talking about that product, the new CLI plugin for it, and the feature roadmap. Tune in to learn from Neha’s experiences and the latest on Custom Metadata .

Show Highlights:

What it’s like being a Product Manager at Salesforce.
The shape of custom metadata.
A comparison of custom metadata and custom settings.
Where custom metadata can be used right now.
Pitfalls people fall into when using hardcoded values and how custom metadata can help them out of that.
Ways metadata can be used with flows and processes.
How VLOOKUP works with custom metadata.
Features that the new CLI plugin rolls out for developers.
Where hierarchical custom metadata and working with custom metadata through Apex exists on the roadmap right now.
High priority things on the roadmap.

Episode Transcript

Neha Ahlawat:

I think after talking to a few of them I realized this is something I want to do. It keeps me close to the technical board, but it also gives me a good higher level picture of how we’re all connected and how we are delivering the best to our customers.

Josh Birk:

That is Neha Ahlawat, product manager for custom metadata here at Salesforce. I’m Josh Birk, developer evangelists for Salesforce, and here on the Salesforce Developer Podcast, you’ll hear stories and insights from developers, for developers. Today, we sit down and talk with Neha, who by the way, is a former Tesla intern who learned about Salesforce, when she went to a career fair and ended up becoming an engineer here. But now she is a product manager and we are going to sit down and talk about custom metadata, What is the fancy new CLI plugin for it, and the roadmap. And to begin with, I asked her the same thing I ask a lot of product managers. What is it like being a PM at Salesforce?

Neha Ahlawat:

Lots of meetings. Definitely lots of meetings. So the day are, or let’s say the week is spread out interacting with a lot of different people, different personas. I interact with the team regularly to see what they’re doing, and developing aligns with what we want to be out there for customers. Definitely a lot of interaction with customers, partners and [inaudible 00:01:29], who bring back feedback, who ask questions, who have issues that they’re facing and bring them to our notice via these meetings or investigations, talking to doc writers, which is a very, very important part because affiliation cannot reach customers if it’s not documented and yeah, meeting other PMs just to see how our product is fitting with overall, where the company is headed.

Josh Birk:

Okay. So give me the elevator pitch for custom metadata.

Neha Ahlawat:

Let’s say you are working on filling a form for your customers, where you have a lot of questions, but those questions vary based on what locality the customers are, and what’s the housing, what’s the geolocation, what’s the age group or baby income or a lot of different criteria, but change how the questions appear in the form. So now you’ll make all of those mappings in your org, in your [inaudible 00:02:35], and then you send out those forms into different customer orgs. Now, once those… you package and you send out the form. Now, once the forms reach the customers, do you go back and set all of those mappings manually again? You don’t want to do that, right? You want those mappings to stay intact, you want to send the forms over and you want customers to start using them without having to send somebody into those orgs and reset all of those mappings. So that’s where custom metadata types come in.

Neha Ahlawat:

They are similar to Salesforce metadata. It is a custom metadata that customers build and it records, being metadata, no surprise there, you can easily package them and move it between environments and then across orgs migrated. So that’s the advantage you get on using custom metadata types, over S objects.They are a great way of storing the application configurations, mappings, business rules, validations, and keeping them intact and moving it across orgs.

Josh Birk:

And comparing them to S objects. What is the shape of a custom metadata?

Neha Ahlawat:

Custom metadata it’s record are metadata versus for a custom object It’s records are data. So when you move let’s say a custom object to be in orgs, only the shape of it move, the records do not move along with it. For a custom metadata, It’s no [inaudible 00:04:09], it’s records move along with the metadata. So yeah, [inaudible 00:04:15],you can do everything that you can do with a metadata if you deployed, [inaudible 00:04:19] through all the various channels, but basically anything you can do from all the various channels to a metadata type, can be back to a custom metadata type.

Josh Birk:

Got it. And then going the other direction, how would you compare them to custom settings?

Neha Ahlawat:

Well, custom settings again are like custom objects, right? They’re not packageable. They are not… you cannot migrate extra records between odds and environments, versus you can do that for customer metadata types. And we have thought about that a bit already, but some of the other things are gashing. You can do that for customer metadata types, to get unlimited calls and queries with customer metadata types, you can add record level protection on custom metadata types, which is much more sophisticated production enhancement compared to custom settings.

Neha Ahlawat:

One other big one is relationship. With custom metadata types, You can define relationships to other custom objects as a metadata type or entity particle, even to the particles of compounds fields that you cannot do the custom settings. And you can’t reference custom settings in validation rules or formulas. So I think there’s a lot more there for custom metadata type to offer.

Josh Birk:

Nice. And what are some locations that custom metadata can be used right now?

Neha Ahlawat:

Basically the story or application configurations, you have mappings, you have customizable business rules, secrets, you could use it there. Yeah, there’s a master detail relationship with senior data. You can a bit…not data, basically between application configurations you can use it.

Josh Birk:

Now this is a silly question. It’s semi obvious, but how is custom metadata better than just hard coding values, but more specifically, what are some pitfalls that you’ve seen people fall into when they’re using hard coded values that custom metadata can help them out of?

Neha Ahlawat:

Well, I mean, going back to my forms example, if you hard code those values there, you lose those mappings when you move it to a different org. Let’s Let’s say the objects are not named similarly in the other orgs, or let’s say those values, those conditions change, So in some area you want to show the same question for the age 24 to 30, but in some other area, you want to show it for age 30 to 35. So going in and changing those numbers in the code are never a good idea. So if you have actually relationships to find, all you can do is go change those end points, which are stored in those conditions, and it gets reflected everywhere in your breast of the flow.

Josh Birk:

I think the phrase ‘It’s never a good idea to have to go change that in code’, it’ should be a placard on ever developer’s desk.

Neha Ahlawat:

Right. It’s complicates your testing. It’s complicates… minor changes become-

Josh Birk:

Huge problems.

Neha Ahlawat:

-look [inaudible 00:07:31] in nature. If you’re hard coding stuff, it’s never good.

Josh Birk:

Yeah and then I think to follow up on that, what are some ways that custom metadata can be used to get a process or a decision in a flow or something like that?

Neha Ahlawat:

Well, you can reference them in five [inaudible 00:07:52], right? So you can always have validation rules in your process where it already can set certain validations, or like you mentioned, those validations might work as gauge, and I think that that’s a good way to use custom metadata for those validations. So anywhere, if you have defined a relationship and then you have referenced that custom metadata in one of the validation rules in some flow, it will get executed and it will help get whatever you’re trying to get.

Josh Birk:

Right. And then you can turn things on and off without having to blow up your entire application.

Neha Ahlawat:

Right. Yeah.

Josh Birk:

How would VLOOKUP work with custom metadata? And is that feature out yet?

Neha Ahlawat:

That feature is not out yet. It has been on our roadmap. To be very honest, it’s not entirely unknown. We have some groundwork we have done for it, but there are some other exciting things that we’re are working on, some of them, I can talk about, some of them I can not yet, but once those are out there for you VLOOKUP is something that is on our long range for now.

Josh Birk:

Okay. Nice. I do want to talk more road mapping stuff, but one of the big things I really want to give a shout out to, is the new CLI plugin for custom metadata. What are some of the features that that rolls out for developers?

Neha Ahlawat:

Yes, there’s definitely an exciting new feature. So for developers, basically there are five new commands that you can start using to now create and manipulate customer data from the command line, and not just from the setup UI. The two of my favorite ones from the set of five, am more passionate to Generate and Insert. Generate basically, lets you, switch to custom meta data types, basically. So if you have existing custom objects or custom settings, it’s going to take up shape, build it as a template, and just convert it into a brand new custom metadata type for you. And not just that,

Neha Ahlawat:

It’ll also move it’s record, the records that are stored in those custom objects or custom settings, over to the new customer metadata type. So I think that one is really powerful. And the other one is insert. It lets you bulk-insert record from a CSC. And I think that one is a huge thing because until now, customers have been using the data loader, which is not something we support and maintain. We saved a lot of, I mean, there were investigations, there were cases when it was not functioning properly, and we couldn’t do much about it. So now we actually have a plugin that we can maintain.

Josh Birk:

Nice, and I think that was a question on Twitter from the great James Larry himself, and here there’s data loader, and then there was another side project that I think somebody had put up on GitHub, but now you can just blow the data right in front of the CLI itself. And since this is all based off the CLI, like you’re saying, now you can build all of this into your continuous integration or your build scripts. If you need to build out those customer metadatas into your scratch org or anything like that.

Neha Ahlawat:

Right. Definitely. I mean, that’s the whole point of sfdx CLI that gives you that whole integrated end-to-end development experience, complete with integration testing, automation, and without a plugin is a huge win for the dev to actually start using custom metadata types and the rest of the existing CLI experience that they already had.

Josh Birk:

Nice. And you were mentioning generating custom metadata from custom objects, but does Generate have the ability to generate things off of existing custom settings or anything like that?

Neha Ahlawat:

Yes, definitely. So if you already have settings in your org, custom settings in your org, you can just run the command to convert them right into custom metadata type and move all of its records, and then just change up packages. They include those custom metadata types I said.

Josh Birk:

Nice. Okay. So talking about the roadmap, a lot of questions I got from Twitter, this is the elephant in the room. I feel like for custom metadata for roadmap, I think, you know what I’m going to say? You can see the corner coming up. Is hierarchical, custom metadata, where does that exist on the roadmap right now?

Neha Ahlawat:

Yeah. So it does, not on our short term roadmap right now, but hat’s only because it’s not something easy to switch and to provide like something similar in custom metadata types for our customers. Having said that we know how important hierarchical settings is, how much it is being used. And I don’t want to point out that a similar solution in custom metadata types is not going to be trivial. It needs a lot of research into it, which is why it is not on the short-term roadmap. So we are working on some, as I mentioned, we are working on some of the other things right now, some things that we’ll get to know in the future releases. We’re trying to get parity with lists, custom settings, that’s another focus that we have in the current release and in our short term roadmap. And once we deliver that, hierarchical setting is definitely the next thing that we want to work on, but right now we don’t have a solution for it. So I can’t really promise anything.

Josh Birk:

I mean, we can go back to what seems to be the favorite phrase I keep hearing from the product teams, which is, part of your job is to build things quickly and not break anything. So you’ve got the eyes on the prize, but it’s no trivial task that’s going to happen overnight. Yeah.

Neha Ahlawat:

Yeah.I completely understand that this one is going to be a big, a big win for the customers, but in order to deliver something quickly, we don’t want to break your existing processes, and we want to deliver a well thought solution rather than a hasty Wunderlist.

Josh Birk:

Totally. So I also got other questions about integrating customer metadata directly in with Apex. Are there any updates on the roadmap when it comes to working with custom metadata through Apex?

Neha Ahlawat:

Yes. If some of the people who are listening to this, have been on the release readiness call, they might know that already. We actually have synchronous crud for custom metadata type from Apex on our roadmap. We working on a solution for you there, to make it much better than how it is today. That’s all I can say. It is under those map yet.

Josh Birk:

And then, and then the other question I got from Jody Miner was, is she can do custom metadata in formulas with process builder, or sorry with custom settings, but it sounded like not being able to do the formulas in flow. Is that in your S set on your map?

Neha Ahlawat:

So, the short answer is No we don’t have it on the roadmap, as of now. Having said that, it’s not impossible to use custom metadata type that flows. You can always create your custom metadata with get record elements in flow, I understand it’s not as direct as it does in process builder, and it would be a nice add-on to have. And it’s definitely in our long range plan, not on the short term roadmap, again, other stuff with higher priority, but I do feel that this somehow actually plays out in the favor of flows, because it makes accessing and using a custom metadata in a flow more dynamic, So you can probably do much more with custom metadata type on flow than you can with, process builder because of those not so direct relationship.

Josh Birk:

Right. Well, and this is also on those examples of, because you would have to work with the flow product team in order to get those updates in. So that I would also imagine that that complicates things.

Neha Ahlawat:

Yes, definitely it does.

Josh Birk:

Okay. So you keep saying that there are things that are higher priority on the roadmap. I feel like there might be some things on the roadmap that you want to give a shout out to. Is there anything you can talk about?

Neha Ahlawat:

Yeah. So as I mentioned, we are working towards getting less custom settings, that’d be with custom metadata types on parity, but less custom settings. So we’re working towards Apex static accessories, which means that you can now use some static differences to get your custom metadata type record, similar to how you can in custom settings. So for the dev listing out here, basically, but get values and get all methods that you have for custom settings, you will be able to do something similar for customer metadata sites.

Neha Ahlawat:

You won’t have to retrieve the records, loop over them, and add that performance of complication to looping over the record. So hopefully that’ll be a nice parity to have, plus it will be a good performance benefit I would say, or, yeah. And the other thing, like I mentioned, we are looking towards synchronous crud for CMT via Apex. We have asynchronous retrieve right now, and I know there are certain limitations to do accessing custom metadata by Apex, as of today.We are going to, we are working towards making good synchronous better, and provide more functionality than we do today.

Josh Birk:

Got it. It actually want to pull back to the CLI plugin because I want to make this clear, that is currently available for developers, right?

Neha Ahlawat:

Yes, it was released with CLI version 49 and it’s available.

Josh Birk:

All right. And finally, is there anything else on your roadmap that you want to give a shout out to?

Neha Ahlawat:

I don’t want to mention that I know CLI is getting everyone excited, but maybe we did release geolocation field support for NTP particle relationships. So geolocation is a compound field that was not supported in our entity particles relationship earlier. So we can do that now.

Josh Birk:

Now that’s our show. Now, before we go, I did ask Neha about her favorite non-technical hobby? And it turned out the first thing that came to mind was something she’d actually never talked about within Salesforce.

Neha Ahlawat:

Well, I have not. It’s interesting that I’ve not mentioned this before within Salesforce, and now that you asked me that question, that’s the first thing that came to my mind. I liked to write poetry.

Josh Birk:

Nice. Now, after some initial reluctance, Neha did actually agree to let us add that WordPress blog into the show notes so you can check out her poetry there. I want to thank Neha for the great conversation and information. Of course, I want to thank you for listening. And if you want to learn more about this podcast, head on over to developer.salesforce.com/podcast, where you can hear old episodes, see the show notes and have links to your favorite podcast service. Thanks again. And I’ll talk to you next week.

Show Highlights:

Links:

Episode Transcript