Apex Triggers

I worked on the Apex Triggers module on trailhead. Apex triggers are very similar to database triggers (remember those?). I remember in my first job, which was an enterprise healthcare company, our DB was littered with hundreds of triggers that did various actions whenever records were inserted, updated, or removed.

Triggers are a powerful concept, but tend to be very difficult to maintain at a large scale. Especially when you have a large team. I think they are an artifact of the legacy development methodologies. These days most of the actions that triggers used to be responsible for are managed as either a part of the model, or as separate background tasks.

Despite this being true in most modern software development, Salesforce allows you to write triggers in a first class way that do things when records change. I think this is a case where they are still “ok” to use because they remove a lot of the overhead with having to figure out how to keep track of the state of all of your various records.

The best part about Apex triggers is that unlike DB triggers which require you to write your code in an enhanced variant of SQL, Apex triggers allow you to write the code in Apex. This means that you can take full advantage of all of the built in salesforce libraries, as well as making HTTP callouts (the most powerful part of all of this) in a really simple way.

One thing to note is that if you do make HTTP callouts with Apex, you must do so asynchronously.

Apex triggers have a handy access to the context that fired the trigger, including both the old and new state of the affected object.

One great hint that the module gives us is to write our code to support both single and bulk operations. While most triggers that I have written operate on only a single object at a time; there may come a day when I may want to do work on multiple objects at a time. For example, if I was using the bulk API. By writing the code in a way that supports bulk operations (essentially using a for loop) you can reuse the same code in the future rather than having to handle both cases separately.


Salesforce DX External Sharing Model

I was working through the Getting Started with Salesforce DX module on trailhead and when it came time to push the Dreamhouse app up to my scratch org I got a dozen or so error messages complaining about all sorts of things.

PROJECT PATH                                                                                    ERROR
──────────────────────────────────────────────────────────────────────────────────────────────  ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
force-app/main/default/objects/Property__c/Property__c.object-meta.xml                          Can't specify an external sharing model for Property__c
force-app/main/default/objects/Favorite__c/fields/Property__c.field-meta.xml                    referenceTo value of 'Property__c' does not resolve to a valid sObject type (65:13)
force-app/main/default/objects/Favorite__c/listViews/All.listView-meta.xml                      In field: columns - no CustomField named Favorite__c.Property__c found (88:16)
force-app/main/default/layouts/Broker__c-Broker Layout.layout-meta.xml                          In field: relatedList - no CustomField named Property__c.Broker__c found (81:19)
force-app/main/default/layouts/Favorite__c-Favorite Layout.layout-meta.xml                      In field: field - no CustomField named Favorite__c.Property__c found (13:26)

Luckily the error messages are pretty useful. In this case it looks like the “External Sharing Model” was not turned on in my scratch org. This appears to be turned off by default.

In order to get this step to work:

    1. Log into your scratch org sfdx force:org:open
    2. Go to Setup
    3. In the Quick Search box look for Sharing Settings
    4. Click on Enable External Sharing Model 

Sharing_Settings___SalesforceNow you can run the push command and deploy the Dreamhouse app without any issues.

Keep on trailbalazing!