Decoding Triggers for Admins: Webinar Recap

Our latest webinar, Decoding Triggers for Admins, is based on Kieren Jameson’s extremely popular Dreamforce ’18 breakout session and covers how #AwesomeAdmins can decode the basic structure of a trigger, learn how to get started with triggers, and understand the role they play in your org.

Take a look at the recording:

Webinar summary:

Trigger overview and best practices
So why should Admins care about triggers? Kieren says, “There’s nothing more frustrating than not knowing what some piece of my org is doing and how it fits together. If you’re using triggers you need to know what they do and how to fix them if something goes wrong.” She adds that if you’re working with developers, being able to speak the same language they do is important. Additionally, it’s important that you can work with developers to ensure your builds & code are following Salesforce best practices.

So what are Apex triggers? Well, they are a type of file that contains code. This code fires off other processes when data is changed in the org. The whole purpose is for the trigger to wait around and listen for things to happen in your org that the code is written to update- like a record- and then run that code on all the records it pertains to.

Why and when do you use triggers?
You can use them to compare data in a record before and after a change is made. You can also use them to create new or update existing records. You can create, or clean up data. You could also interact with external databases and web services like syncing data between Salesforce and an outside system.

How triggers work
Kieren explains that triggers can fire either before the data is saved, or after. Having the trigger fire before is great for changing data programmatically before you save the record. You can use this “before” trigger to ensure that the data you’re about to enter isn’t going to mess up something in your org. Essentially, you’re validating it, without running into the limitations that validation rules present. Now for the “after” triggers. “After” triggers are great for doing something related to the record you just inserted or updated in your org. For example, if you’re trying to create a series of related records, you can easily accomplish this with a trigger!

Now let’s look at an example to start laying out just how triggers work in an org. Kieren explains,
“a trigger is always tied to a single object so if, for example, you clicked the new contact record and there is a trigger associated with that object, then the trigger will fire.”

You’ll likely have a few sections that relate to what you’re going to do before and after the trigger is saved (and it is always best practice to have one trigger per object). First, before trigger actions will fire, and when they run code those pieces will save in a class file. The trigger calls to the class, and tells it what it wants it to do. And then, the data is saved! Next, the after trigger actions call out to more classes which can do all sorts of things that are based on the records you just saved. Then, the trigger waits for the command it needs to fire again.

A look at trigger structure
Kieren explains that first, you’ll define the type of file. Then, you name the file. Next, define the object the trigger should listen to, then define when you want the part of the trigger to run. She says this becomes your “table of contents” so to speak. For the full visual example, just click play!

So, where does all the code go?
The best practice is in the example above. However, you’ll likely see a not-so-good, but very common practice in your org. This looks like a trigger containing all the code that does the actions you want to be performed, rather than calling out to one or more classes which each contain the code that does the actions you want performed. Kieren explains that you won’t necessarily want to do this because you won’t be able to reuse or update the code without duplicating it in all the places where you want to use the business logic. With one trigger per object, it is easier to control the order that each piece of code will run in. Bonus, it is easier to read code when it is stored in smaller chunks and it’s also easier to run distinct unit tests with smaller portions of code!

So, now that we have a basic understanding of what we’re looking at and best practices to set us up for success, we can jump into her demo: Cooking with Code.

Cooking with Code is a custom app that stores recipes and their reviews. Each recipe can have more than one review and each review can have a single reviewer which is being pulled from the user object. So what do we want the trigger to do? Whenever a recipe record is inserted or updated in the org, we want the trigger to check for reviews and if there are none, then create one. To see how this trigger scenario plays out, take a look at the demo below:

Wow! That was a ton of awesome information. Your mind is probably turning, and hungry for more (and maybe some dessert). So, where do you go from here? Check out these resources:

Womencodeheroes.com
sfdc99.com
RADWomen.org

Trailhead trails:
Build a conference management app
Quickstart apex coding for admins
Apex triggers
Apex basics & database