About Salesforce

I’ve had a pleasure to watch many Salesforce technical architects trying to find a perfect way, how to work with Record Types in Apex . One created class Global_Constants to store all Record Type Ids and DeveloperNames in static properties, the other queried RecordType table and put the result in the map. I was never impressed so I‘ve come up with Record Type Provider , that allows you to access RecordTypeId like this: RecordTypeProvider.[ObjectName].[RecordTypeName].Id . It’s not perfect, but it definitely has its pros. What doesn’t work First, I would like to stop by the usual solutions and explain, why they do not work (well). Querying the RecordType table is extremely fast – you get all the Record Type descriptions in few miliseconds, but on the other hand you lose what every Salesforce developer must treasure the most – SOQL query . You may think, that you have only limited amount of classes and this one tiny query will never mean anything, but over time logic in your o

Have you ever thought, how to test scheduled batch ? If your answer is no, because Test.startTest() and Test.stopTest() would do the job for you, you are not entirely right and you may find this article interesting. Clean the mess! For start let's define some "more-or-less" real life scenario for those, who want to follow in their orgs. We have a custom object Log ( API Name: Log__c , Name Type: Auto Number ), that we use to log exceptions, integrations and some other events worth saving. Custom object has several fields containing information like error message and stack trace, but it is not really important for our purpose. Unfortunately our predecessors (or anyone else we can easily blame) didn’t do their work properly creating immense number of bugs in the system and our object is overloaded with logged exceptions and takes too much of the storage. Fixing all the bugs in the system will take months, so we need to take care of the storage first. Our 2 000 hard-wo

It is almost 18 months since Salesforce finally introduced one of the most eagerly anticipated features for Apex - switch statement . Does it even make sense to comment it today? I can only guess it was because of general familiarity with the switch statement , good documentation or simply happiness over surprising birth of a son you stopped dreaming about years ago, but no one has ever questioned it ! Why do we love switch statements ? We've had switch statements in other programming languages since the dawn of time and if not, it was definitely long before I was born. Therefore reasons to use switch statements over if and if else statements are also clear and kind of indisputable. It is preferable to use switch , if you can agree with following statements in your programming language and of course specific situation you are in: Code is easier to read and therefore it is easier to understand and maintain Code is easier to debug Code is faster to execute