Winter ‘19 has already started its preview cycle within sandboxes last weekend. Before diving into those goodies, are you up to speed Summer ‘18? Here’s some to get you started:
Hittin’ The Switches!
Can you believe it’s finally here?! The pivotal switch-case statement (minus the ‘case’) has finally made its way to Apex! Want to do something different based on a certain picklist value? Or possibly whether something is on a date before/on/after a certain date? Now you too can write code like all the cool kids! And don’t worry, no need to concern yourself with fall-throughs… it’s not in the Apex switch paradigm.
Here’s an example using Opportunity.StageName as the switch expression:
Scramblin’ Man!
So, remember that policy a while back involving personal information called GDPR? I know, it wasn’t as huge as TLS 1.0 disablement, but you may have run across it on one of your feeds. Well, in order to help comply with regulations such as GDPR, Salesforce now offers a way to (ahem, PERMANENTLY) scramble personal information on a user record. A few fields are unaffected such as UserId, TimeZoneSidKey, LocaleSidKey, and ProfileId.
Here’s how you would enable the use of this functionality:
1. Navigate to Setup, and find User Management Settings in the left navigation bar
2. Enable the “Scramble Specific Users’ Data” setting
3. Use the System.UserManagement.obfuscateUser(userId) method in any context you would normally use Apex. Documentation found here.
Here’s My Number, so Store Me Maybe!
Phone number formats are a tricky situation, especially when dealing on an international scope. Plus sign before the country code? Separate area code with parentheses/hyphens/spaces? Now you can allow more variation in the inputs your users enter and send the result to the new Apex method System.UserManagement.formatPhoneNumber(countryCode, phoneNumber).
Stop Memorizing Those Package ID’s!!
We know you’ve spent hours memorizing the ID of your favorite package or package version (you know, 04tB0123abcJm1EIAW?) Well, just like org aliases, packages now come with the ability to be aliased. You can even use these aliases when defining package dependencies for other packages!
Here’s an example. Let’s say you have a package for your organization that contains a lot of utilities the rest of your organization uses. You can now do the following:
Record Type Developer Name from DescribeSObjectResult FINALLY!
If you’re a developer who has ever dealt with doing something dynamically involving record types, you know the pain. Record type name (a.k.a. “label”) was available through describe information in Apex, but not the developer name. Well, fret no more! No longer will you need to hard-code record type IDs in your Apex code. Here’s an example of how you might use this:
