Hot on the heels of the Trailhead Superbadges in June, we had another influx of new content in July.
Platform Encryption with Salesforce Shield
Shield Platform Encryption
Encrypt your data at-rest in the cloud and manage the life cycle of your encryption keys.
Encryption of sensitive data on the Salesforce platform is something that I’ve been asked about quite a lot during my time working on the platform. Back in the day we had encrypted fields, but there were a number of drawbacks to these. System Administrators had visibility of them by default, for example, they only worked on certain fields, and you had no control over the keys that were used to encrypt the data.
These days you have to work pretty hard to avoid encrypting your data in-flight, as Salesforce need to make a change to your org to allow you to use the unencrypted HTTP protocol. Encryption at rest, however, is a different matter and Salesforce Shield was introduced to provide a more full featured solution to this problem.
There’s a bunch of new administration tasks once you enable Platform Encryption with Salesforce Shield, but I like the fact that the Trailhead content doesn’t just cover that side of things. It starts with a discussion of the basics of cryptography — personally I’d like to see a lot more on this, but I accept that I’m probably in the minority with that view.
It also covers the softer t asks— rather than just turning it on and encrypting everything you can, take the time to assess both the sensitivity of data and the real threat that is posed by storing it in plaintext. Encryption slows things down and can make some tasks harder (searching has always been a relatively tough nut to crack) and definitely introduces some latency (encryption algorithms typically carry out a reasonable amount of processing on the source data over multiple passes, which uses up CPU cycles). Too often a sledgehammer approach is used, everything is encrypted and then shortly afterwards is found to be unworkable. Then begins the process of unwinding one at a time until a usable compromise is found, all the while annoying the users. While this is certainly one implementation approach, it won’t do much for your adoption!
There’s a couple of items in the content that I feel should be in flaming letters 10 feet high, just to reinforce the message:
- Back up keys (aka tenant secrets). Plenty of times in the past people have told me they’ll never forget their passphrase, only to forget it almost instantly and ask me to decrypt it through some magic access I’m assumed to have! If you lose the keys, you can’t decrypt without some form brute force approach based on trying all possible key combinations. If this wasn’t the case the decryption would be worthless, as anyone who had access to the secret decryption code would be able to access it without needing the keys. This is a good thing!
- Test in a sandbox before production. This actually goes for almost everything, not just Shield. Reports and dashboards make sense to build in production, but everything else needs testing first. Even more so when restricting access to the system or the data, as in this case.
- User permission sets over profiles. I regularly used to have to roll out variants around access to applications across 150+ profiles and I hope never to do it again. Always use permission sets — future you will be really grateful.
There’s also a couple of items I’d like to see covered:
- While you can restrict who has the permission set containing the View Encrypted Data permission initially assigned to them, any System Administrator is able to assign the permission set to themselves. Quis custodiet ipsos custodes? as they say.
- You can only generate tenant secret once every 24 hours — bit of a downside if you think it has been compromised shortly after it is generated.
There are two badges in this Trail — Basics and the Toolkit.
I first used Desk.com when Salesforce relaunched it after the Assistly purchase back in 2011/2012— I still have a Facebook page from then with the incredibly inventive name of “Bob Buzzard Desk.com” that I used to test out some of the social service features!
Since then I’ve read about the odd new feature, but not really taken that much notice. As a the CTO of a Platinum Partner, I’m working with enterprise customers who are better suited to the Service Cloud. Working through the new modules made it clear just how much it has come on as a product. It’s still squarely aimed at the smaller business but has a surprising amount of automation and analytics functionality.
This is another of the reasons that I really like Trailhead — the breadth of content means that I get to learn about parts of the Salesforce product line that I might otherwise not use. The intense competition around badges also ensures that I can’t leave any of them alone!
If I had one criticism about the desk.com content it would be that all the challenges are quizzes rather than actually having to do something in the application, although this may be down to the fact that it isn’t a full featured platform like Force.com. It does feel like a light touch test of knowledge though.
Sadly Desk.com doesn’t offer developer editions, so you sign up for a free trial that expires after 14 days. While you can obviously sign up with different email addresses, it does limit the amount of customisation that you’ll want to do as you have to start again each time. Although this did lead to a situation that I found entertaining. The free trial signup results in an email (which I assume is automated) asking you to set up a call to discuss your needs further. Given the volume of Trailhead enthusiasts, I’d imagine there were some excited sales people when this trail was released, made up about the sudden spike in trial signups and then gradually deflating as they realised it was all enthusiastic trailblazers solely interested in accruing badges!
What’s next for Trailhead?
The fact that there is a desk.com trail shows the power that the Trailhead “brand” now has. Every product manager in the Salesforce ecosystem must want content on Trailhead, as asking people to go to your Help and Training site is so 2010. Marc Benioff and Parker Harris keynoting the TrailheaDX conference also shows the buy in from the very top of the Salesforce organisation.
I’m really interested to see where Trailhead goes next — not in terms of content, which I’m sure will grow and grow, but at Salesforce events. How long before Dreamforce becomes Trailforce?
I’m better known in the Salesforce community as Bob Buzzard — Umpteen Certifications, including Technical Architect, 5 x MVP and CTO of BrightGen, a Platinum Cloud Alliance Partner in the United Kingdom.
You can find my (usually) more technical thoughts at the Bob Buzzard Blog