Sunday 21 February 2021

London Salesforce Developers Want Your Spring 21 Favourites

Since the UK went into first lockdown in March 2020, the London Salesforce Developers have met virtually over zoom. This works fine from the perspective of the talks and Q&A, but one area that is a real challenge to replicate is the casual conversations. Sometimes this is just general catch ups to talk about what we've been working on recently, which is something we can just about manage without. More problematic is that we aren't sharing the cool new features that we've just learned about, and that just isn't acceptable.

For that reason, our March 2021 event will be nothing but our members sharing their favourite feature from the Spring 21 release of Salesforce - we want to hear what you are excited about, and why!

So if you've spotted a hidden gem, sign up for our session on March 10th 2021 and tell us all about it. Don't delay - if someone else gets in before you, they'll get to talk about it!

You can sign up for the event here - once registered you'll need to fill in another form with details of what you want to talk about. You can also put in a backup choice or two, in case someone got in early and grabbed your favourite.

The event takes place on March 10th from 18:00 to 20:00 GMT - we'd love to hear from some internationals, so if you can make the timing work then please join us.

Thursday 11 February 2021

Spring 21 - AuraEnabled Apex and Sharing

(Updated 11/02 to fix typo on inherited sharing when Apex is invoked by starting a transaction. Mea culpa)


The Spring 21 release of Salesforce includes an update that may change the behaviour of your Apex classes that are used as controllers for Aura or Lighting Web Components. If your org was created after the Spring 18 Salesforce release, or you activated the (now retired) update

   Use without sharing for @AuraEnabled Apex Controllers with Implicit Sharing 

then by default your controllers run as without sharing, which means that they don't take into account sharing settings for the user making the request and allow access to all records. 

Once Spring 21 goes live, the

   Use with sharing for @AuraEnabled Apex Controllers with Implicit Sharing (Update, Enforced)

will be applied and this behaviour will be reversed - the default will be with sharing and access will only be allowed for records owned by, or shared with, the user making the request. 

Why the Change

In a word, security. This update makes your components secure by default - if you forget to specify with sharing or without sharing, the principle of least privilege is applied and the most restrictive option is chosen. 

The absence of a sharing keyword can also be considered a sharing keyword

I'm really not a fan of acts of omission driving behaviour, especially when that behaviour isn't guaranteed. Prior to the Spring 21 release, if you don't specify the type of sharing, there's no way to tell by inspecting the code itself what will happen. Anyone debugging an issue around sharing would have to know when the org was provisioned, or find out whether the earlier update had been applied, always assuming they could get access to production to find out!

Historically, one reason to omit the sharing was to allow the code to inherit the sharing from it's calling Apex. This allowed a class to execute as though :

  • with sharing is defined, if called from a class defined as with sharing
  • without sharing is defined, if called from a class defined as without sharing
which gives a great degree of flexibility, with the trade-off that the exact same behaviour applies if you forgot the sharing declaration rather than intentionally excluded it. A comment to clarify the intent could help here, but that's something else to remember.

Inherited Sharing

Winter 19 made a great step forward for forgetful programmers with the introduction of the inherited sharing keyword. This explicitly states that the the class will inherit the sharing from the calling code, so no need for anyone to try to infer what the missing sharing keywords might mean.  

A slight wrinkle to this is what does inherited sharing mean when the calling code is not Apex - i.e. when it is the entry point for a transaction and thus executed by the Salesforce platform? A great example of this is an @AuraEnabled class used as a controller for an Aura or Lightning Web Component, aka where we came in to this post! 

The good news is that the Apex docs explicitly call this out - inherited sharing means with sharing when it is the entry point for a transaction - the principle of least privilege again, but clearly documented so that everyone knows what behaviour to expect.

Call to action

So do yourself and your team a favour, and when you are checking your @AuraEnabled classes to see if they will be affected by the Spring 21 update, if you find any without a sharing keyword, add one to make it clear what sharing is being applied. Your future self will thank you, and it also means that Salesforce can flip flop around what the absence of a sharing keyword should be and your code remains unaffected.

Related Posts

Saturday 6 February 2021

Org Documentor - Flag Non-Display Fields


Towards the end of 2020, I pushed an update to the Org Documentor plug-in to include details of the page layouts that a field is referenced in. When I posted this on Linked In, I got the following comment from Anand Narasimhan (a blast from the past from the early days of the CTA program) :

Which chimed with some of the comments I'd received when I was asked to add this, around helping to retire old fields that weren't used any more.  This didn't seem like it would take a huge amount of work to implement, so I added an issue to the Github repository and forgot about it until today.


It certainly didn't take a huge amount of effort. As detailed when adding the page layout reference information, I build up a map of the page layouts that reference a field keyed by the field name. As I'm building a complex JavaScript object to pass to the EJS templating framework, I add the list of page layouts to a field property named pageLayoutInfo.  It was then simply a matter of setting the background colour for the field if the pageLayoutInfo property was empty. The slight complication was that if the field has been determined to be in an error (missing description) or warning (todo, deprecated in the field description) then it would already have a background colour and I wanted to leave that in place. 

All told, this was 4 lines of code (could be reduced to 3 with a wider screen ;):
  if ( (!field.pageLayoutInfo) && 
       (''==field.background) ) {

I then added a field to the sample metadata that isn't present on any page layouts - Internal Description - and regenerated the report, which highlights the field in pink as expected:

Bonus Changes

In response to an issue raised from the community, I also added the ability to configure the name of the report subdirectory for a metadata type via the reportDirectory property in the configuration file. The sample repository has been updated to write the pages pertaining to the objects metadata to the objs directory. If you don't provide the reportDirectory property, it will default to the metadata type name - e.g. objects, triggers. I've also added an issue to document the configuration file properties, as right now there is an example file and I leave everyone to draw their own conclusions.

I also fixed a bug in the aura enabled pages that detail the Apex controller classes for aura components - if the component extended a super component it all went to hell, but now it handles that correctly.

Updated Plug-in

Version 3.4.6 of the plug-in has this new functionality and can be found on NPM

If you already have the plug-in installed, just run sfdx plugins:update to upgrade to 3.4.6 - run sfdx plugins once you have done that to check the version.

if you aren't already using it, check out the dedicated page to read more about how to install and configure it.

The source code for the plug-in can be found in the Github repository.

Related Posts