Platform Developer-I Certification Maintenance (Winter’22) 💪
Staying Up-to-Date
Attaining a Certificate is a tough nut to crack and once you did, it feels like a Super-Hero. But as you know “With great power comes great responsibility”. It is true for certification as well. Clearing a certificate is just a mere beginning, maintaining it responsibly is the next step forward. Just keep in mind
“It’s not difficult to reach the top of the mountain. It’s much difficult to stay on it”
This blog will not only let you know your responsibility but also help you to fulfil it. First of all, let me grab this opportunity to congratulate all the Salesforce PD-I Certified trailblazers and a big congratulations to all those (including me 😀) who successfully maintained their PD-I Certification for the Winter’22 release.
This blog is for -
- Those who want to maintain their Salesforce PD-I Cert for Winter’22.
- Those who maintained it but haven’t implemented the new release features.
Now, for maintaining your Salesforce certification(s), the certified professionals have to complete Trailhead maintenance modules specific to their certification. However, all certifications now need to complete one maintenance module per year starting with the Spring ’20 release cycle.
It's a wonderful gift by Salesforce 🙏 to all the Certified professionals and relieved us a lot, but if you are unable to complete your maintenance module(s) by the deadline, all certification(s) maintained by that module will expire, or become suspended. However, if achieve a new higher-level or advanced certification, then also you will have to complete entry-level maintenance to maintain all of your certifications.
So, to maintain your Salesforce PD-I for the Winter’22 release you need to complete the following module.
Platform Developer I Certification Maintenance (Winter ‘22)
The above module is part of the “Maintain Your Salesforce Certifications” Trail which contains modules for maintaining various certs.
Now, you have to complete the above module before the deadline of PD-I Certification maintenance, i.e. 2nd December 2022. Yes, you got almost 11 months to complete and in fact, most of them have already completed it, but I am sorry to say that most of them have completed this module just for the sake of completion and hence I made this blog where you’ll not only know about the release but also to implement features of the new release. So without making any further delay let’s proceed with the maintenance.
Features that are introduced with the Winter’22 release for PD-1 are -
Customize map markers and controls.
Implement new methods to get custom metadata in Apex.
Update styles to remove BEM notation.
Investigate schema using SOQL FIELDS function.
Create Lightning Web Component Quick Actions.
Set up events in Lightning App Builder.
So let's discuss them one by one.
1. Customize Map Markers and Controls 🥰
Now, we can make our map look and behave the way we want. Now, we can -
- Customize map location to use SVG image instead of standard Google Maps markers or define a shaded circle, rectangle or polygon around a location.
- Modify or Disable the zoom and dragging feature.
- Disable the map controls altogether to create a static map.
This change applies to -
- Lightning Experience
- Lightning Experience Builder
- Salesforce Mobile App
Reason for applying change
- To show a simple locator map to customers to find your business.
- To remove the zoom and map satellite buttons.
- To disable dragging.
- To add your SVG to use a star for the marker.
To explain the scenario, I have made the following three lightning components, the first one with normal values, the second one without Zoom and Draggable features and the third one with all the new custom features.
The effect of all these components is as given below.
2. Implement new methods to get custom metadata in Apex 😎
Gone are the days when the developers need to write SOQL queries to fetch the Custom Metadata in Apex. With the Winter’22 release now the developers can fetch Custom Metadata records without taking the burden of writing SOQL queries for it.
Now developers can use the new Apex getAll(), getInstance(recordId), getInstance(qualifiedApiName), or getInstance(developerName) methods to retrieve custom metadata type records.
To explain the scenario I have created the following custom metadata in the org.
I have also inserted two records in this custom metadata, as shown below-
Just like any Custom Metadata, it has the following five standard fields —
- CreatedBy
- DeveloperName
- MasterLabel
- LastModifiedBy
- NamespacePrefix
- IsProtected
I have also created two custom fields in this metadata which are -
- Creation_Date__c (Type: Date)
- Resolved__c (Type: Checkbox)
Now definitely, we can write the following SOQL query to fetch the metadata records from the given Custom Metadata.
and the above apex code gives the following result when executed.
and in case we want a specific record from the metadata then we can use the WHERE clause with the Label or MasterLabel field of the metadata in the above SOQL query as follows to get the filtered result.
SELECT DeveloperName, MasterLabel, NamespacePrefix, Creation_Date__c, Resolved__c FROM Sample_Metadata__mdt WHERE MasterLabel= ‘Sample Metadata 1’
This is a traditional way of fetching Custom Metadata, with the new feature we can fetch custom metadata records as follows.
getAll() function- It returns a map containing custom metadata records for the specific custom metadata type. The map’s keys are the IDs of the records and the map’s values are the record sObjects.
Map<String, Sample_Metadata__mdt> sampleMetadata = Sample_Metadata__mdt.getAll();
As you can see the getAll function will return a Map with key as String type and value as Custom metadata type. So if you’ll print the keys of this map, it would behave as follow —
Set<String> setOfKeys = sampleMetadata.keySet();
System.debug(‘KEYS ==> ‘+setOfKeys);
KEYS ==> {Sample_Metadata_1, Sample_Metadata_2}
which is the DeveloperName of these metadata records and with help of these keys we can fetch details of each record.
and the result of the above code would be as follows-
One more point to be noted is that in case you want to work with individual fields of the custom metadata then the following code will do the needful.
Now the next three functions, getInstance(recorded), getInstance(developerName) and getInstance(qualifiedApiName) can be used to fetch specific records from the Custom metadata. These are overloaded functions, where the first one works with record id as a parameter, the second one accepts the developer name of the record as a parameter and the third one accepts qualified API name as a parameter. Though each function accepts a different parameter, all of them are used to fetch certain records from Custom metadata.
getInstance(recorded) function- It returns a single custom metadata type record sObject for a specified record ID.
getInstance(developerName) function- It returns a single custom metadata type record sObject for a specified developerName field of the custom metadata type object.
getInstance(qualifiedApiName) function- It returns a single custom metadata type record sObject for a qualified API name.
To understand the same you can compare the following code with our Custom Metadata.
So, it’s a happy goodbye to SOQL from Custom Metadata!
3. Update styles to remove BEM notation 🤔
Now, this implementation is because the “BEM Notation with Double Dashes Is Being Deprecated”. First of all, if don’t know what BEM is, then
‘BEM’ stands for Block-Element-Modifier which is nothing but a naming convention standard for CSS class names.
As you can see from the screenshot all these double dashes are to be replaced by an underscore. Hence the class name that was written
“slds-text-heading--medium”
would now be written as
“slds-text-heading _ medium”
Now, in case you are wondering why 🤔 then it is mentioned in the module as well —
“ Double dashes are not supported in XML files that include comments. This notation change was first announced in Salesforce Lightning Design System (SLDS) Release 2.3.1 on May 25, 2017, and announced again in the Winter ’21 release notes.”
4. Investigate schema using SOQL FIELDS function 🤘
Well, SOQL has some good news for their developers. 😊 SOQL made it easy to include predefined groupings of fields within a query statement. Well, it was something, I was waiting for. It was a feature that is available in most of the Database Query Language.
In most or I can say in all Structured Query Language we have a feature of ‘*’ which is a way of telling all fields. But SOQL was missing it, and hence we have to type the API name of all the fields that we want to include in our query. Quite boring! right?
But now, SOQL introduced fields() function, with help of which we can select all fields of an object. This function has been introduced in three variances.
- FIELDS(ALL)- Select all fields of an object.
- FIELDS(CUSTOM)- Select all the custom fields of an object.
- FIELDS(STANDARD)- Select all the standard fields of an object.
These functions respect the Field-Level Security, hence it will only show fields for which the current user is permitted to. In the module, the following is mentioned as a note.
Hence we wouldn’t be able to use the FIELDS(ALL) and FIELDS(CUSTOM) functions in Apex, and if you’ll try to do that, you’ll also end up with something as below, which I got while trying it out in the anonymous window.
The errors were due to the following statements.
List<Account> accs1 = [SELECT FIELDS(ALL) FROM Account];
List<Account> accs2 = [SELECT FIELDS(CUSTOM) FROM Account];
but the following statement worked fine.
List<Account> accs = [SELECT FIELDS(STANDARD) FROM Account];
But to remind you, these errors were in Apex only. You can certainly execute these queries in the Query Editor of Developer Console. Like I did execute these queries with the following results-
The result is quite clumsy due to that many fields. But we can test it out on any custom object as well. So, let’s see the result of the following queries one by one. One more thing to mark here is the use of LIMIT 200 with the FIELDS(ALL) function.
SELECT FIELDS(ALL) FROM School__c
SELECT FIELDS(STANDARD) FROM School__c
SELECT FIELDS(CUSTOM) FROM School__c
5. Create Lightning Web Component Quick Actions 🤩
Remember, the days when we want to add an LWC component as Quick Action and unwillingly we have to use Aura Components in between. Gone are the days of Aura Dependency.
Yes, Now we can directly attach our LWC as Quick Actions. This change applies to Lightning Experience desktop in Developer, Enterprise, Essentials, Professional, and Unlimited editions. Quick actions aren’t available in Experience Cloud sites.
Now, to make your LWC capable to be accessed as a Quick Actions option, you have to provide a few details in the LWC’s XML file. Please provide the following to the LWC’s XML file.
<isExposed>true</isExposed>
<targets>
<target>lightning__RecordAction</target>
</targets>
<targetConfigs>
<targetConfig targets=”lightning__RecordAction”>
<actionType>Action</actionType>
</targetConfig>
</targetConfigs>
Now, in case you’re willing to headless action, then you have to add an exposed invoke() method to your component as shown below-
@api invoke() {
console.log(“Hi, I’m an action.”);
}
In case you are wondering what are headless actions? Unlike a screen action, a headless action doesn’t open a modal window. So, enjoy using Quick Actions with LWC.
Keep a note that LWC Quick Actions are currently supported only on record pages. It is also not supported for Salesforce Mobile App.
6. Set up events in Lightning App Builder 👩💻
Now, this is the last amendment in the Winter ’22 release. With this release, you can now define the events for a Lightning web component on a page, and then expose those events in the Lightning App Builder. An admin can then configure the event by setting up interactions between the source component and its targets right in the App Builder UI.
Now for this, I have to explain Dynamic Interactions and hence it would be beyond the scope of this blog, but I promise to bring one blog on Dynamic Interaction as well and there I would explain this for sure. For now, just knowing how to expose an event would be enough.
To expose an event from a component, you fire a standard JavaScript CustomEvent in its .js file. To make the event discoverable, use the Dynamic Interactions–related targetConfig subtags in the component js-meta.xml file with the target lightning__AppPage.
event
Exposes the event for Dynamic Interactions and makes it available for the component in the Lightning App Builder. The event subtag supports the name, label, and description attributes.
name
The name of the event is defined in the component’s .js file. If no label attribute is defined, the name value is shown in the list of available events for the component in the Lightning App Builder.label
The admin-friendly label for the event.description
The description of the event, which displays in an i-bubble on the event label in the Lightning App Builder.
schema
Provides the shape of the event. Content in the schema subtag must be in JSON format.
Here’s a sample js-meta.xml configuration file for a custom Account List source component. It includes an itemselected event, and its schema includes apiName and recordId as defined in the .js file.
That’s it guys we have implemented all the new releases of Winter ’22. I hope you also enjoyed implementing them.
Thanks & Happy Trailblazing 🙏
You can follow me on -
