Play by Play is a series in which top technologists work through a problem in real time, unrehearsed and unscripted. In this course, Play by Play: Knowing When to Code in Salesforce, David Liu and Don Robins dive into the the pros and cons of various tools such as Apex, Workflow Rules, and Process Builder as they work together to solve a common business scenario. Learn whether to use "clicks" or "code" when approaching a specific task, configure "no-code" features, and when to use Apex to provide an ultimate "low-code" solution. By the end of this course, you'll have learned a step-by-step approach to decide whether or not you should use code in your next Salesforce project.
David Liu is a self-taught programmer whose dreams came true when he became a Salesforce Technical Architect at Google. Now, David dreams of inspiring the next generation of Salesforce developers. He's a four-time Salesforce MVP winner and runs SFDC99.com, the world's most popular Salesforce blog.
Don Robins is a well known Salesforce MVP, instructor, author, and speaker.
A custom business application developer for more decades than he cares to
admit, he focuses on Salesforce technical instruction and knowledge
Course Overview Welcome to this Salesforce Play By Play with Pluralsight. Salesforce Play By Play is an interactive series where we sit down with Salesforce experts such as MVPs, consultants, developers, and architects to discuss common challenges faced every day by Salesforce customers. We'll be learning while discussing concepts and debating trade-offs on various approaches to solving real-world problems. We learn by reviewing system configurations or writing code, and then exploring the benefits of any particular solution. In this course, we challenge Salesforce MVP, Google technical architect and author, David Liu, to help us understand when and how to choose a declarative versus a programmatic solution. David walks us through his thought process of deciding whether to use clicks or code when approaching a specific task. Along the way, we dissect and explore each of his successive attempts to build a robust and effective solution. He shows us step by step how to implement each approach, configuring and explaining no-code features such as custom fields, workflow, process builder and more. We discuss the limits of each, along with some options and trade-offs. And we review why or why not each will or won't work, eventually crossing over into when we must use Apex to provide an ultimate low-code solution. Whether you're an admin or a developer, you'll definitely gain valuable insight, along with some great tips and tricks for development in your own org. So please join us for Knowing When to Code. We hope you enjoy it!
Setting the Stage Hi! I'm Don Robins, a Salesforce MVP, developer, and a certified technical instructor, and I'm here with David Liu for this Salesforce Play By Play on Pluralsight. David, why don't you introduce yourself. Awesome! I'm David Liu, Salesforce admin turned developer turned technical architect at Google. Cool! Well, you know, for Play By Play, what we do, is we have a challenge, and I'd like to set up your challenge with a scenario. It's a pretty common scenario in the Salesforce world like Salesforce administrators, developers, you're typical responsible for the management of the org. And you're typically regularly making enhancements and modifications in features, etc. We know that the Salesforce platform promotes a no-code/low-code development approach --- Amen to that. --- even though it's capable of a high-code approach, which has problems, but we're not going to talk about that. Best practice is to code just enough or maybe even not at all based on the requirements. So that's your challenge. Awesome! How do you determine when to code versus when to rely solely on declarative configuration or what we call clicks or perhaps use a combination of the two? Apex can always provide a solution. We know that. Developers can always code. But there're always going to be some tradeoffs, and the stated best practice is to strive to adopt that no-code/low-code approach. So, how can you determine the best approach based on known business and functional requirements?