Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is there anything available to us in Apex that can be used to determine if a trigger was fired by Workflow/Process Builder?

share|improve this question
As far as I know: no. – Adrian Larson Mar 9 at 16:55
What kind of workflow? Triggers require initiation of DML activity for them to be activated. Off-hand, I can't think of any time-based workflow that causes DML to occur. In an execution context, Workflow and Process Builder aren't called until After a trigger is fired at least once, after which the workflow or process builder activity could cause it to be called again (i.e. recursion); something a Boolean variable can be used to detect. – crmprogdev Mar 9 at 17:38
@crmprogdev how can a boolean (maybe more like a static counter?) be used when the same trigger runs twice before WF gets to run? e.g. user inserts an Account > AccountTrigger runs > updates Contacts > ContactTrigger runs > updates another set of Accounts (different from user Account) > AccountTrigger runs again > WF runs > etc – Mossi Mar 9 at 18:59
@Mossi. It depends on trigger design whether static or non-static var would be used to prevent recursion. I've written some triggers that required static boolean and others where a static boolean would cause issues with other instances of the same class. In the situation you cite where Contacts are updated by an Account trigger, I'd expect there to be two instances of the Account trigger. A 2nd instance would begin after update of the Contacts that creates a diff and a 2nd rel execution instance of trigger for those Accts gets spawned. NOT operating on same records any longer. – crmprogdev Mar 9 at 19:42
Exactly. But in that case how can a boolean (or any other variable) tell whether or not a WF caused the 2nd Account trigger to run? – Mossi Mar 9 at 20:19

Triggers (which represent the domain layer in a Separation of Concerns architecture) should not have to know how they were invoked as they could be invoked via

  • Web or REST service DML
  • VF controller
  • Standard controller
  • Data Loader
  • AJAX Toolkit
  • Asynchronous process
  • ...
share|improve this answer
But they can detect if they've been re-run in the same transaction by using a static variable. Usually, this doesn't matter for a well-written trigger, but it can avoid extra queries/DML statements by doing so. – sfdcfox Mar 9 at 17:17
But I believe the trigger context in SF does allow partial detection of the caller, using the isExecuting flag check. Isn't it so? – Mossi Mar 9 at 17:28
I agree with @sfdcfox. I always feel soiled if I code trigger.isExecuting as that usually means I haven't structured my separation of concerns properly. There is no Workflow.isExecuting. – cropredy Mar 9 at 17:33
@Mossi a workflow could include an additional field update to an sobject field isinWorkflowContext__c that would be useful to a before insert or before update trigger as those triggers can switch it off – cropredy Mar 9 at 17:36
Yes. But I was just trying to point out that SF may not be completely following the SoC architecture as they are partially exposing how triggers were invoked via the isExecuting flag. As for the custom field solution; that can definitely be applied to one-off scenarios. But it fails in bigger designs. – Mossi Mar 9 at 17:38

I was searching the same some time ago and it looks like the answer is NO. There is also an idea posted 6 years ago on that but yet not implemented. So it is an old one.

share|improve this answer
Static variables can detect if a trigger re-fires a second time, which is probably why that idea was never seriously considered. However, I would say that the ability to detect if the trigger happened from a particular context (API versus UI) would be pretty convenient. – sfdcfox Mar 9 at 17:19
@sfdcfox I'm not agitating to vote for that idea:) I'll better edit my post. – Oles Malkov Mar 9 at 17:24

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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