How to get everything to work (eventually)

Posted byjohanngilibconsulting

Authors: Tanja Janjić & Johann Furmann

Summary

Often, we can’t quite figure out why some piece of (low) code doesn’t work. We are 100% sure it’s supposed to work, but for some reason, it doesn’t. Maybe it already works in a Sandbox but not in Production, maybe it worked in the past but suddenly stopped working or we never got it to work in the first place. You can spend hours trying to get it to work or just follow a simple but effective process. The process gets everything that can work to work (eventually).

Table of Contents

Example

I brought an example from last week’s work.

Requirement: Every time a “Payment Record” is created for Students with a Revenue of more than 10.000 the Sales Agent needs to be informed.

The idea is to have a Process Builder which should create a Task every time your custom object “Payment__c” with “Status__c = ‘New’, RecordType.Name = ‘Student’ and Revenue__c > 10.000 is created or updated.

The field Status__c is set to default to ‘New’ for the RecordType ‘Student’. The other fields are set on Record creation by the user.

At the end of the blog, you find example documentation.

One Step at a time

I know it sounds obvious, but I learned from a friend to systematically build one step after another. That way is the opposite of frantically trying to build as quickly as possible. The process might be boring  but works every time.  The process can be applied to building something new, extending existing solutions, or debugging an issue. I always follow the same 9 steps.

1) Create a detailed plan

It’s tempting to start without a plan, especially if you’ve done something similar before. My favorite excuse to myself is, I don’t have time to write a plan, I need to get this done now! After all these years I still create a detailed plan for everything I do. The plan can’t be detailed enough! For the example with the Process Builder I wrote out in a ticket: Create Process Builder, all criteria’s, all planed value for all Task fields. The details can be found at the end of the post.

Not having a plan makes getting lost almost every time. Don’t skip creating a plan, especially if you are sure you don’t need a plan.

2) Research & Prototyping or does this work in general?

If it is something I have never done before or am not sure about, I research the topic and build a prototype to make sure, it’s doable. My plan has usually a section “to be verified”. I only start with the real implementation once I’m sure everything works as I plan to.  First, I do the Trail (if available), read the documentation (thoroughly) and follow up with available exercise and community content.  Once the research phase is finished, I prototype each element of the solution individually. Getting a prototype to work proves I don’t waste any time trying to build something complex which couldn’t work in the first place.

An example “To be verified” list:

  • Can Tasks be created on ‘Payment__c’
  • Can Process Builder create Tasks

First, I create manually a Task on Payment__c to make sure that works. Then I finish the Trails and Project to Process Builder. Only if I verified everything is working as planned, I start implementing the solution.

3) Build according to plan, one step after another

After you have a plan and you verified everything can be done, the (boring) building starts. Make sure you follow the plan and build one piece after another. After I finish one element, I immediately test. Only after I positive test, I continue building. I try not to skip steps, I treat it like a recipe.

If everything works now, congratulations! Unfortunately, often something doesn’t work as planned and you just can’t figure out why. That’s where the remaining six steps come into play.

4) Is everything deployed and activated

You wouldn’t know how often I forgot to activate the latest version of the Process Builder or deploy my code. Yes, check one more time, even if you are 100% sure the last version of the Process or Flow is activated. Oh, and yes, check if you are logged in to the correct org. Happened to me way more often than I’m comfortable to admit.

5) Is everything done correctly?

This is the most annoying one, but small (spelling) mistakes happen all the time. Check one more time, if everything is written correctly, especially the API values match. Check every comma is set correctly in the very formula you wrote. Check everything thoroughly, mistakes happen! I usually use the “Copy + Search” method. That means I copy the value from the Process Builder, go to the record and use the browser search “Ctrl + F” to make sure they match. I do the same in Setup and make sure the API values match. In our case, I’d open the Process Builder, look at the criteria and compare every line with a Payment__c record I just created. I often use “Salesforce Inspector” to record values more quickly.

6) Clean up

Stop fixing, clean up first.  Especially for more complex implementations, it often becomes a mess. Sometimes the error is hidden in unstructured formulas, leftover code, or similar. Cleaning and structuring nicely often enough fix the issues.

In our example there’s likely some left-over stuff from the prototyping phase, clean that up. Furthermore, format any formulas you built nicely. Maybe that already fixes your issues. Bonus, your org is clean as well.

7) Rubber-duck to the rescue

Explaining your solution to someone is a great way to spot mistakes. You take your implementation and explain it step by step to somebody who doesn’t know the solution. Often, I spot the mistake while I explain the solution to someone. It’s also called rubber-duck debugging because the person doesn’t have to be listening to you. The part of explaining is what leads you to the solution.

8) Stop, do the dishes, finish later

Sometimes I’m stuck, nothing seems to work. If I’m in that situation and try to get something to work for more than 30 minutes without success, I stop. I leave my desk and start doing something else. I can always do the dishes, laundry, or start cooking dinner. From my experience, the solution often comes as soon as I put some distance between the problem and me. Bonus, dishes are done and dinner is ready.

9) Reverse Prototyping or Divide & Conquer

This is the last step, the most desperate one. If I already ruled out all the other issues and dinner is ready, I start to “Divide & Conquer” the implementation. It’s like prototyping but in reverse.
I take my automation and remove one element after another. After each removal, I test and see if it works. As soon as it starts to work, I know the last removed element causes the issue. For our example, with the Process Builder, I would start by removing the last criteria, activate the Process Builder, and test. If the Process still doesn’t work after all criteria are removed, I even remove the Task creation itself and just create a Chatter post. If that still doesn’t work, I would deactivate all other automation on the Payment__c and the Task Object. At some point, it must start to work. If you still can’t get it to work, you likely skipped the prototype phase.

Always, follow the process

The process explained up there is long and tedious but every single time I try shortcuts by skipping a step it hurts me later. There are smart people out there who can get by with a shorter process, but I know myself. I need to follow all the steps to get something to work.

Therefore, this process is the backbone of everything I do, no matter how complex or simple the task ahead is. Following the process might be slow sometimes but I guarantee it pays out in the long-run.

Template:

Requirement

Every time a “Payment Record” is created for Students with a Revenue of more than 10.000 the Sales Agent needs to be informed.

Implementation Plan:

Process Builder creates a record on “Payment__c” on record create.

Process Builder Criteria:

AND(     isNew()
RecordType.Name = ‘Student’
Status__c = ‘’New’,
Revenue__c > 10.000)

Task Details:

                Subject = ‘Check Payment’

                Due Date = TODAY() + 7

                WhatId = Payment Record

                Status = ‘Open’

To be verified

  • Can Tasks be created on ‘Payment__c’ -> Verified
  • Can Process Builder create Tasks -> Verified

Components to be deployed

  • Process Builder ‘Payment_automation’