Every Salesforce professional runs into situations from time to time where we really need a professional opinion. As a team of SaaS growth experts, OpFocus wants to lend our expertise whenever possible. We recently held an “Ask Me Anything” session, this one focusing on Development and Integrations.

During the session, two of our in-house experts, Senior Vice President of Technology, MJ Kahn, and Director of Salesforce Development, Jason Curry, led the discussion and provided their professional opinion on all things Salesforce automation and development. This article covers some of questions and answers that took place during this session. Whether you’re in the middle of a project or just getting started, we hope this will answer your development questions!

What are some use cases for using custom development? 

 

One of the most common questions we received revolved around what can be done with custom development. As MJ describes, you are really only limited to your imagination.

A common request is if something happens in the database, we would like something else to happen automatically, this is usually done with triggers. A few examples that MJ lists include the automatic creation of renewal opportunities, which can be done with CPQ or custom development; automatic lead conversion if the lead matches with an existing contact or account; and automatic persona alignment based on specific criteria or actions.

Other use cases she mentions include calculating things such as ARR, using “as time marches on” automation that sends an email after a certain amount of time, Batch Apex which can process large quantities of data, and building custom user interfaces. Integrations with other systems to send or receive specific data is another big use case that MJ mentions.

With this being said, it’s clear that custom development offers a wide range of possibilities. There is very little you can’t do with a little imagination and a lot of knowledge!

What is the recommended process for determining if we should build or buy a solution?

 

As consultants, we will always say, “It depends.” The first question is whether there is an app out there that can do what you have in mind. If there is not, “buy” is not even an option. The next question is whether the apps available are close enough to what you would like to do. If so, the next question is how much you would pay for that solution. Some solutions are free and others have different types of costs associated with it. If it is a paid solution, you will want to look at how much it will cost, which may depend on the number of users who will be using the solution.

Once you have this cost, you need to estimate how much it would cost to build the program you want on your own. What would it cost to build everything you want? What would it cost to create a minimally viable product? How does that cost compare to the cost of license fees for a “buy” solution?

The last thing to consider is that, as your needs change, the “buy” option may not be able to change with them. If you build with custom code, you should build it to be as configurable as possible. This may increase the “build” cost somewhat but may allow the solution to change more easily without incurring additional development cost.

What is the right tool for me to use – Workflow, Process Builder, Flow, or Triggers?

 

Again, the answer to this question is, it depends. The chart below outlines the use cases for each tool and an example of when you may want to consider this. Workflow is very useful for a limited amount of things. This list includes updating a field, sending an email, make an outbound call, and create a task.

Process Builder is more visual UI and fires when records are created, updated, or when an event specifically launches the Process Builder. It can do everything Workflow can do in addition to launching Quick Actions and Flows, and submit for an Approval Process.

Flow can be launched when an event causes it to as well as before a save. Actions include everything Process Builder can do as well as more complex processes. The final option is Triggers written in Apex. They can fire before and after records are created, updated, deleted, and undeleted. Triggers can do just about anything you can think of.

If you want to update the same record that caused the automation to fire, then we recommend using a Before Trigger or a Before Save Flow. That’s because both Workflow and Process Builder cause extra updates to the database, which causes performance to suffer. If you want to create or update other records, you can do that with a Trigger, Workflow, or Flow: performance, in this case, is roughly equal for each of those automation tools. So again, the correct answer to this question is that it depends on the situation and what you are hoping to accomplish.

How can I create a stopwatch functionality that pauses the time a deal takes to be completed when delayed by the customer?

 

A more general way of asking this question is, “How can I keep track of how long an Opportunity, Case, or Lead spends in different Stages or Statuses?” OpFocus has a blog article that covers a very similar use case. It covers different approaches for how you can more accurately track stage changes that a deal goes through in order to reach the correct stage you would like. This blog outlines the type of code needed to make this change and how your team should go about implementing it.

Queueable vs Batch, when should I use each?

 

Batch is record driven which is good for doing updates across your data for a single update. Queueable does not require a record to start and can be scheduled or launched from a batch. This approach often has higher governor limits in many cases allowing you to process larger files. Some differences include the chains that can be associated with the action. Queueable can have up to 5 consecutive chains set up at the same time as to where Batch frowns upon this process. Batch can only have 100 scheduled Apex jobs as where Queueable only allows for 2-5. It is best to think of Queueable as a generic function with higher limits. 

Can you share the most fun and/or challenging Dev Project you have done?

 

For MJ, the type of project that jumps out to her is implementations of the Demand Unit Waterfall. This strategy involves targeting a group of individuals at an organization rather than a single Lead to then pass over to the sales team. She enjoys this type of project because it works closely with the business decisions of an organization and often makes a meaningful impact in the organization.

Jason’s favorite project involved developing a custom branded community that helped the customer track the progress and changes in their projects. This project affected the displays used in times square. Another project he really enjoyed revolved around the Dreamforce website. 

How can I get started with Apex? 

 

It is helpful, but not absolutely necessary, to have some prior programming experience, especially with Java. Apex is different from most other languages, though, in that it runs in a multi-tenant environment that limits the amount of work you can do in a single transaction. For example, you can’t write a simple Apex trigger that creates a million records. The official list of governor limits lets you know how much Apex is able to do at once.

Learning SOQL, the Salesforce Object Query Language, will also come in handy as you work to become more familiar with Apex. Trailhead is a great resource to use when learning. The Apex Developer Guide is yet another great resource to help become acquainted. There are a number of articles and blogs available to help you get started.

The best way to learn is to do. MJ recommends learning in a free Developer Edition org rather than a sandbox. She also says it is best to start small and start early. Start with small projects and as you become comfortable, you can take on more and more complex projects. Finding a buddy to review your code and whose code you can review is another great way to learn. A final piece of advice is to never deploy to Production without unit testing. This is something that you should keep in mind no matter how experienced you become.

How can I get started with Visualforce and creating custom user interfaces?

 

Visualforce is Salesforce’s oldest custom user interface technology. Writing Visualforce is similar to writing HTML in that it allows you to specify the layout and content on a page. You also typically use an Apex controller that sits in between the Visualforce and the database to control the flow of data. If your Visualforce page uses an Apex controller, you also have to write unit tests. One issue with Visualforce is that there can be a lot of transfers between the browser and the Salesforce server, which can slow the performance of your UI. Visualforce is still useful for email templates and generating PDF’s. 

Aura Components, a more recent technology built on the Aura framework, are now available. They usually require fewer transfers of data between the browser and the server than Visualforce, and as a result, usually perform better. They also allow you to divide a complex user interface page into logical pieces (components) that can be implemented separately. Aura Components tend to look more like Lightning than Visualforce pages might.

Lightning Web Components (LWC) are the next generation after Aura. Like Aura Components, Lighting Components allow you to create separate components that interact with one another rather than building a monolithic page. The framework is lighter-weight than that of Aura, which makes it faster and far easier to build. 

When starting to learn the building of custom UIs in Salesforce you will decide which to use. MJ recommends learning with Lightning Web Components as they are the future that Salesforce will build on going forward. Trailhead is a great place to start learning and developing your skills.

What are some considerations for building automation in Salesforce?

 

 

There are several factors to consider when deciding how to automate a process in Salesforce.

One of the most common issues is when a team builds directly in Production. Working in a sandbox and then deploying to Production is key. It not only gives you a non-mission-critical environment for testing, but also ensures that the sandbox is an accurate reflection of Production.

With the exception of Apex Triggers, other automation techniques don’t provide mechanisms for documenting details around what the process does. If the details aren’t documented, it can be difficult for someone to make changes to the process later on. Detailed documentation can be crucial to the long-term maintainability of a process.

When there are multiple types of automation for a single object, it is difficult to determine how they operate. For example, imagine an Account object that has 15 workflow rules, 5 Process Builders, 3 Flows, and 3 Apex triggers. As an Administrator, determining exactly what happens when an Account record is saved is nearly impossible. In addition, if multiple Triggers are defined for the same object, the order in which they fire is unpredictable. The same is true for Process Builders and Flows. Creating multiple types of automation tools, or even multiple instances of the same automation tool, for the same object can make it difficult to determine what the system is doing and therefore to enhance the system or to correct issues.

These are just some of the factors that we recommend keeping in mind when testing and writing Salesforce automation.

Final Thoughts

Throughout the session, we heard from a number of professionals and provided guidance around their ongoing projects. We’ll be holding sessions similar to this in that future that we invite you to take part in. If your team is considering a custom development project and is unsure where to start, reach out to our team and we’d be happy to discuss it in more detail!