VSCode for Salesforce Admins: A Deeper Dive

Share this article...

Point and click isn’t always the quickest way to perform some Salesforce Admin tasks, especially when you need to do something quickly, repeatedly, and at scale. Which is why we need to borrow some Developer tools to be an awesome Admin, such as SFDX (a set of power tools) and VSCode (Visual Studio Code).

This Admin’s guide to SFDX and VSCode comes in two parts. In the first part, Introduction to SFDX and VSCode for Admins, I worked through an example that may have sounded like a headache initially, but was very easy by the end of the tutorial! The first post went through a number of reviews to ensure that the steps were easy to follow and understand. It made me wonder why is VSCode a bit clunky?

“Validity”

Learning VSCode – My Thoughts

Here are my thoughts: I now regard VSCode as the equivalent of Lightning in its early days. Anyone who remembers Lightning when it first came out will remember that it was slow and missing vital features. Salesforce knew this, but equally realised it was a pain-point they had to work through, because the end result would be worth it. 5(!) years on, I have to report they were right. Lightning is more modern, and Salesforce reports that the time to develop and deploy new features has dramatically improved, as well as the new experience provides a lot more flexibility than the old one.

VSCode or, more accurately – VSCode using Salesforce’s SFDX and other plugins – is good but it’s not entirely smooth yet. Some features you would expect are missing and the documentation needs a bit of a polish to make it more user friendly. These will come with time* but if you want to tap into what’s on offer now, and take advantage of it, take a breath, grab a cuppa (tea/coffee, you decide!), remember it’s not just you if it does take a couple of attempts to do things, and enjoy the ride of exploring and discovering new ways to do things.

This is the price we pay for innovation, for having a product that is being actively developed in response to identified needs and customer feedback. Speaking of Salesforce identifying needs, an example of this can be seen in one of TrailheaDX’s “wow” moments, that VSCode is coming natively to Salesforce as CodeBuilder, simplifying development as well as a host of other benefits.

Next Challenge: Email Templates & Playing Around with more Metadata

What happens if you want to find out where an email template is referenced in Salesforce? This isn’t possible from the standard point and click interface (though products such as Elements.Cloud can do it). If you look in “Email Alerts” you can see which Workflow Rules and Approval Processes use your email template but that doesn’t tell you which Apex Classes, Flows and Process Builder processes are using it.

How can you find and quickly update fields in Salesforce reports? You can find reports with certain fields in Salesforce easily, but updating them is a slow and laborious process.

With VSCode, and this guide, help is on hand!

Tip: This guide doesn’t necessarily cover managed packages, depending on how they are implemented.

Instructions

To keep the instructions short and simple, we’re going to presume you’ve run through the main example given last time, that you have connected and authorised your Salesforce environment (steps 1-17; everything in “Preparing the Ground”).

Step 1: For the purposes of this demo, ensure you have an Email Template in your Salesforce Org, and it contains at least one field. We’ll search for this field later on.

Step 2: Launch VSCode.

Step 3: Install Salesforce Package.xml Generator Extension for VS Code by Vignaesh Ram Amaranth. Just click the “Install” button.

Step 4: VSCode will then pop up on screen, displaying the package. Simply click “Install” (again, albeit on a different page).

Tip: you will know that the package has completed installing when it says “Uninstall” on the screen as the available option (see screenshot below).

Step 5: Go to “File”, then “Open Recent” and choose your previous project (or repeat steps Steps 6 to 17 from the last week’s blog).

Step 6: CTRL SHIFT P and then type:

SFDX Package.xml Generator: Choose Metadata Components

(or CTRL SHIFT P and then Metadata as you’ll then be displayed a list of matching options).

Step 7: Click “Select All” and then the metadata will immediately begin to download; you will then see a “Processing Metadata” box in the bottom right hand corner of VSCode. For smaller orgs this can take around 10 minutes – eventually the box appears and a new one appears saying “All metadata selected except [various names]”.

Tip: If you add new metadata (e.g. create new fields, email templates, etc), you will have to rerun the process from this step (Step 7) onwards, to ensure that your new metadata is included.

Step 8: Individually select Dashboards, Documents, Email Templates and Reports just by ticking their individual boxes. You can use the in-plugin search box to quickly jump to the appropriate item (see white highlighted areas in screenshot below).

Tip: When you do “Select All” the package doesn’t select any metadata that is saved in folders (this means Dashboards, Documents, Email Templates and Reports). Also it will appear not to select certain “child objects” such as Workflow Alerts, however it collects all dependencies when collecting main objects such as Workflow Rules.

Step 9: Click “Update Package.xml” (highlighted in pink in the screenshot below).

This then takes you to the package.html screen; it simply lists the elements of the metadata, but it hasn’t downloaded them (yet).

Step 10: Because of a known Salesforce issue, scroll to the end and change:

<version>48.0</version>
to
<version>46.0</version>

Step 11: Then go to File (in the top left corner) and press Save.

Step 12: To download the metadata right mouse click anywhere in the package.html panel on the right hand side of the screen and select “SFDX: Retrieve Source in Manifest from Org”.

Tip: When I ran the above step I got the following error. It’s not as scary as it looks. I simply went back to Step 9, used CTRL F to search for ManagedContentType, deleted the reference (see screenshot below) and then went on to Step 10 again.

Step 13: When successful you will see “SFDX: Retrieve Source from Org successfully ran” in the bottom right hand corner of your screen (see screenshot below).

Step 14: Now you can use CTRL SHIFT F to search all the metadata (including email templates) for your field, whether that be SalesforceBen_Offer__c or anything else.

Step 15: If you’re wanting to update reports, you can now use the principles discussed in the my first article (Step 20 onwards), to find and replace/update the original data.

Exciting Part: Navigation

Want more? Click on the File icon in the top left hand corner (see screenshot below) and have a poke around. This will show you what metadata is out there to be played with investigated. A new world awaits!

Last Word

In this example we’ve used Vignaesh Ram Amaranth’s free plugin. This – to me – is what makes VSCode so exciting. Salesforce doesn’t currently provide the en masse metadata downloading tool. Vignaesh saw this and created his plugin because he realised that there was a gap in the market and he had the skills to fill that gap. That’s a good chunk of what makes Salesforce such an awesome product to use day-in, day-out: the #SalesforceOhana “Trailblazer” community spirit (as well as Salesforce having the foresight to support and encourage this).

There are other plugins that help extend VSCode – much like Salesforce has its AppExchange – no security or quality control checks, apart from those you run yourself however.

Further Resources (reprise!)

Thanks

Huge thanks go once again to Christian “Szandor” Knapp MVP and, this time around, to Vignaesh Ram Amaranth for taking the time to talk me through his plugin (as well as creating it in the first place!). And thanks to Ankit Taneja, Christine Marshall and Rob Cowell for reviewing the text.

4 thoughts on “VSCode for Salesforce Admins: A Deeper Dive

  1. Avatar

    Started learning SFDX in December and now have our org built using it. We have 6 packages developed and working across 4 team members using VS and GIT. I am Administrator of the Org and do virtually everything.

    Something I would like to discuss with peeps is how best to admin against an Installed Managed Package? From this I mean we have Financial Force installed. We need to add fields to page layouts for Financial Force work. Are people combining SFDX with Standard Change Sets?

    1. Avatar

      Best practice is NOT to modify page layouts that are contained in a managed package. Create a new page layout and update page layout assignments.

Leave a Reply