I really like working with Salesforce DX and scratch orgs. However, in larger projects it can be time consuming to create a scratch org, install dependencies, push code, assign permission sets and setup test data. After doing this manually for a while I created a PowerShell script to automate the process. In a large project the script can still take some time to run but at least I can let it run while I do something else.

I can’t believe it’s been almost six months since my last post. What a weird year 2020 has been. Early this year I decided to create a Udemy course for beginning Apex developers. My goal was to create a course that would teach programming fundamentals and the Apex langauge at the same time. I wanted it to be approachable by students who are new to Apex, new to Salesforce or new to both.

Last week I passed the Platform App Builder exam, my second Salesforce certification. My primary area of focus is coding but in my current role I’m also doing a lot of declarative development. So, I thought this would be a good time to prep for the App Builder certification. I used the Focus on Force practice exams again and they were very helpful again. They do a good job of shining a light on the areas where I need to study more.

The DateTime object in Apex includes rich support for formatting dates using Java’s SimpleDateFormat. To format a DateTime, call the format() method and pass it a format string. The following table includes the most common elements you can include in the format string. All examples are using the date and time when I’m writing this — March 8, 2020 at 3:45pm. Letter Component Example y Year 2020 M Month in year 3 w Week in year 11 W Week in month 2 D Day in year 68 d Day in month 8 E Day name Sunday u Day of week (1 = Monday, 7 =Sunday) 7 a AM/PM PM H Hour (0 – 23) 15 K Hour (0 – 11) 3 m Minute 45 s Second 12 S Millisecond 71 z Time Zone PDT Repeat Letters to Modify the Presentation Many of the letters can be repeated to modify the presentation of the component they represent.

NOTE: The project discussed in this post is on GitHub. I recently needed to display a message to users in response to a server side event. Sometimes the message would only need to be displayed for the user who generated the event. For example, a user saves a record and something happens in a trigger they need to be notified of. We also had a use case where we want to notify every user who is currently using a particular application.

When to code in Salesforce is a topic that comes up a lot. It’s a common interview question for Salesforce developers and Pluralsight even has an entire course on the subject. I have heard many times that we should use declarative whenever possible and code as a last resort. Some teams even quantify it with goals like 90% declarative and 10% code. Why do so many Salesforce developers have a bias against code?

Over the summer I worked on a real estate project. Some of the Salesforce data is used to generate documents and some of those documents need to have numbers spelled out. For example, 1,535,000 would be spelled out as one million five hundred thirty-five thousand. I didn’t like the solutions I found online so I spent a little time coding my own. It’s not a common use case but I wanted to post my solution in case others find it useful.

Postman is my favorite tool for testing REST APIs. Workbench is great for ad-hoc testing but I like Postman better because I can create a suite of repeatable, scriptable tests. You can download and install Postman from getpostman.com. When you run it you should see the main screen. Postman main screen Prerequisites In this post we will test the REST API we created in the last few posts. To follow along with this post you can clone the GitHub repo and push the code to a scratch org or start at the beginning of the series if you would like to follow along with building the API.

This post is a continuation of the previous two posts where we created a Salesforce DX REST API project and then coded HTTP methods to perform CRUD operations. The full project is on GitHub. In this post we will cover some general unit testing concepts and specifically how to unit test HTTP methods in Apex. Arrange, Act, Assert There is a common pattern in unit tests called Arrange, Act, Assert. It states that each unit test does these three things.

In part 1 we setup our scratch org and created our custom object. In this post we will build out the API. First, create a new class in Visual Studio Code called HouseService. From the command palette in VS Code select SFDX: Create Apex Class and enter the name of the class. A few things to note about the class definition: @RestResource identifies our class as a REST endpoint.