2

We have been using Process Builder instead of workflow for many years now. But we have been bitten a few times by problems with Scheduled Actions in PB.

Specifically, we were just bitten by the behavior described here https://developer.salesforce.com/forums/?id=906F0000000fz6b and in several threads here on SE.

tl;dr: although this isn't clearly stated in SF docs, it appears that if a Process has Scheduled Actions already in the queue, and you make and activate a new version of the Process, not only do those actions stay in the queue, but changes to the triggering record will no longer cause them to re-evaluate. That can lead to emails going out that you don't want, if a new version has been activated since the action triggered.

There doesn't seem to be a great way to avoid this, at least not without a ton of extra work to clear out the queue and then re-trigger the Scheduled Action after each new version change.

We are thinking of making a new policy of using Workflow for all Scheduled Actions where we don't want to write code, and continuing to use PB for other uses.

Question: anyone else doing it this way? Sounds like a good idea or a bad idea? General feedback and did-you-think-of-this welcomed!

1

We use an InvocableMethod in our Scheduled Action Process Builder.

This allows us to check that the criteria is still true.

  • Thanks, @shmuels. I should have specified that this is about situations where we don't want to write code (which we do in other situations). Will clarify in the OP. – mscholtz Feb 26 '19 at 1:18
1

You should not avoid Process Builder. Workflow rules are "deprecated" (in the sense that Salesforce recommends that you should not use them). For example, the Workflow help topic says:

TIP Whenever possible, automate your if/then statements with Process Builder instead of workflow rules.

While there's no definitive "shut off" date, it would be preferable to use PB, as it is the intended future of point-and-click automation. For those issues you're having, log a case to get a bug logged against it. PB is more efficient and capable than Workflow Rules; despite the few glitches it has, it's still preferable to use it.

  • 1
    I would still argue that PB has a major feature gap on deferred actions - one is the above noted lack of predictability. Monitoring the workflow queue is relatively easy, whereas monitoring the "paused flow interview" queue for specific records is not. I personally believe SFDC will not fully deprecate WFRs until ALL relative deficiencies of PBs are addressed. I advise my team that if workflow behaves better for a use case, they're justified to use it over PB. – Charles T Feb 26 '19 at 1:43
  • Personally I wouldn't be surprised if Process Builder gets merged into the new Lightning Flow Builder in some manner one day. We haven't seen huge advances in its feature set in a few years. – Charles T Feb 26 '19 at 1:46
  • @CharlesT This is why I suggested logging a bug; it would be more ideal if the bug were fixed rather than use the older WFR hoping that PB someday gets fixed despite nobody complaining about it. Of course, one could report the bug and choose to use WFR, for now, until the behavioral problems are remedied. – sfdcfox Feb 26 '19 at 2:42
  • @sfdcfox yeah, I agree in general, which is why we've been using PB up til now. But for Scheduled Actions in particular, the behavior I describe is pretty much a deal-breaker. If we're automating an email, which we often are, it's a cardinal sin for a system to send it when it shouldn't. And there doesn't seem to be a good workaround. I'm pretty sure this behavior is known, as it's been posted about for at least 3 years. – mscholtz Feb 26 '19 at 5:12
  • 1
    For sure - someone influential should put together a minimal repro and try to get it pushed up to a Known Issue. – Charles T Feb 26 '19 at 5:16

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.