16

The criteria is not checked again in this situation - see below According to the Time-Based Workflow FAQ, any record which no longer matches the criteria for a time-based workflow will be removed from the queue. This is vague though and doesn't indicate whether a test is performed if the other record is updated. I would expect that the criteria would work ...


11

Work Around: if action is a field update As Matt mentioned in his answer Time-Dependent workflows only check to see if the criteria is still true if the record that is queued is updated. They do not check to see if the criteria is still true before kicking off the action. However if your action is a field update you could place your criteria in the formula ...


9

nivyaj, I posted an answer to the same (or very similar) question that another admin found helpful: When does the time-based workflow put records in it's queue? The possible solution is: Create a checkbox field on your target object called "Retroactively Triggers Workflow?" Edit your workflow with the time-dependent action to "Evaluate the rule when a ...


8

To accomplish a number of date-dependent pieces of work we run a Scheduled Job - a class that implements Schedulable - every night. That job can then kick-off a chain of classes that implement Database.Batchable. These avoid governor limit issues by breaking their work up into multiple batches passed to the execute method, each with its own governor limits. ...


8

The time based workflow processor only runs once every fifteen minutes, starting from the time the processor starts. For example, if the server comes up at three minutes past the hour, it will run at 3, 18, 33, and 48 after the hour.


7

What is your Workflow's Rule Criteria? Have you tried: CloseDate >= TODAY() + 7 That way if it closes today, the rule criteria will evaluate to false.


7

Time based workflow is perfect for this. The workflow turns off automatically when the criteria changes. Scheduled Apex will also work, but isn't needed. Batch Apex would ensure you can scale to large data volumes. From Help & Training Time-dependent actions remain in the workflow queue only as long as the workflow rule criteria are still valid. ...


7

I don't believe there is any guarantee about when a timed workflow will trigger - as stated in the docs : "Time-dependent actions aren't executed independently. They're processed several times every hour, where they're grouped together and executed as a single batch." I don't know of any way to guarantee a time - all async operations operate based on "...


7

Any field update from a Workflow Rule/Process Builder/Apex Trigger will cause update triggers on affected records to fire.


6

The problem is with how you are trying to get the workflow rule to fire. As crop1645 commented, changing the date will not cause the workflow rule to fire. Take a look at this help doc here. Your workflow rule is set to fire when the record is created, and any time it’s edited to subsequently meet criteria: (Default) Evaluate the rule criteria each time ...


6

Salesforce does not throw the triggers away if it goes over the hourly limit it just queues it up for the next hour. So in your example of 3,000 workflow time triggers firing at once. Which seems super crazy to have that high a volume but I digress... It would flow something like this: Salesforce checks to see if there are any time triggers that are ...


5

The pending actions in the queue will not be affected. In fact, the pending actions int eh queue that don't match the new criteria will remain in the queue. The criteria is only checked upon entry to the queue. changing the entry criteria doesn't effect those actions that already made it into the queue. I have been burned on this before. IMO, technically,...


5

Short answer, yes, if the object is in a time-based queue, and its criteria changes to no longer fire that rule, it will be removed. Longer answer, this article details the common approaches to the problem you're seeing and may give you some ideas for other solutions to the problem.


5

Here is an old blog post I saved for this purpose: The 5 minute workflow It will show you how to set a workflow to fire in intervals of minutes. BUT: you cannot have it fire say every x minutes. Once a workflow fires it is done unless you reset the field and update the record. If you want something to fire every x minutes, you really should look at ...


5

Apex tests are for testing Apex. They are not designed to test for declarative features. That being said, I agree with the desire to do so. Why not write a test that ensures that functionality behaves in a predictable way, regardless of it being done via point-and-click or via code. Back to your question though. The time based workflow queue is not ...


5

The object you're looking for is the WorkflowTimeQueue. However, it does not appear to be accessible from Apex Code or the API, so there's no way you can clear pending entries, other than manually deleting them from the queue in Setup > Monitoring > Time-Based Workflow. Instead, you'll need to edit/modify the record so it no longer meets the criteria, at ...


5

I think, you are creating time based action based on created date and this time based action is getting queued. I would suggest you to create a separate datetime field, let's say Action DateTime which will initially be populated as created date + 7 days. If any action has taken on the lead then mark this Action DateTime as blank. Your time based action ...


4

Triggers only fire when a record is created, modified or deleted. You can't use triggers to fire at a certain time. You should create a scheduled job. See http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_scheduler.htm. The code would look something like this (untested): global class CreateCustObjRecord implements Schedulable{ global ...


4

This is something that would be a better fit for scheduled apex - this will allow you to execute some code according to a date/time schedule. You can schedule the job from the UI or from code, via the developer console. Take a look at the docs at: http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_scheduler.htm There's a blog post at: ...


4

The only way to "kill" a pending transaction for now is to modify the record so it doesn't meet the criteria any longer. You can't modify the date/time it will go off, unless that date/time is driven by a field on the record, in which case updating the record will change the firing time. For example, if the date field called "Due Date" triggers a workflow ...


4

This is the correct way to do this. It will use the status change date assuming you are not using a formula field. Assuming you have just set the field using TODAY it will be fine to use. The trigger just cant reference a nondeterministic formula. Try checking on the work flow to update field check reevaluate workflow criteria. I created a workflow that ...


4

Adding to the answer, an Apex class that implementing the Schedulable interface can do the job too. References: Apex Scheduler Cron Expression writer - cronmaker.com Example: Write a class implementing the Schedulable interface global class EveryFifteenMinutes implements Schedulable { static void doStuff(){ // ... } public static ...


4

My understanding says that Workflow field updates will not fire custom validation rules. The field will be updated irrespective of validation rule. Before & After triggers will fire. SO AddError might work but validation rules are bypassed. Here is a extract to second my view "Trigger and Order of Execution" point number 13 : If the record was updated ...


4

Scheduled apex jobs are the only time-based alternative for time-based workflows within the SFDC platform currently. So your idea of moving to scheduled apex is the way to go. As a general way of making the decision between the 2, I'd say use time-based workflow unless you run into its limitations, including (but not limited to) the following: Time ...


4

You can use Escalation Rules for this purpose. It will send an email to a user and also optionally assign the case to another user (such as a manager). Unlike a workflow rule, it shows a red arrow that indicates the case has been escalated and needs attention.


4

You will want to write a batch and execute it daily. Your query locator should look like: SELECT Id FROM Lead WHERE CreatedDate < LAST_N_DAYS:15 AND Consent_Obtained__c = false Then your execute method will just look like: try { delete scope; } catch (DmlException dmx) { // send email? create log record? }


4

You could make it a combination of workflow logic and trigger. Workflow Rule Evaluate when record is created or modified and meets the criteria. Criteria: Date Consent Obtained equals null Action: Time Based action (15 days after CreatedDate) Field Update: Expired Lead -> Checked trigger deleteExpiredLead on Lead (after update) { Lead[] deletes = ...


4

I've got to the bottom of one scenario specific to a sandbox (still seeing it in production though) - for some reason the default workflow user was bugged. The user lookup was completed with the expected user but if you clicked on the lookup it couldn't be found (it did exist). I'm guessing either a faulty sandbox creation or something like the user record ...


4

Go to Setup Menu->Create->Workflows->Process Builder->New-> NameYourProcess Save Add Object You wanna make this workflow work On Mark "when a record is created or edited" Save Add Criteria -> Select a name for this. -> Select "No criteria Just execute the actions!" Save. Click on Inmidiate actions->Name It-> Choose "Select the xxx record that started ...


4

This is working as designed. If the close date is 2 weeks from today and the WFR is supposed to send an alert 30 days before, it will send immediately as it is < 30 days before the close date. To prevent it you will have to exclude those opportunities in your criteria


Only top voted, non community-wiki answers of a minimum length are eligible