Salesforce, Philly, Apex discussed on Software Engineering Daily


In terms of actually building workflows or processes. There is the declarative layer. Can you talk more about what the declarative layer is and how you build applications at the declarative layer? So in some circles the Holy Grail of of software is to not right code right? It's a mission of a lot of different platforms and teams over time and I think I'm a pragmatic person. I think that there's there's always going to be some combination of what you can do with code and what you can do with tools that are essentially writing code under the hood and Salesforce really believes in sort of a low code no code approach and can they create enough tooling? So that smart people can do all kinds of interesting complicated applications without actually having to write any code. So they're they're ton of tools on the platform to support this sort of initiative. There's workflows which have been around for a long time basically sort of an if this the map sort of behavior where you say, okay, you know, if a guy satisfies these criteria then I want you to mutate in the following way or want you to send an email to someone about this record so screw the first one they did and they've added another set of them over time their flows which are much more robust choice. Node based Behavior where you have like this sort of if else evaluation and if true follow this path that falls follow this path and then manipulate records of the following way very similar to like a note read most familiar with that sort of a very sort of flowed based Behavior called flow naturally and they also do something called process Builder, which is very similar to flow actually quite the quite South Philly ated under the hood some more technology and that's a little bit friendlier richer with metadata. Not quite as powerful. So that's just three examples of sort of workflow based logic off but there's actually a number of tools in sort of the declared a toolbox. You have things like validation rules where you can say Okay, I want to evaluate this record for these criteria and the criteria can be quite sophisticated sales was actually has their own sort of formula language where you can evaluate all kinds of things about a record or make mutations to a record using their formula and then they have metadata linkages back to the formula so long It's going to be a drum be throughout our conversation is all this metadata where Behavior so for example, I can Define essentially a reference table with information and maybe break points for discounts based on volume. Right? This money items sold. Is this kind of break point or maybe it's really reference data. That's the names of all the states or the names of some sort of information that we refer to a lot for our business and from for example a formula I can pull in that reference data or from some of these declared of tools. I can pull my reference data and use it as part of my evaluation. So, you know, if this record is greater than breakpoint a you know, this do this logic and I can define breakpoint a is it an abstract entities. This is I'm just going to call it a point a its actually metadata in a reference table somewhere else so I can go back and update that that reference. So really there's some some very clean design here. That is a Common Thread throughout all these different parts of the system this idea that metadata is the most important thing. We're not going to repeat stuff as much as possible and everything else is built around metadata ties back to it. So, of course you have those jobs So clear to tools they don't always get the job done unusual or complex things. Typically you fall back to code and then especially for a speed the coding on a form is still much faster than most of the declarative stuff that's gotten better over time, especially with the recent recent feature where you can actually run flows before save but still if you're doing things a lot of Records, it's typically better to write it with Apex still one of the things that I try to tell people when I'm teaching them about Salesforce. I do a lot of training for Architects and developers is that is because it's such a large toolbox. You really have a lot of different ways to solve your problem and a lot of them probably will look correct. And in fact, some of them will be correct. But only a few of them are probably the most wage only one of them can be the most but only a couple of them are probably really solutions to your problem and one of the reasons that people get tripped up as you won't necessarily know which one was the best for a log Of time and really was scale. That's one of the big Achilles heels for people that are getting used to doing sales work is that things behave quite differently at Large Scale than they do it small-scale. So if you have a table that has a hundred records and enter a thousand words in it, then then find like you do kind of do whatever you want programmatically and declared to be around that those records of you a table that has ten million records in it or fifty million records in it or a hundred million records in in and remember this very sophisticated security model around sharing that's a lot of calculations around sharing they start to get into all kinds of weird little behaviors around. Okay. Well if you defined the linkages between these two records as this type of relationship, then it's going to change your sharing model in this following way. And when you scale that, you know, two hundred fifty million records X the number of users in your org you start to have huge numbers of sharing records has to be recalculated if you make certain changes, so it really kind of takes you down a rabbit hole at the large-scale. And of course, every application needs to have some kind of you. I layer tell me about the best practices for building UI layers in Salesforce applications. So let's talk about you. I layers that. I want to come back to just the idea of layers in general with Salesforce. So of course salesperson evolving platform. I actually one of the things that I love about the platform for is the how often it moves it changes a lot. They have three releases a year. There's so much stuff. I never release it's actually really challenging.

Coming up next