Salesforce Facts by Abhishek

We know that using a package.xml file in VSCode we can deploy or retrieve metadata from the connected org. But do you know the location of this package.xml is important. When we create a new SFDX project with Manifest, then it is placed inside a folder called Manifest which is the correct structure. But suppose if you have already created the project without Manifest and later on adding the package.xml file. Then, we need to create a new folder named 'Manifest' and inside that create the file package.xml and then you can retrieve or deploy the metadata successfully. If we try to create and keep the package.xml file outside the folder, it will throw the error: 'The file or directory that you tried to deploy or retrieve isn't in a package directory that's specified in your sfdx-project.json file'. Attached are the screenshots. To resolve the error, we need to keep the file inside Manifest folder.

Have you come across errors while changing owner ids of records which involve queues? Let's see few of them. Error1: This error happens when you try to assign a queue as the owner but the  SObject  does not support a queue as the owner. For example, if you try to assign a queue as an account owner by mistake, this error will be encountered since Account object does not support queue as an owner. Error2:  This error happens when a queue is supported as the owner for the SObject, but you are trying assign a queue which is not supported by the current object, which supports some other  SObject . For example, Case and Lead both objects can have queue as owner. Now, if you try to assign a queue which is supported by Case as the owner of a Lead record, you would get this error.

Do you know there is an object MatchingRule in Salesforce which stores the details of all the matching rules in the org. So we can use this object in screen flow to get the details and show the same to the user. Attached are the screenshots.   Note: There is a field named SobjectSubType on MatchingRule object which can have either 'None' or 'PersonAccount' as value. If the rule is for a PersonAccount, the value is automatically set to 'PersonAccount' else it is 'None'. However, for standard matching rules present in the org, the field is blank. For more details, check out: https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_matchingrule.htm

Do you know what is 'Holdout' in context of territory management. A Holdout scenario occurs when a user owns the opportunity that's assigned to a territory but the user isn't assigned to the territory. For details check out, https://help.salesforce.com/s/articleView?id=sf.forecasts3_territory_forecasts_overview.htm&type=5

Do you know we can query records from CaseTeamRole object irrespective of seeAllData setting in test class. However, for CaseTeamMember we need to create records in test class. The existing org records are not automatically available. Attached are the screenshots.

Suppose we have a use case where we need to find the Nth highest value of a number field in an Object. We can get the same using SOQL. In this example,  we are getting the 2nd highest value of NumberOfEmployees in Account object. Here is the SOQL: SELECT NumberOfEmployees FROM Account GROUP BY NumberOfEmployees ORDER BY NumberOfEmployees DESC NULLS LAST LIMIT 1 OFFSET 1. Here OFFSET=N-1.

The force:source:deploy command is not transactional and attempts to deploy all components. If any component has errors, it skips those and deploys all changes that are valid and compile. On the other hand, the force:mdapi:deploy command deploys all the components if none of the component have errors. If any component has errors, it rolls back the entire deployment. Thus, it maintains integrity during deployment. Trailhead module reference:  https://trailhead.salesforce.com/en/content/learn/modules/org-development-model

While using Fields(Beta) option in screen flow, do you know the execution context and FLS defines the field visibility to the user. In this example, we have made the Account Type field as read only for a profile. Now, when the flow runs with the option: User or System Context - depends on how the flow is launched, then the field does not appear to the user. But for the other two options related to System context, the field appears and it is read-only to the user. Attached are the screenshots.

Continuing with the previous use case, we can use an alternative approach as well to maintain the correct order of indexes. We can create a list equal to the size of session keySet and populate the keys in the respective indexes. Attached is the screenshot.

If we store the numeric indexes on the Salesforce org Session Cache as String value and if we try to retrieve them using getKeys() method, it returns a sorted set and there could be issue if there are more than 9 values since the comparison is based on String, not numeric value. As a workaround, we can use the length of the keySet and iterate to get the correct value as per the index value. Attached is the screenshot.

If we try to populate the value of an auto-number field by mistake during record insert/update from apex, we get the error 'the field is not writeable'. But do you know in case of record-triggered flow, we get a different error message: 'Invalid target field for field update'. Attached are the screenshots.

Do you know you can delete a role only if it is not assigned to any user. Additionally, on deletion of the role all the associated sharing rules which refer to this role, also gets deleted. So, we should check whether the role is referenced in any sharing rule before deleting it. There is also an idea on ideaexchange:  https://ideas.salesforce.com/s/idea/a0B8W00000GdebVUAR/when-deleting-a-role-warn-if-dependent-sharing-rules-will-be-deleted

We can write validation in case of record undelete as well in the apex trigger. Attached are the screenshots.

Do you know there is a formula function named ISCLONE() which lets you check whether the record was cloned from an existing record. The formula/validation rule is applied when we create a record from apex code as well using the clone() function.

For boolean fields, we generally use TRUE/FALSE during SOQL. But do you know that if we use NULL as the filter it is same as using FALSE. However, during insert/update record we need to use FALSE explicitly, else we will get error. Attached are the screenshots.

We know that dependency on the values can the defined between picklists. This is ensured while we are creating or updating records from the UI. But do you know while creating/updating records from API or data load picklist values can be inconsistent if both the controlling and dependent picklist values are not specified. In this example, we have two picklist fields on Account: Picklist1 & Picklist2. Picklist1 has two values: valueA, valueB and Picklist2 has three values: value1, value2, value3. The dependency set up is like this: valueA-> value1, value2, value3 & valueB->None. Now when updating records from the UI, whenever we select valueB, the dependent value sets to None. However, if we update the record from back end specifying only controlling picklist value, only that gets updated & the dependent one remains the same leading to inconsistency. So we should be careful while updating picklists having dependency. Attached are the screenshots.

Suppose we have a similar method logic which gets called by LWC and Flow. Now, we can create two different methods since LWC expects @AuraEnabled(Cacheable=true) annotation, whereas flow allows @InvocableMethod annotation. But we can simplify this by keeping the logic in the method annotated with @InvocableMethod and calling this method from the other method. This avoids writing redundant code and keeps it simple. Attached is the screenshot.

We often encounter SOQL and DML errors in apex. Do you know that unsuccessful SOQL and DML statements count towards Governor limits. Attached are the screenshots. To know more about Limits class functions, check out:  https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_methods_system_limits.htm

We have lightning-checkbox-group base lightning component in LWC which shows multiple checkboxes as a group. Suppose, we have a use case where we need to select only one checkbox at a time. We can get the same by using some logic on onchange handler. Attached are the screenshots.

Continuing with the last use case, we can create an utility function which will get the metadata values using built-in functions and it won't get counted towards Governor limit. The function will take the API name of the custom metadata and would return the corresponding metadata records.  Every time a new custom metadata gets created, we can create an entry in this function.  The function is invocable from flow. Attached is the screenshot.

Continuing with the last use case, we can skip the SOQL query rows count as well from the Governor limit if we use built-in custom metadata methods instead of SOQL. Attached are the screenshots.