The document discusses the decision-making process for developers when choosing between code and configuration in Salesforce, emphasizing the importance of tool selection based on functionality, performance, and scalability. It provides key takeaways for building forms and implementing automation, suggesting best practices for leveraging both configurations and code. Ultimately, it encourages continuous learning and thorough documentation to ensure long-term maintainability and success of implementations.

1. When to Code / Config / Config
+ Code
Let’s find a Pragmatic approach
to the daily dilemma

2. Our Speaker - Nikunj Doshi
LinkedIn https://www.linkedin.com/in/nikunj-doshi/ (Dormant)Blog - https://struckbylightning.github.io/

3. Agenda
● Why should we care?
● What does Salesforce have to say about this?
○ Decision Making Approach
○ All available tools (Existing + New)
○ Architect Decision Guides
● Sample Code + Config Record Triggered Solutions
● What do I have to add more to what is already said
● Q&A / Share your story

4. Why should we care?
Daily Dilemma
It is a decision that we as a
Developers/Admin/TL/TAs need to make on daily
basis.
Compounding complexity
Lasting impact our decisions can potentially make on overall health
and success of the implementation.
Ever Growing Platform
Means that there are always better way to do things ;)
Karma!!!
What goes around comes around
(Careful considerations, keeping up to date, and documenting the
rationale our only real saviours!)

5. What does Salesforce have to say about this?
Decision-making approach to evaluate tools
Step 1. Identify which tools offer the functionality or level of customization needed to meet your
requirements.
- Functional requirements define what your solution must do
- Performance requirements define how your solution should perform under certain conditions
- Scalability requirements define how well the solution should be able to handle increases in load
without impact on performance.
Step 2. Choose the tool that allows you to best leverage the available skillsets of your team (now
and into the future), think carefully about followings,
- Specialized Skills, Skills of Delivery Vs Operations team
- Delegation of Delivery, How can requirements be broken into module solution pieces, how will
the be delivered Code Vs/+ Config
- Maintainability & Long-Term Ownership, Think of a framework on how to deliver ever-evolving
requirements in the future on an evolving platform, long after you are gone.

6. Form Builders to choose from
- Dynamic Forms aka Lightning Pages
- Screen Flow (+ LWC)
- LWC
- OmniScript (+ LWC)
- AppExchange Solutions

7. What does Salesforce have to say about this?
Architect Decision Guide - Building Forms
Key Takeaways
● Takeaway #1: For basic create/edit forms on a Lightning record page on desktop, use Dynamic Forms.
● Takeaway #2: Use Flow to build multi-screen forms. If you need to also meet precise UX requirements, layer in LWCs.
● Takeaway #3: If you need test automation, start with LWC. You can write unit tests for any LWC, regardless of where you plan to embed it

8. Salesforce Industries OmniStudio
New Kid on the block (there is always going to be one)

9. Compare & Contrast

10. When to use whatOmniScript Vs Screen Flows

11. What does Salesforce have to say about this?
Architect Decision Guide - Record Triggered Automation
Key Takeaways
● Takeaway #1: Stop putting same-record field updates into
Workflow Rules and Process Builder. Start putting same-
record field updates into before-save Flow triggers
instead.
● Takeaway #2: Wherever possible, start implementing use
cases in after-save Flow triggers rather than in Process
Builder and Workflow (except for same-record field
updates, in which case see point #1).
● Takeaway #3: If you have high performance batch
processing needs or expect highly sophisticated
implementation logic, use Apex.

12. Sample of Scalable Code+Config Solutions
1. Define Rollup Fields For Lookup Relationships In Custom Metadata
2. Reusable Big Object Archival Engine Design

13. What do I have to add more to what is already said
- When in doubt, List all Options -> POC -> Document (Pros/Cons/Considerations) -
> Shortlist and move forward.
- Treat Config as declarative code, thereby applying same best practises of code to
your config.
- When coding, always think scale and reuse.
- Most simple solution is generally always the best solution
- Play by yours and your to be operations teams strengths
- Consider Profiling/Performance/Debugging/Automation Testing needs before going
forward with an option.
- While Config(ing)/Coding - Do not underestimate power of Naming variables in a
way that makes sense to a lay man (not big fan of conventions that make your head
dizzy)
- What is best today might be sub-optimal tomorrow, so to avoid future generations
to come in and curse you, document document document all the thoughts &
conscious considerations that went in behind defining a pattern/selecting an option
- Goes without saying, keep always learning!

14. Q & A
Share your memorable (think best well thought implementation I have ever
seen) / horror (think infinite recursive loop) stories NOW :)