Fabrice Cathala joins to talk about declarative for Salesforce developers.
Fabrice is a Salesforce MVP, SF Dev Group leader, SaaS evangelist.
Main Points
- Fabrice’s self-introduction
- Two types of solutions in Salesforces – enterprise solution and ISV managed package
- Using declaratives in managed packages
- Take into consideration that the platform is all the time evolving when building a solution
- Design a solution with declarative or coding
Links
Video Teaser
Contact Me
If you enjoy this podcast, please reach me out to let me know your thoughts or simply say Hello. My (Xi’s) contact info:
Take care, until next time :)!
Transcript
AI-generated, unedited.
[00:13] Hey everybody! This is Xi Xiao. This is yet another new Salesforce Way podcast episode. Today I'm sitting with a new guest with me. His name's Fabrice Cathala. Hello, Fabrice. Hello, Xi. How are you? I'm good. I'm good. Thanks for your time. I know you are now sitting in the hotel room, so definitely appreciate that. Yeah, no worries, no worries. Why would you introduce yourself before we really start our conversation? Yeah, sure. So I mean, I'm a Salesforce consultant. I'm currently specialized on the Service Cloud delivery. And yeah, so I'm that's what I'm doing as a day job, and I've got a couple of certifications, so ten in nine in total, because the dev has been removed, and I'm a Salesforce MVP as well. Yeah, I understand. You had a lot of contribution back to the community. You were different Salesforce group leader, right? In the past, indeed. Yeah. So I've I've started. So I was part of the group which started the the. Developer group in Reading, in in the UK, and then I move closer to my home in Swindon, still in the UK, but yeah, as it happened, it's closer to where
[01:43] I live. Yeah, and today I invited you to talk about the interesting topic, and actually it's a complex topic because different people really have different opinion on this. It's the declarative versus coding. Yeah, absolutely. So, yeah, I've got a strong feeling, sort of against coding. I'm tolerant, so I wouldn't say. For sure, coding has to be removed from the platform for from delivery. But I think that you've got two sort of Salesforce implementation. So one is. On the customer side, and it's delivered by us partners, or by the the customer themselves, and as well, the other thing is you've got what I would call GSA or people who are. Delivering solution on the AppExchange platform, and for for for these guys, it's a completely different story. So I'm I'm making the separation between. Yes, I think most of our listeners already know that we have ISV who creates that manager package, right? And also we have dedicated enterprise solution which for individual customers, right?
[03:14] Yeah, okay. Yeah. So I mean, so the for the individual customer, so the thing that you release solution, I would say, based on the Salesforce platform, but which is a unique. So you've got to go through testing and before you release, etc. Every every partner has got their own solution for for for this and process in place. But you don't benefit from testing. So testing is is the key. Yeah. Um, because so the the testing a bit is a different if you deliver a single solution or if you deliver two multiple customer. So if you deliver a single solution is for customer. The partner versus Apex change delivered. So, Apex change typically targets multiple customers and and benefit from more testing. So, what's what's the the difference I'm making? Okay, so what I'm hearing here is that. You agree that for the ISV, the managed solution, creating as much as possible by code. Is acceptable, right? Well, yeah. I mean, so that's my my take on this,
[04:44] and so based on my own experience, and also the fact that I'm seeing more and more customers who are stepping back from coding at the coding mayhem and being. Exaggerately configured to accept the fact that a single delivery. So, again, for from a customer perspective, has got to deliver on every single use case, and and so they. What I see again in in the field is that people prefer to to have a reliable solution rather than a solution which does every everything. And the other thing is that Salesforce as a platform is a. Getting age, I would say. So at the beginning, people were doing all and nothing, really configuring how they thought. But now we've got some return on experience, and we see that. Customer who used to go mental between codes with coding.
[06:10] Don't benefit from the latest feature, for instance, because they have configured so much their solution and it's not necessarily supported, or it's not going down the the the road that Salesforce would would like to go, and.
[06:32] Yeah, and and doing this from as a ASV on the on the AppExchange platform is a different business with a different resource and specialties as well. And yeah, so I think that in the end today, exaggerated the use of code. Is not necessarily the the way we want to go, and Salesforce themselves are talking about low code, for instance. And they, although effectively, you've got this possibility to to write code on the platform. They do highlight the fact that low code is is a good way to get the the best of both. Hmm. Yeah, I I I wasn't quite clear when you uh said that for the ISV, um, because for ISV I know that there was one guy called Chris. I don't remember his full name, but he created the managed package and published in in AppExchange change is fully declarative way. So, so that's possible. That's feasible. That's doable. Yeah, absolutely. Yeah, absolutely. But I never thought about that before because always people around me who has the developer background always tell
[08:02] me that use the code, use the code. That's the way for the managed packages. Yeah, I mean, so the managed packages are a bit difficult to put together, but. I think that if you are part of GSI, you've got your colleague around you to
[08:24] deliver the right solution on the on the AppExchange, but. It's more difficult to to do on the for single customer. Okay. Sometimes I also hear, especially developers, because I'm a developer, so a lot of people around me are technical, architectural developer. So once the solution becomes slightly more complex. We are moving the declarative ways back to the code because either the performance is not as good as expected. Or it's just too harder to maintain a hybrid solution when you have both code and the declarative. So they want to unify the solution into just code. Do you think that's a too like a simplified kind of view on the things, or we can do things better we by using more declarative tools? Yeah, no, no. So I think that so it's it's a it's a principle I would say more than an idea to follow all of the time and all the implementation, etc. So I think that effectively, if you are blocked as a customer, so you got this possibility to go into low code, etc., and do effectively implement code instead of. Declarative option, but declarative. So the thing that Salesforce
[09:54] is a software service is a. Declarative first, I would say, platform. So you do need to think about a declarative way to do things before you end up coding. That's that's a really good point. Indeed, this is like the declarative tools is one of the major reasons that Salesforce become today, like is so successful, right? And it's always the the marketing, the promoting, the low code there. While a lot of people in the consultancy firms, especially, a kind of hesitate, think that this is just a marketing slogan. So when we really do customer solutions, we more prefer the coding over the declarative. And I remember in the Dreamforce 19, Daniel Stanger. He made a good presentation about comparing the performance differences between the declarative and the code. I think that's a really. Have you? Listen to that session. I have not, but you you need to be careful because comparing the, I mean the the current state of the the code. So if the code is currently working faster than declarative alternative, is something that you need to be very careful of. Because
[11:25] it can change, and Salesforce has been changing since the early days. I would say so. Yeah, so that's that's absolutely my point is to say careful because this is a a platform which is evolving with the the time, and what's true at one point may not be true. In the future, and you need to to build a solution which is future proof. So. Hmm. Yeah, yeah. Because you you mentioned a really good point is that when we build a solution with declarative tools, it evolves along with the platform new features, new versions. Right. So when the new feature is pushed to the platform, your solution automatically gets this new feature in. Yeah, wild and I can tell you. Yeah, I can give you an example of customer of mine that I won't name, but in in the past they they they had the their own way to do service cloud.
[12:34] Work so working with cases etc. and they wanted to reproduce exactly the the old way to do things instead of considering the way of doing it the Salesforce way say and Salesforce released a new feature which was related the case to knowledge content.
[13:01] And yeah, and they were blocked, so they they didn't benefit from this capability. Why? Because they were so much custom, when they they just were outside of the Salesforce way, and.
[13:19] Well, that was too bad, but we had to rebuild the the solution for him and go back to standard so standard slash declarative way. In my previous working experience before joining Salesforce, the company I am working in definitely. Learned a lot, had expensive lessons to go to extreme in the tailored solution, so it's really really hard to maintain. I think it applies here in the Salesforce ecosystem, the platform as well. But I think the things that for also on the other side, a lot of customers, their solution that think is kind of unique. And they think that only the code can really fulfill their requirement, so. We need somebody to challenge that and then pull it back a little bit, right? And absolutely. And what's the what's the the the the solution? I would say to this this problem is to learn to say no, because people think how will I how will I deliver this requirement. And how they come up with a code option? But how about you say no? Let's not do it this way. Let's wait for a future functionality. So again, Salesforce is raising a functionality pretty regularly
[14:50] three times a year. So yeah, so I would be very careful. About saying yes to everything, basically. I think in that sense, in the team, when we make a solution, we need experienced people who have many years of Salesforce experience, like what you did, right? So when we have a requirement from the customer. You can really make a decision. Okay, let's use the declarative, or let's use the code, and you have to have an in-depth understanding. What's the pros and cons? Yeah, but so the declarative is tested by by Salesforce. So again, I'm going back to the testing side of thing. So the declarative is tested intensively, I would say, by Salesforce before releasing a new feature. There. Bulletproofing a
[15:50] new a new feature. Say you need to ask yourself the question: How robust is going to be? Is is my solution going to to to become? And that's the way I would put it. Okay, but is there a best practice, a good guidance, like for what type of solutions or like how complex solutions we better use the declarative more? Or you know, otherwise it's it's it's too hard for for people. We understand the principle. We need to think about the declarative, but then how do we put it to really to practice? Yeah, I mean, so so effectively, so it's a principle. You need also to take into consideration how how long. Are the troops going to stay with the company? Because that's the other thing that you can have a a customer who's got developer who can effectively implement on the flow new feature and coding option, etc. But then they leave the company. Go and work somewhere else, and God knows that it's a very moving ecosystem. And then the customer is left with a solution that nobody knows how to maintain. So that's that's a
[17:20] one way to look at the the risk here, and it's a risk management issue. Okay, okay. I see, I see. So, what else do you think is important to put put into this picture? So, for me, I'm a developer. I understand from what you mentioned to always think about the declarative, and I'm actively, you know, learning from like Daniel Stanker. He has put really good resources out. For example, sometimes the declarative tools works okay. But if it reaches more than two hundred records in one go, then the performance would drop drastically. So I didn't know in advance until I hit it. So do you have some good resources or something for people to to to learn or? No, I mean, so honestly, I just wanted to raise the point when we we had this chat about. Getting together about the fact that code wasn't a way to go systematically and a way to do everything in Salesforce. Again, it's a principle. It's a warning that I'm raising to say careful because if you overdo the coding thingy, you you may end up in trapping
[18:51] yourself and delivering a solution which is going not to evolve in the time. With with Salesforce new new feature, three years a new delivery.
[19:05] Or it's going to be difficult and expensive for you as a customer as well to to maintain in the in the future. So it's it's really difficult to. Put some rules and guidance there, but you need to be aware of the fact that code is not everything. Understand, which is also make the CTAs more pricey. The CTAs they know what to do, right? Absolutely, absolutely. This is this is the the key. In fact, is that effectively we need to rely on CTA to to say, okay, this is one step too too far. We need to say no, and that's that's the the way to think about this this problem. Excellent, thanks Fabrice. I think you have pulled me back a little bit from all coding path. Yeah, great chatting with you. Yeah. Before we close our session, do we have something else you want to add? No, no, no. So again, so I wanted to raise this point in in in your series. So say that code wasn't the solution to all problems in life, Salesforce life. But yeah, nothing else to to add really. Thanks, Fabrice. It was really very welcome. Okay.
