Reliable

Record-triggered flows are automatically launched every time a record change. As a best practice, an entry condition should be used to ensure the flow is only fired when required.

In Salesforce Apex, Schema.getGlobalDescribe is a method that allows developers to dynamically fetch metadata information about all objects in the Salesforce schema. While this offers flexibility, it can be resource-intensive, especially in orgs with numerous custom objects and fields, consuming CPU time and memory, and contributing to governor limits like CPU time limits.

Salesforce enforce a limit on the number of SOSL and DML statements per transaction. Reading or writing data inside loops is highly likely to hit such limits.

Salesforce limits the maximum number of rows that a SOQL query can return to 50,000 records. When this number is exceeded, a runtime exception is thrown. As a best practice, developers should always use either a WHERE or a LIMIT clause to cap the maximum number of results.

Salesforce recommends including any additional JavaScript files by using static resources. Importing scripts differently, for example, loading them from a CDN, is discouraged for performance and security reasons.

Even though Apex written within an asynchronous method gets its own independent set of higher governor limits, the number of @future methods that can be invoked within a single Apex transaction is limited. Calling an asynchronous method from within a loop is highly likely to hit these limits.

In Apex, when a batch of record updates fire a trigger, a single instance of the code is executed. Therefore the code within the trigger needs to handle all of the records within that batch correctly.

Flows should not perform database changes as part of a loop path, as it will likely hit governor limits. Applying all database changes at the end of the flow is typically best.

Salesforce allows a limited number of 10 calls to the Messaging.sendEmail method per transaction. Any invocations of this method within a loop makes it likely to reach or exceed Apex governor limits.

When querying large objects, non-selective queries take a very long-time and may cause different programmatic elements (such as Apex triggers or batch Apex classes) to fail.