Five things that rocked my world learning Apex

Ok maybe not rocked my world but when I started developing on the Salesforce platform I was very much figuring it out as I went along (If only trailhead existed then!). Unfortunately, there were some things that I wished I had known before I had started. In some cases meant I had to do rework or in worse cases didn’t even know I’d made a fundamental error. So here are the top things that “rocked my world” when developing Apex for the first time.

Triggers don’t fire all the time

When I was first introduced to triggers, I was told they were very much like database triggers. Every time a record was inserted, updated, deleted or undeleted the trigger would fire. I expected that after I had written my update & delete triggers on say the contact object, the trigger would always fire in the same way a database stored procedure trigger would fire. But this is not the case. There are a couple of scenarios where triggers are not fired. A full list is here but here are the ones I know caught me out:

1. Cascading delete operations; If you have records in a master-detail relationship and someone deletes the parent record, the children will cascade delete. The kicker? Only the parent records delete trigger is fired, not the children. To protect yourself from this happening you can put logic in the parents delete trigger.
2. Cascading update operations as a result of a merge operation; If you merge two records together the “winning” record is kept, and the losing record is deleted. Any child records of the losing record are then “re-parented” with the winning record, but the update triggers on the child records are not fired. For example if you had two account records that you were merging, and both had opportunities on them, the Account field on the losing account’s opportunities will be updated with the new/winning account (the “re-parenting”), but the update triggers won’t fire on those opportunity records.

 

Users can Undelete records!

No, I don’t think you’re understanding me, “Users can undelete records!” 🙂 When I do org reviews, one of the things I hunt out is delete trigger code, and if needed, if there is any corresponding undelete trigger code. It’s amazing how often I don’t find anything. Which in some circumstances can be dangerous and it gives an extra dimension when architecting a Salesforce solution.

One scenario I found was with an opportunity product line trigger that calculated an opportunity total price field on the parent opportunity. The insert, update & delete triggers were there, but no undelete. After looking at the data, it looked like one enterprising sales rep had figured out how he could reduce the price of the opportunity by deleting, then undeleting the opportunity product lines. Essentially making the product come back with zero value giving his client a better deal. The delete trigger was reducing the amount but when the record was undeleted it wasn’t recalculating the total.

There are inconsistencies between standard and custom objects

Now I have to say that Salesforce has been working hard over the years to make things consistent but there are a few inconsistencies that have caught me out over the years. One I do remember was that you couldn’t have triggers on opportunity lines (now thankfully possible).

There are still inconsistencies out there. It usually comes down to two things. Salesforce has bolted on an acquisition application that doesn’t fully support the standard platform. Or is old Salesforce code (E.g. activities) or “Parkers code” as it’s affectionately called 🙂

1. You can’t have triggers on case milestones; It’s an object, why not 🙂
2. Salesforce Knowledge: Workflow rules only exist on the article, no triggers. Approval processes only work on the article and not the article translations. Not being able to query articles as you would expect,  data categories… Well… I think I will leave it there, but you get the point.
3. Workflow rules: Not all fields can be used in workflows, you can’t create email workflows for activities.

Some limits can be increased

Some core governor limits can’t be extended, for example, CPU limit, the number of DML calls per transaction but others can. Most of governor increases are declarative limits. Essentally Salesforce doesn’t want you to run riot by consuming all resources, but if you have a good business case for increasing one they will. Some requests to increase limits do have side effects and there is usually an upper limit.

One classic limit I increase is the number rollup summary fields but has a “hard limit” of a maximum of 25 per object. But as of the Winter ’16 Salesforce has relaxed this limit and now everyone can enjoy 25 rollup summary fields per object.

If you do get stuck on a limit, do a google or reach out to Support as you maybe surprised what they say 🙂

Workflows bulkify record updating (most of the time)

Time-dependent actions aren’t executed independently. They’re grouped into a single batch that starts executing within one hour after the first action enters the batch. UNLESS Its a Case workflow and in that case they start executing within a minute if the time. Therefore, any Apex triggers that fire as a result of those grouped actions are also executed in a single batch. This behavior can cause you to exceed your Apex governor limits if you design your time-based workflow in conjunction with Apex triggers.

Bonus Sixth: I can do a Salesforce deployment while going 125mph on a train

Deploying code on #Salesforce while on a train going at 125mph, its a beautiful thing 🙂

— Francis Pindar (@radnip) January 19, 2013

Yes totally amazing 🙂