Skip to main content

Posts

Showing posts with the label Apex

SF Fact #03 | Undelete Failed, Entity is not in recycle bin

  Similar to ENTITY_IS_DELETED error, if we attempt to undelete a record from recycle bin by mistake which has already been hard deleted, the following error is encountered: UNDELETE_FAILED. When a record is deleted, it moves to the Recycle Bin. This is known as "soft deletion," allowing the record to be easily restored through the user interface. However, under certain conditions, a deleted record will no longer appear in the Recycle Bin: Master-Detail Relationship (Child Deleted First): If a record is a child or detail in a master-detail relationship and it is deleted before its parent record, then after the parent is deleted, the child record transitions to a "hard deleted" status. In this state, the child record cannot be recovered through the Recycle Bin and must be recreated if needed. Master-Detail Relationship (Parent Deleted): If a record is a child or detail in a master-detail relationship and the parent record is deleted, the child record is also soft del...

SF Fact #02 | Database.querywithBinds() usage

  Dynamic SOQL refers to constructing a SOQL query string at runtime using Apex code. This approach allows for more flexible applications. For example, you can create a search based on user input or update records with different field names. Creating Dynamic SOQL Queries To create a dynamic SOQL query at runtime, use the Database.query or Database.queryWithBinds methods in the following ways: Single Record Query : sObject s = Database.query(string); Multiple Records Query : List<sObject> sobjList = Database.query(string); Query with Bind Variables : List<sObject> sobjList = Database.queryWithBinds(string, bindVariablesMap, accessLevel); These methods can be used wherever inline SOQL queries are used, such as in assignment statements and for loops, and are processed similarly to static SOQL queries. API Version 55.0 and Later: User Mode for Database Operations With API version 55.0 and later, the accessLevel parameter allows running the query in user or system mode:...

SF Facts #01 | system.typeexception: unsupported sobject type and/or version

  Error Encountered While Accessing Custom Metadata Records Using Built-in Methods: Error Message: system.TypeException: Unsupported sObject type and/or version Cause: This error occurs because the metadata type methods were introduced in API version 51. If your Apex class is using an API version lower than 51, it will not support these methods. Solution: To resolve this issue, update the API version of your Apex class to version 51 or higher. By updating the API version, you ensure that your Apex class can utilize the built-in methods for accessing custom metadata records without encountering the unsupported sObject type and/or ersion  error. Feel free to share your view and comments.

Determine the execution context in apex

      The Quiddity Enum stands out as a highly valuable but often overlooked feature, offering one of the most effective means to grasp the context of Apex execution. Leveraging Quiddity allows us to discern whether an Apex method is invoked from Lightning Web Components (LWC), Aura, or an Anonymous context. Explore the comprehensive documentation linked below to discover the full range of contexts supported by Quiddity. Below is the Example of Quiddity. public List<Account> getAccountsWithQuiddityGuard () {       List<Account> accounts = new List<Account>();               public static List<Quiddity> allowedQuiddities = new List<Quiddity>{              Quiddity.QUEUEABLE,              Quiddity.BATCH_APEX,      ...

Sharing records by Apex in Salesforce

  Greetings, everyone! In today's session, we'll delve into the topic of sharing records within an Apex class. As we're aware, there exist various methods through which we can accomplish the sharing of records. We engage in record sharing primarily when the object's Organization Wide Default (OWD) settings are set to private. Sharing settings come into play when certain predefined criteria are met, allowing us to extend access to records to designated groups or roles. In cases where intricate logic is involved, manual sharing is employed. While this approach proves beneficial for specific records, instances where a multitude of records require automated handling, Apex sharing becomes the preferred solution. Salesforce offers a 'Share' object for each type of object, with distinct naming conventions: For standard objects, it's 'StandardobjectName+Share', such as 'AccountShare' for the 'Account' object. Custom objects follow the pattern...