Automated

Exposing log messages in your production code is considered an anti-pattern. Removing debug statements after development avoids generating unnecessary verbose logs that may expose too much information.

When attempting to save multiple records as part of the same operation, one should always assure that the database isn't left in an inconsistent state in case of error. Using transaction control (savepoints and rollback) allows rolling back partial changes in case of error and preserves data integrity.

As a best practice, errors on database manipulation should be handled to let the application manage error scenarios.

A server-side JSON and XML injection can happen when data from an untrusted source is not sanitised by the server and written directly to a JSON or XML stream.

Using a single type of automation per object keeps your application easy to maintain and less prone to errors.

Flows that perform record lookups should make sure that the records are found. Not performing such a check may cause the Flow to break.

Flows that interact with the Salesforce database can fail. As a best practice, all fault paths should cover by error handlers.

Null Pointer Exceptions (NPEs) are one of the most common errors in Apex applications. The safe navigation operator (.?) short-circuits expressions that attempt to operate on a null value and returns null instead of throwing a NullPointerException, making the code less likely to fail.

The null coalescing operator (??) replaces verbose and explicit checks for null references in code.

Record IDs change between environments. For this reason, any logic that uses hardcoded IDs will fail when deployed to a different Salesforce environment.

Logic in triggers can't be exposed for test purposes and cannot be re-used anywhere else in your org. As a best practice, developers should avoid placing any business logic directly inside triggers. Instead, one should use a handler class or a trigger framework.

Each time a record is created or updated, all record-change processes for its object are executed. Using only one record-triggered flow keeps the order of operations predictable and reduces the risk of hitting governor limits.

Record IDs change between environments. For this reason, any logic that uses hardcoded IDs will fail when deployed to a different Salesforce environment.

The act of creation of an object should not alter data on the server-side or have any other significant side-effect. For this reason, using DML statements inside constructors is considered unsafe.

Salesforce has changed the behaviour of the Type.forName Method. Using an invalid namespace while calling the Type.forName() method now returns null. Previously, Apex allowed you to specify an invalid namespace such as Type.forName('InvalidNamespace', 'OuterClass.InnerClass') or use an outer class as a namespace such as Type.forName('OuterClass', 'InnerClass') with indeterminate results.

As a best practice, the registration of new platform users should be somewhat controlled or limited (i.e. using Captcha) to avoid being hijacked by malicious actors and prevent consuming an uncontrolled amount of licenses.

Lightning Web Components use Shadow DOM to protect the component from being manipulated by arbitrary HTML, CSS, and JavaScript. Bypassing the Shadow DOM gives developers greater control but is strongly discouraged as it significantly increases the risk of Cross-Site Scripting (XSS) and code injection vulnerabilities.

Having various triggers on the same object typically leads to unnecessary queries, non-deterministic behaviour and significantly lower maintainability.

When creating APIs that send emails programmatically, it's essential to include logic to ensure that messages get sent only if certain conditions apply (for example, CAPTCHAs) to reduce the risk of spamming by bots, sometimes also known as "email flooding".

Record IDs change between environments. For this reason, any logic that uses hardcoded IDs will fail when deployed to a different Salesforce environment.