For any Salesforce developer, writing code is not enough – it’s about writing quality code that is maintainable, secure, and high-performing.
1. Use Out-of-the-Box Features Before Writing Code
Salesforce offers many ready-to-use features(OOB) and standard settings. Before jumping into custom Apex code or complex solutions, check if your requirement can be met with point-and-click tools or built-in features.
Leverage declarative options like Flows, Validation Rules, Roll-up Summary fields, Approval Processes, or other configurations first. This helps you develop faster and makes maintenance and future upgrades easier. Write custom code only when necessary (i.e., no standard feature can accomplish the task).
Tip: Over-customization can lead to technical debt. Use standard Salesforce capabilities (like Process Builder/Flows, Schema Builder, and Lightning standard components) to minimise the amount of Apex or JavaScript you write. This makes future updates easier and reduces potential bugs.
2. Avoid Deprecated Functions and Patterns
Salesforce technology evolves rapidly, and some older functions become obsolete. Stay up-to-date and avoid using deprecated methods or patterns. Always read Salesforce release notes and developer blogs.
They will highlight deprecations and recommend alternatives. Using modern, supported methods ensures your code remains compatible with the latest Salesforce releases.
3. Design a Scalable and Modular Architecture
A robust Salesforce application needs a good foundation. Keep your codebase modular, logically structured, and aligned with best architectural practices:
Trigger Handler Framework
Avoid putting business logic directly in triggers. Instead, use a trigger handler framework or pattern to manage trigger logic. This means having one trigger per object that delegates actions to handler classes.
Service and Utility Classes
Separate your concerns. Use dedicated service classes or utility classes for business processes, and call them from triggers, controllers, or batches.
This modular approach means if you need to invoke the same logic from a Lightning component or a scheduled job, you have a single Apex method doing the work. It increases reuse and makes maintenance easier.
Modular Lightning Components
Break down your UI into smaller LWCs. Instead of one massive component handling everything, create components with clear purposes. This modular design makes components reusable across pages and apps. It also simplifies testing and debugging, since each piece has a focused responsibility.
Use design patterns to bring structure and clarity to your Salesforce code. For example, implement a factory class to manage test data generation efficiently.
4. Adhere to Security Best Practices
Security is paramount on the Salesforce platform. Always ensure your customizations respect user permissions and org security settings:
Enforce Sharing Rules
Use with sharing to ensure Apex code respects record-level access, as Apex executes in system context by default. Always explicitly declare your Apex classes as with sharing (to enforce sharing rules) or without sharing (to bypass sharing when truly needed).
As a rule of thumb, any class that performs SOQL or DML should be declared with sharing unless there’s a specific reason not to. This ensures users can only view or modify records they are authorized to access.
Respect CRUD and FLS
Before you query or update data in Apex, make sure to check the object’s CRUD permissions and field-level security.
Use User Mode in your database operations: for example, add WITH USER_MODE to SOQL queries and use insert … as user for DML. Running in user mode automatically enforces field security and CRUD, saving you from doing it manually.
Secure Integrations
When calling external services, do not hardcode secrets or endpoints in your code.Use Named Credentials to safely store API endpoints and login details. This not only keeps your code clean (no sensitive info in Apex) but also makes it easier to manage endpoints across environments.
Additionally, always use HTTPS callouts; Salesforce will prevent http:// callouts for security.
By following these security practices, you maintain the trust and data integrity that is expected on the Salesforce platform.
5. Write Clean, Quality Code (Error Handling, Logging, and Standards)
Robust Error Handling
Anticipate and handle exceptions in your code. Use try-catch blocks around logic that can fail (e.g., callouts, database operations in batches). In the catch block, make sure to log the error and then either handle it or throw it again with a message that users can understand.
Implement Logging
Use a consistent logging approach to enhance maintainability and traceability in your org. You can use a custom object to store logs, or even platform events or an external monitoring tool.
Avoid Hard-Coding
Never hard-code IDs, URLs, or credentials in your code. Use Custom Metadata Types or Custom Settings to store configuration data that might change (such as record type IDs, special field values, thresholds, or endpoint URLs). This makes your application flexible—when something changes, you update a metadata record instead of altering code. It also eases deployments between orgs (no need to find-replace IDs in Apex).
Bulkify and Optimize
Ensure your Apex code is bulk-safe to avoid hitting limits and to support large-scale operations. Assume that your trigger could be processing 200 records at once, and your code should handle it without error. This means no SOQL or DML inside loops (instead, gather all needed records and query/update in one go using collections).
Write code that is clean and organised so that you or someone else can read and improve it easily later on.
6. Ensure Thorough Testing (Apex and LWC)
Testing is non-negotiable for quality Salesforce development. It’s not just about hitting the 75% code coverage requirement; it’s about verifying correctness and preventing regressions:
High Coverage with Assertions
Aim for 90%+ code coverage on your Apex classes, and make sure your tests assert the expected outcomes.
Test Bulk and Various Scenarios
Write tests that cover bulk scenarios (e.g., insert 200 accounts at once to see if your trigger handles large batches). Also test negative scenarios and edge cases
Use a Test Data Factory
Build a separate utility class that creates test data for your unit tests.TestDataFactory can have methods like createcontact() or createleads() to generate sample records with all required fields.
This promotes reuse and consistency, and avoids cluttering your test methods with repetitive object setup. Moreover, do not use SeeAllData=true in tests; always create the data you need within the test. This will make tests independent of org data and more reliable.
Test Lightning Components (LWC)
If you’re building LWCs, include Jest tests for the JavaScript side. These tests can simulate @wire data or user interactions and verify that the component behaves correctly. For example, test that when the Apex @wire returns no records, the component shows a ‘No results’ message, and when the data is present, it renders the list correctly.
Front-end tests catch issues in your client-side code and complement your Apex tests for a full coverage of your application’s functionality.
Investing in thorough testing pays off with fewer bugs in production and easier refactoring. It also gives you confidence during Salesforce upgrades (which happen thrice yearly) that your critical custom code still works.
7. Build Responsive and User-Friendly UI
A great user experience is key to user adoption. Keep these UI best practices in mind when building Salesforce apps By focusing on responsive, accessible, and user-friendly design, you ensure that your technical excellence on the back end is matched by satisfaction on the front end.
Conclusion and Checklist
Developing on Salesforce requires balancing clicks and code, ensuring security, and keeping performance in mind at all times. Following these best practices will help you deliver solutions that are trusted, scalable, and maintainable. Below is a quick checklist of key points covered in this post. Use it to double-check your work before you deploy your next Salesforce project:
- Use Standard Features First: Try declarative tools (Flows, formulas, etc.) before writing Apex. This reduces complexity and technical debt.
- Clean & Modern Code: Avoid using any deprecated APIs or old hacks. Stay current with Salesforce’s latest features (like using WITH USER_MODE for queries) for future-proof code.
- Structured Architecture: Implement a trigger framework and use helper classes. Keep code modular (separate concerns) so that each piece is easier to manage and reuse.
- Security First: Always enforce sharing rules (with sharing), and honor CRUD/FLS in code (or use user mode to enforce it automatically). No SOQL injection or hardcoded secrets – ever.
- Avoid hard-coding: Save IDs, URLs, and fixed values in Custom Metadata or Custom Settings instead of putting them directly in your code.
- Error Handling & Logging: Handle exceptions gracefully with try-catch, and log important events and errors. This will save you countless hours when debugging issues in production.
- Bulkify Everything: Ensure all Apex code (triggers, batch, etc.) can handle large volumes of data without hitting limits. Use collections and bulk DML/SOQL properly.
- Thorough Testing: Aim for high test coverage with meaningful assertions. Test not just the happy path, but bulk operations and error conditions. Include tests for async Apex and LWC components.
- User-Friendly UI: Build Lightning components that are responsive and accessible. Follow SLDS for consistent UX, and give users helpful feedback and error messages.
These practices have helped me deliver successful Salesforce projects for clients, and I’m confident they will help you as well. By adhering to these guidelines, you’ll reduce bugs, improve security, and create applications that scale smoothly with your business growth. Keep learning with each Salesforce release (they happen three times a year!), and continue refining your craft.
Happy Salesforce coding!
