Apex Code – Sara Has No Limits

Farewell Package.xml…you will not be missed

Salesforce’s Spring 21 release has brought about a lot of big changes. Some I am not so thrilled with, but one has so far been nice to see.

Sandbox Source Tracking went GA with this release. This is meant to help us poor developers keep track of all metadata changes between our local VS Code source repositories and the actual Sandbox/Scratch orgs.

In a nutshell, it appears to me that the dreaded package.xml file will be going away, eventually. This file has caused far too many problems (especially for teams of developers). Instead of having to manually track all metadata data changes, Salesforce will automatically keep those changes synchronized between your local development workspace and the org. THANK YOU Salesforce!

Now before you get too excited, this is NOT going to be an easy transition. For starters, a force:source:pull will not get you all the metadata from an org. I experienced problems just trying to do a simple demo with a scratch org this past weekend, using brand new code.

I anticipate a lot of customers are going to experience huge problems as a result of this change. This will be especially difficult for legacy customers with huge monolith orgs that have not been untangled.

But, I do believe this step is necessary to allowing all Salesforce developers to really emerge from the 90’s and start doing serious modern web development. Before you go too far with this, you need to know what you are dealing with. Start by checking out this Developer Blog article. I am sure there will be lots more Trailhead modules/videos etc to come on this.

So, this is not some “magic pill” to solve all development/deployment problems. But, it is a good first step. Looking forward to seeing problems addressed and enhancements made.

Top 5 Tips for Working with Salesforce Extensions for Visual Studio Code

After spending quite a lot of time working with the Salesforce Extensions for Visual Studio Code and discovering many hidden gems, here is a list of my top 5 tips. Hope they help you in your development journey.

#1 – Install the Expanded Extension Pack

This VERY handy version of the regular Salesforce Extension Pack, includes not only all the core SFDX plugin’s, but all the third-party ones you might need, like Prettier, ESLint, etc.

#2 – Run Update as Often as Possible

This is perhaps the MOST important tip I will offer. Unlike the rest of Salesforce software, the SS Salesforce Extensions are updated every week. That’s right. And they are constantly adding really cool features, so if you have not run…

sfdx update

in a while, you are probably wayyyyy behind and need to do it immediately!

#3 – Use the CLI Help Feature

For all of you that depend solely on the Command Palette, you really need to start using the built-in help that is offered. Come on, the Terminal is not that scary.

Not only will you get access to some really helpful info, but you will learn a heck of a lot about the CLI in general. Start by just typing sfdx help.

Go even further down the stack, but use –help past the first level. For example, to see the help for the project create command, so the following:

sfdx force:project:create --help

#4 – Use Code Completion and Snippets

If you do a lot of work with Apex, then you definitely want to check out using the Code Completion and Code Snippets features. This can be really helpful when creating Apex classes or triggers (especially if you are like me and do not do it that often).

#5 – See all SFDX Commands

When you are first learning how to work with the extensions, it can be helpful to see a list of all the available commands. This is accomplished by entering the following command: sfdx commands

New Pluralsight Course: Getting Started Customizing Salesforce with Lightning Aura Components

I am very proud to announce the release of my latest Pluralsight course, “Customizing Salesforce with Lightning Aura Components“. This is actually a total re-write of my most popular course, “Customizing Salesforce with Lightning Components”, released in 2017. The key word change in the title is the addition of the word, “Aura“.

New Pluralsight Course, which includes working with VS Code and the CLI

This course is different because at the time that course was released, Lightning Components were not called Lightning Aura Components AND most importantly, the new modern toolset known as Salesforce DX was not yet available. There were also no Lightning Web Components available yet.

I personally believe that for many developers, transitioning to LWC would be much easier if they were to first learn to build simple Aura components using the new modern tools first.

In this course, all those great shiny new tools will be used to build very simple Aura Lightning Components. The original course used the online Developer Console, which is what Trailhead still uses in all their content about Aura Components. On Trailhead, the new tools are only used for Lightning Web Components.

So, if you want to learn about building Aura Components, while also embracing the new modern toolset, this course is perfect for you. And if you want to learn about Lightning Web Components (LWC’s), then you can check out the “Building Your First Lightning Web Component (LWC) for Salesforce” course that I released earlier this year.

Either way, you will be knowledgeable in all the latest that Salesforce has to offer. I personally believe that for some developers, transitioning to LWC would be much easier if they were to first learn to build simple Aura components using the new modern tools first.

This course includes a GitHub Repo that features all the code covered in the course. The material covered includes the following:

Understanding the Lightning Component Framework

Refer to the following blog post #1 . In this post/Pluralsight module), you will learn:

Who Should be Building Aura Components?
Where Can Aura Components Be Used?
Anatomy of an Aura Component Bundle
Creating an Aura Component Bundle

Creating Aura Components with the Salesforce CLI

Refer to the following blog post # 2 .

Using an Interactive Development Environment (IDE)
Getting Setup with an IDE
Understanding Salesforce DX (SFDX)
Creating an Aura Component in Visual Studio (VS) Code
Exposing Aura Components to Lightning App Builder

Working with Data

Refer to the following blog post # 3 .

Working with Controllers
Working with Apex and DML
Creating a New Open Cases Component
Using the CLI to Load Data to Scratch Org
Enforcing Apex Security
What About Caching and Usability?

Working with Record Forms

Refer to the following blog post # 4 .

Working with Record Form Base Lightning Components
Creating a New Quick Case Component
Creating Quick Actions

Working with Salesforce Mobile

Refer to the following blog post # 5 .

Working with the new Salesforce Mobile App
Using the Salesforce Mobile App QuickStart Page
Wrapping Up

Check out the Salesforce API Explorer

In an attempt to make things easier for us developers, the Developer Relations group has created a nice little tool called the Salesforce API Explorer.

Screen Shot 2018-08-23 at 1.48.18 PM

What It Includes Now

The first thing you should know about this tool is that it is still in Developer Preview and the team that created it is actively seeking feedback on how it can be improved. You can submit feedback right from the Send us Feedback link at the top.

As of this writing, there are only the following two API’s featured here:

Force.com REST API
Marketing Cloud REST API

How You Can Help

Remember when I said this was still in Preview mode? Well, you can easily vote on which API’s will be included next by clicking the like button underneath the API’s listed in the “Which API’s would you like to see here next?” section. Please take the time to go through the list and vote for which ones you would like to see appear next. Come on. You can’t complain about a lack of good documentation without taking the time to be part of a solution.

Why It is So Cool

This Explorer tool is not only cool because of the fact that it will list all the API’s in one place in a nice readable way. But, it is VERY cool when you consider the nice “Try it now” feature that lets you see the results of executing any of the API calls against your developer org. You just need to provide credentials for your org.

You will then select a Resource, such as Account and then an endpoint, such as FindAccountById. Not only does this show you all the documentation you need for that endpoint, but you can try it out by doing the following:

Click Try it Now
Enter any path parameters (if needed), such as the Account ID
Click Execute
A Live response appears on the right

Screen Shot 2018-08-23 at 6.35.09 PM.png

Boom! You don’t have to go into workbench. You can do everything you need right here in the explorer tool. Cool, right?

Goodbye Force.com IDE Beta…Hello Visual Studio Code

Back in 2016, I wrote a post here about how the Force.com IDE was making an epic comeback, with support for Lightning. At the time I was very excited to see that Salesforce was refocusing it’s efforts towards improving that tool in the form of a Beta. Even though the Force.com IDE was the original tool that Salesforce offered and it had a long history with the development community, it had failed to keep up with the bevy of tools now being offered by third-parties.

Fast forward to today and the recent announcement by Salesforce that the Force.com IDE Beta has been officially discontinued.

So where does that leave Salesforce developers?

Well, not as bad as you might think. Salesforce is not giving up on supporting a local IDE. Nor are they giving up on the original version of the Force.com IDE (at least not just yet). So far, only the new Beta will be discontinued.

It is just that they are focusing their efforts towards improvement of the Salesforce Extensions for Visual Studio (VS) Code. It just made no sense to support two tools and after analyzing feedback from the Beta of the Force.com IDE, the team had to make a clear choice and Salesforce Extensions for VS Code came up the winner.

I personally prefer Visual Studio Code and there is no question that it is easier to install than Eclipse (which was always a bit of a nightmare imho with all the required Java installs it required). I also like how intuitive it is and that I can use it to do all sorts of other modern development. If there is a popular modern language out there, you can safely bet that VS Code supports it.

If you have not had a chance to check it out yet, I highly suggest you do so and just remember to keep an open mind.

Also, be aware that Salesforce Extensions for VS Code does not yet support everything that the Force.com IDE does. Like I said earlier, the original Force.com IDE is not going away, just the newer Beta version which included support for Salesforce DX and Lightning. It is going to take some time for the development team to get all the features that the Force.com IDE offers into Salesforce Extensions for VS Code.

But keep in mind, that VS Code is where they are headed, so if you have not yet checked out Visual Studio Code, now is the perfect time to do so. I think you will be pleasantly surprised and impressed with it.

And let me know what you think…

Salesforce Play By Plays on Pluralsight

My good friend Don Robins has been hard at work putting together a new series of Play by Play Pluralsight courses that are all about Salesforce development. This is all part of a deliberate attempt by Pluralsight to greatly expand the Salesforce portion of their library. Which, in case you have not noticed, has grown quite a lot in just the past year – with lot’s more good stuff to come.

If you are not familiar with them, courses in the Play by Play series are not your typical Pluralsight courses. They are more of a dialogue or open-end discussion in which the host, Don Robins interviews Salesforce MVP’s about topics they are the most knowledgeable and passionate about. Don does a great job of channeling all the best talk show hosts, as he playfully challenges each MVP, asking all the questions the viewer themself might ask. It is not so much of a “watch me do this” as it is a “so this is why I am thinking of doing this particular thing and here are a few ways I might do it”.

There are currently 4 Play by Play videos available and they cover the following topics:

Moving Visualforce Code to the Lightning UI in Salesforce

Featuring non-profit guru and certified developer and administrator Bonny Hinners, this Play by Play walks you through things to consider when moving your legacy Visualforce code to the new Lightning Experience. This is a topic I also cover in my course and is one that I think many Salesforce developers will be pondering over for years to come.

Managing Data in Salesforce Using Apex

In this Play by Play, Don sits down with Dan Appleman, Salesforce MVP and author of Advanced Apex Programming, to discuss all the gotchas you need to consider when working with data in your org. He will alert you to the common pitfalls that most developers make and lead you towards a better way of approaching your trigger code and unit tests.

Knowing When to Code in Salesforce

This is perhaps one of the most important topics for Salesforce Developers and one that is covered in depth by Don and Salesforce MVP and new Pluralsight superstar, David Liu. David introduces a common scenario and then talks through all the different ways the solution could be achieved. Beginning with custom fields and then moving on to Workflow Rules, Process Builder, Flows, and finally when there are no other options, Apex code.

How to Mobilize Your Salesforce App

Featuring mobile expert and Salesforce MVP, Gaurav Kheterpal, you will learn about all the different ways you can approach mobilizing your Salesforce apps. Starting with the easiest but least flexible alternative, Salesforce1 and then moving on to the more complex, but robust alternatives of going hybrid with the Android or iPhone mobile SDK’s, you will learn the pros and cons of each. Finally, you will learn how to build Hybrid apps, where you get some of the best of native, without all the complexity native brings.

And if you do not already have a Pluralsight subscription, now is the best time to get one (but make sure you hurry): Get up to a $30 Visa gift card when you sign up for Pluralsight by June 30!

Initial Impressions of SalesforceDX

Last year at Dreamforce, Salesforce’s Wade Wegner unveiled a new initiative called SalesforceDX, in which Salesforce promised to make the Version Control System the source of truth and NOT the Salesforce org, as it is now.

SalesforceDX represents a VERY different way of development.

As a former .NET developer, who has long considered the Salesforce tooling to be anything but robust and not in line with some of the more modern development tooling, I was VERY happy to see this new development. I waited anxiously to hear more, and early this year, Salesforce announced it was ready to go into the pilot phase. I immediately signed myself and my company, SynapticAP up and was graciously accepted.

This post represents a summary of some of my initial impressions while being part of the pilot:

The team has done a GREAT job of putting together a set of streamlined tools that I think were well thought out and elegantly designed.

I see this as something of great interest to ISV partners and large enterprises, but not sure how valuable it would be to small/medium sized orgs with low or simplistic code bases, especially since it will likely be an extra service they will have to pay for.

Even though the Force.com IDE uses the CLI, or Command Line Interface, it seems to me that the design team intended for you to use the CLI as your primary method of managing your scratch orgs. When SalesforceDX is released, I am sure other third-party IDE’s will jump on to supporting it, and perhaps the visual tooling will get better, but as it is, the Force.com IDE does not seem to do everything that the IDE does and I suspect it may always be that way.

SalesforceDX represents a VERY different way of development. To be quite frank, Salesforce has been doing things wrong for many years (in terms of modern development standards), but SalesforceDX represents an attempt to remedy that. If you are a developer that has only worked with Salesforce, or you started your career as an Admin and then transitioned to development, you may find SalesforceDX kind of strange at first. This does not mean it is bad, it just may take you longer to adjust to the way things are done with the version control being the source of truth and not the org itself. It represents a shift in thinking about your org, so don’t expect to make this transition overnight. Give yourself some time and eventually things will start to make sense.

I look forward to the eventual release of this product as I am sure it will really help to propel Salesforce development into the next whatever. If you have a chance to work with the pilot or the eventual beta release, feel free to share your thoughts here in the comments.

Hello Lightning Data Service

The Winter 17 Salesforce release introduced a lot of exciting new changes for Lightning Component Developers. One of the most significant, was the release of the Lightning Data Service (LDS).

The LDS is “kind of” like the standard Visualforce controller, but for Lightning components. Even after the Spring 17 release, it remains in developer preview. This means you cannot use it for Production apps and it will likely change names before it’s release. However, this represents the direction of where Lightning development is headed in terms of making it easier on the developer. Expect to see more things like this.

The LDS can be really cool if you are putting together a really simple component that will just access a single sObject and do some CRUD with it. The biggest benefit with using the LDS is that you do not need to use Apex code (think no unit tests). And most importantly, you do not have to include CRUD access checks in that code. You also get great performance benefits because components using the LDS all share a highly efficient local storage, so they should run faster.

Unfortunately, most of the Lightning component samples out there do not include Apex code to check for CRUD and FLS permissions and this is a big mistake because for Lightning components, this is not automatically enforced. CRUD and FLS security was automatically enforced in Visualforce pages, so most Salesforce developers will not even think about adding these checks. But in the world of Lightning, if you are using Apex code, you need to add access checks. Period!!!!

If you have no idea what I am even talking about, take a look at this sample Apex code, which includes the necessary access checks:

public with sharing class MyController {
  @AuraEnabled
  public static List getAccounts() {
    String [] accountAccessFields = new String [] {'Id',
      'Name',
      'AccountNumber',
      'AccountRevenue',
      'CreatedDate'
    };
    // Obtain the field name/token map for the Account object
    Map<String,Schema.SObjectField> m = Schema.SObjectType.Account.fields.getMap();

    for (String fieldToCheck : accountAccessFields) {

        // Check if the user has access to view field
        if (!m.get(fieldToCheck).getDescribe().isAccessible()) {

            // Pass error to client
            throw new System.NoAccessException()

            // Suppress editor logs
            return null;
         }
     }

     // Query the object safely. This is the only code you will see in most 
     // Lightning code samples that do not include the access checks
     return [SELECT Id, Name, AccountNumber, AccountRevenue, CreatedDate 
              FROM Account];
  }
}

By using the LDS, you avoid having to include ALL of this apex code and you still get a secure Lightning component. See now why using the LDS is so cool?

Now, I have to be honest and tell you that using LDS is not all unicorns and rainbows. It has some serious limitations (besides the fact that it is still in developer preview) such as:

Only works with a single record and does not support operations that need to go against multiple sObjects
Cannot be used to perform queries using anything other than the recordID.
Even after it is released, it will probably not work in Communities, Lightning Out or Lightning Components for Visualforce

Despite these limitations, I still think the LDS is cool and that it’s introduction indicates more good things to come. I hope you take the time to check it out.

Do this Salesforce Security Scan NOW!!!

Screen Shot 2016-08-20 at 11.39.10 AM Prior to about a week ago, if you went to this page and requested a Force.com Security Source Code Scan, you would have most likely gotten an error telling you that it could not be done and that you would need to submit a case.

Luckily, Salesforce has resolved this issue and you can now simply go to the link above, enter your credentials and you will be able to scan your org for security and quality rules. The scan will take a while to run (as in several hours or even days perhaps), but I promise it is worth the wait.

What you will get back is a very thorough report that scans your entire codebase for not only security issues (of which I am sure you will be amazed by how many critical violations it will find) but it will also evaluate whether you are utilizing best practices in your code to ensure good quality.

For example, it will scan your code to tell you where you have code that does the following:

Queries With No Where Or Limit Clause
Multiple Trigger On same sObject
Hardcoded Ids
DML Statements Inside Loops
SOSL SOQL Statements Inside Loops
Async Future Method Inside Loops
Test Methods With No Assert
Need to Bulkify Apex Methods Using Collections In Methods

I think everyone should take the time to have their orgs scanned and review the results. I suspect that even the most diligent of development shops will find some issue that needs to be addressed.

Happy Scanning.

Can’t Miss Salesforce Security Webinar Series

vulnerabilities_checklist I know security is probably not your favorite subject. But these days, it seems like everyday there is another major story coming out about how some big company has a major security breach. A lot of companies use Salesforce because it is secure and trust is so important. But as a developer, you have to realize that there are MANY ways you can bypass all the terrific security features Salesforce has put in place.

Developers have lots of flexibility that gives them power, but with power comes responsibility. It is so important you are aware of all the ways you may inadvertently make your app vulnerable to attack. Unfortunately, most of the documentation on this subject is loooooonnnnnggg and how shall I say this….BORING!

Well, for all you visual learners that really love practical examples, your help has arrived. The Salesforce security team has begun a series of Webinars designed to get developers up to speed with some practical, code-based demonstrations that show:

How we as developers can inadvertently bypass security
What you can do to correct the mistake and make your app secure again

So far there are only 2 webinars in the series, but just watching these two will probably teach you more than you get by trying to pour through and interpret all that other boring documentation.

Hope you find these as helpful and enlightening as I did. And thanks to the Security team for taking the time to put the sample app together along with these webinars.