3

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!

Improve this question
2
  • I'm sure you saw this but you can automate deletion of pending flow actions per this help article with a little bit of work upfront - help.salesforce.com/articleView?id=000213446&type=1
    – Nicholas Zozaya
    Commented Mar 2, 2019 at 7:54
  • deleting the paused flow interviews, creating a new PB version, then doing dataloader to coerce DML to reconstruct the scheduled actions is problematic if your scheduled actions send emails based on a date-offset ladder progression as recipients are likely to see duplicates of emails they already received.
    – cropredy
    Commented May 19, 2021 at 15:53

2 Answers 2

Reset to default
2

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.

Improve this answer
7
  • 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
    Commented Feb 26, 2019 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
    Commented Feb 26, 2019 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 ♦
    Commented Feb 26, 2019 at 2:42
  • 1
    For sure - someone influential should put together a minimal repro and try to get it pushed up to a Known Issue.
    – Charles T
    Commented Feb 26, 2019 at 5:16
  • 1
    Another thing to consider is that you can't push updates via the metadata api to flows with pending actions. Workflow rules don't have that limitation.
    – Nicholas Zozaya
    Commented Mar 2, 2019 at 7:53
1

We use an InvocableMethod in our Scheduled Action Process Builder.

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

Improve this answer
1
  • 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
    Commented Feb 26, 2019 at 1:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .