There are issues that just are not obvious at the first look. You might be pulling your hair out for hours. Misleading documentation (or just lack of it) can be one of the ways to end up at these situations. Another is just not paying enough attention. Whatever the reason, these things happen and often make interesting stories. Here I share some of the ‘Gotchas’ I ran into myself.
Subscribe to new posts
LWC in Purgatory
If you are delivering your SFDX projects using packaging you are likely aware of the challenges with moving metadata artefacts from one package to another. Particularly when moving up the dependency hierarchy. There is this very neat “trick” for Unlocked Packages where you can temporarily remove metadata from a package…
Accidental Permissions
Blowing the “Single Profile” approach out of the water When you install a package from AppExchange via the browser you get to choose whether to Install it for All Users, Only Admins, Specific Profiles or no-one. This really means if you want to grant full access to Classes, Pages, Fields…
UoW and SObject Instances
I previously talked about the need to be careful about how you register records as dirty with the Apex Common’s Unit of Work. There is another little gotcha to be ware of I recently ran into. Though when it does happen to you then you are probably doing something you…
Wasting Time in Disabled fflib Trigger Handlers
Did you know that you can dynamically disable fflib_SObjectDomain Trigger Handlers? You did? Ok then, did you know that when you do disable them their constructors run anyway? So be careful not to put any (expensive) logic inside those. For instance, I had some common related records that needed to…
UoW’s Dirty Little Secret
Did you know that you have to be super careful with registering records as dirty with a Unit of Work? If you happen to register the same record a second time you can lose your original registered updates. This is especially likely when you are trying to use the UOW…
Queueable Running User in Unit Test
I noticed that the Running User context of a Queueable Job in a unit test depends on who calls the Test.stopTest() method. While when code is ran normally (trigger, anonymous, …) the User context of the Queueable is the same as the user who put it on the queue. So if you…