The phrase "manipulate the workflow from a business rule" sends a chill down my spine. As a general rule, we recommend firing events at workflows to get them to use conditional behavior vs changing state out from underneath them. Here's what I mean by that.
I'm guessing you have a workflow that looks like this:
And your asking how to create a business rule that will under certain conditions make that timer fire early. That's not difficult, but it hides the logic that the flow is really using. Sometimes, the timer will just seem ti fire early, and people who don't know about the business rule in the background that's doing it will scratch their heads and file an INT on HI saying that Timers, or Workflow, or both, are broken.
I would suggest this alternative:
With this version, the timer will be set and the workflow will wait until either "certain interval" goes off, or "certain conditions" are met, whichever happens first will complete their respective activity and transition to "do some stuff". The activity that didn't complete will automatically cancel when the workflow ends.
What's nice about this is all the logic is clearly laid out in the workflow, the context diagram and workflow log will show you exactly what happened when you look back at the workflow context, and you don't need to add any business rules.
This assumes that "certain conditions" are all based on the workflow's current record. If that's not the case, you can do a similar flow using Wait For Event, but you would need to add a business rule that fires the event when those conditions are met.
If you want the timer to reset when the certain condition branch runs, then you can cancel the existing timer, and transition back to it to create a new one.
To cancel the existing timer you send it a "cancel" event. Unfortunately, I had to use a Run Script to do that. We do have a "Create Event" activity, but its for creating system events, not workflow events. Here's the script I used:
var timerActivity = new GlideRecord('wf_executing');
timerActivity.addQuery('context', activity.context);
timerActivity.addQuery('activity.name', 'certain interval');
timerActivity.query();
while(timerActivity.next()) {
new Workflow().fireEvent(timerActivity, 'cancel');
}
That was definitely more difficult than it should have been. I'll be suggesting we put adding a FireEvent activity into our next release plan.
Timer also supports "pause" and "resume" events. So if you just want to pause the timer while you wait for the "certain conditions" branch to do its work, you should be able to use the same script and substitute in the different events. But you'll also need to add Join and another Run script to cancel the Wait for condition activity
What's happening here is that if the "certain conditions" are met. The flow will move along that branch and into the Join. It will wait at the Join for the timer to complete, and once it does, the Join will finish on the "Complete" transition because both incoming transitions to it finished. The cancelling Run Script in this scenario does nothing, because the Wait for condition activity is already finished, so the event is just ignored.
If "certain conditions" had never been met, the Wait For condition will still be active, and get cancelled when the timer finishes. Now, the Join only has one incoming transition that finished, but Join is smart enough to know that the Wait for branch got cancelled and can never complete, so it takes its "Incomplete" transition.
