8

What are your thoughts on using a combination of workflow + trigger versus running all logic through a trigger. The reason I bring it up is I'm undertaking a massive trigger cleanup in a new org I took over, and am running into a few "workflows causing triggers to run twice" issues.

Am I best off implementing the public static Boolean isFirstRun method, or simply putting all logic into a trigger?

I'm wondering on two levels:

  1. Simplicity (it's obviously more difficult to write/test/push triggers than it is to write a simple workflow rule, but it's also simpler to do everything in one giant beforeUpdate trigger where you can control order of execution, etc with more granularity)
  2. Time (is it fast to have one single all-encompassing trigger as opposed to forcing salesforce to work "trigger, then workflows, then re-trigger"?)

Thoughts on best practice?

I know salesforce states that the more "point-and-click" you can make your app, the better (and I can do some of that via Custom Labels and Custom Settings read via the trigger), but I'm no stranger to triggers, so it doesn't scare me to be fully reliant on them...

  • 1
    I was asking myself the same question 2 days ago, exactly for the same reason... I ended up with trigger stoppers mainly due to the time/budget restrictions – ManSpan Jul 2 '14 at 16:08
  • Fair, in a perfect world what would you do? (I've got some freedom to clean up, if it's the "right way") -- I'm seriously leaning 100% trigger – Nathan Williams Jul 2 '14 at 16:17
  • I had a situation last week where a new workflow rule was interfering with an existing trigger. Our logic is messed up somewhere. I ended up disabling the rule since debugging the trigger would take much longer. I'll get to sorting out the trigger code eventually. – Jagular Jul 2 '14 at 16:32
  • 1
    I would try to follow SForce recommendation and control trigger invocation, until it gets too complex. Then evaluate all triggers and workflows, and rebuild... – ManSpan Jul 3 '14 at 7:54
5

This is a VERY good question, with no TRUE right or wrong answer. IMO though, it is fairly easily (I know this is not always true and we have all likely had a tough time debugging a recursion issue) to control trigger recursion with static variables.

Again, IMO, the main advantage of using clicks over code is not simplicity, but cost. Cost for your company or cost for your client. As we all know SF resources are not cheap, but Administrative resources are cheaper and a bit more abundant that development resources. Even if you are a rockstar developer that can code anything under the sun, you may not be with the company forever or you may have a short term engagement with a client. If you leave them with all code, the maintenance on that code is FAR more costly. The more config you use over code, the more long term savings you can provide your company/client.

Another advantage is that the onus for maintaining the solution doesn't always fall back to you as the developer. A admin or BA can likely provide some Tier 1 support on any issues, where as if you go all out code, it is always escalated to you as a developer as your admin cannot help.

Don't get me wrong, I LOVE CODING, and love coming up with slick new solutions using code. Just have to try to think about long term maintenance costs.

Don't know if that was the angle you were looking for, but that is my two cents on code vs. config and WF vs triggers.

| improve this answer | |
  • Totally valid point on cost of support. My main concern at this point is that there's a complex interplay between the rules and the triggers, which causes some major headaches when debugging (trigger sometimes sets up a workflow rule, and sometimes vice versa). I'm glad to hear there's no "wrong answer" and that actually tells me to work on the triggers more. I can personally feel more confident when triggers are fully tested (with my automated daily testing where it emails me results of every testMethod!) that nothing is breaking vs workflows which can be tweaked and cause issues silently... – Nathan Williams Jul 2 '14 at 16:58
  • 1
    The key is to try to keep triggers to a minimum by using one trigger/object that runs as a class strategy and to minimize recursions plus trigger firing again after workflow runs with re-entry detection methods. As API changes, triggers will need expensive maintenance that won't be required in most workflow scenarios. That's a critical cost factor for most businesses. – crmprogdev Jul 2 '14 at 18:09
  • Totally agree with you @crmprogdev and I'm implementing Hari Krishnan's beautiful framework. That said, the workflow triggering a second set of triggers doesn't count as "recursion" as you want some things before and some after workflows. Great points, though... – Nathan Williams Jul 2 '14 at 18:21
  • Yes, I know you have befores and afters. In some situations you can also get multiple after updates because of workflow firing after the 1st time thru the trigger caused by the trigger having to reset some flag on the object, etc. where re-entry afterward would simply waste time and can be avoided. Its not the same kind of recursion we normally think of, but causes an extra trip thru most of the trigger. – crmprogdev Jul 2 '14 at 18:32
6

Well I also agree to follow the Salesforce recommendations to the extend it's realistic. One thing you should keep in mind (and I hate) about workflows is that you can't define the order of execution...

When things get too complex having to control trigger invocation, recursive execution and ensure idempotence is becoming a big pain.

So I would say use point and click to the point where things are under control. When it starts to getting complicated, go with the trigger approach but be prepared for serious re-engineering.

p.s. I have nothing against admins, but they tend to do things without having a clear understanding of the big picture, which results up in a big (or not so big) mess. So at the end, the developer would need to clean it up ;-)

| improve this answer | |
  • 1
    I ended up going with an all-trigger approach and it's been a god-send from a simplicity standpoint. As you mention, admins who don't have a clear understanding of a change's affect can cause a ripple affect, and that was enough of a reason for me to stick with the all-trigger solution. – Nathan Williams Feb 27 '16 at 20:59
2

I would suggest you workflow + trigger for following reasons:

1) Workflow are easy to implement , easy to maintain & easy to understand

2) You do not need to provide test code coverage so that reduce the development time

With workflow + trigger approach you many times get into situation where trigger is getting called recursive.

To handle this recursion you can use static variable and make sure your trigger is called only once.

Here is sample code for your reference.

public Class checkRecursive{
    private static boolean run = true;
    public static boolean runOnce(){
    if(run){
        run=false;
        return true;
    }else{
        return run;
    }
  }
}

Trigger code :

trigger updateTrigger on anyObject(after update) {

 if(checkRecursive.runOnce())
 {
    //write your code here            
 }
}
| improve this answer | |
  • Can you elaborate on this a little? It doesn't really add much right now. – Matt Lacey Jul 2 '14 at 23:47
  • @LaceySnr I have added more details hope that helps. – AtulRajguru9 Jul 3 '14 at 5:08
  • 1
    only issue i see here is that sometimes you want things to run on the second time only. for instance, if i have a before trigger with two methods, where one should fire the first time through (before workflows) and another should fire the second (after). I honestly think at this point, 100% trigger is my only bet, but I do appreciate the response. I've been toying with this methodology on and off for a week or so... – Nathan Williams Jul 3 '14 at 18:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.