As Clayton’s founder, I have been working with dozen of Salesforce teams throughout my career. As I look at how they manage their code reviews, there are 3 things that most of them miss. In this short blog post I will share them with you.
This simply means that the object and field-level security permissions you set can by bypassed. Many believe this is not a big deal for internal Orgs, but it is – especially when you keep sensitive data or when you have external users.
Primary impact: risk of customer data leaks.
Using open source library is a great way to accelerate development, but it often comes at the expense of security. Most teams bundle third-party JS in their static resources. When vulnerabilities are discovered for those libraries (it happens all the times) no one notices and the security flaw stays hidden.
Primary impact: code injection vulnerabilities.
Creating data with new in test methods
Not centralising how test objects are created is one of the easiest way to cause rework. All test methods that instantiate sObjects directly via new will break as soon a new validation rule is introduced. Depending on how many tests you have, this could easily cause tens of hours of rework.
Primary impact: regressions.
These problems are sneaky: they require inspecting many files at once, and cannot be detected by tools like PMD, that simply check the syntax of your source files. We have built Clayton to automate these and many more problems out of existence, so you can build more, and worry less.
If you want always-on coverage for your Salesforce application, let’s have a chat about how Clayton can help you.
What is your business’s biggest Salesforce challenge?
Book a free, 30-minute call with Salesforce CTA and Clayton founder Lorenzo Frattini to discuss your business’s biggest Salesforce challenge. Talk to us about technical debt, security best practice, hiring new devs, rapidly scaling teams, dummy unit tests and offshoring development. Book a slot here.