Workflow waiting for a timer to finish OR event fired?

Jacob Saaby Ni1 · ‎06-20-2019

Hey everyone.

I've run into sort of a peculiar problem:

I want to create a workflow which uses a timer to wait a day, then perform something again.

But if something specific happens in the meantime, it should just end the workflow.

It doesn't seem like that's possible within the workflow? *HINT SERVICENOW - Introduce a multi-action "wait for" activity or action, which lets you wait for multiple types of activities ;)*

So, could a solution be to use a business rule to simply cancel that workflow context? If yes, how do I go about doing that?

Is there a smarter way than doing it this way?

What would your solution be?

Jacob Saaby Ni1 · ‎09-03-2019

EUREKA!

Oh my god. The answer was RIGHT there in front me the whole time. How could I not be aware of this? I almost facedesked myself when this dawned upon me.

The solution is to use Branch/Join.

Use a Branch activity.

From Branch to a Timer activity.

From Branch to a Wait for condition activity.

From Timer/Wait for condition to where they need to go.

This launches EXACTLY what I needed: It waits for both the timer and the wait for condition. Whatever is true first, cancels the other.

In fact, you don't even have to use branch/join unless you explicitely want to visualize your intentions. Because the workflow behaves as if it's a branch/join, if you drag two lines from the same box to two different activities.

Here's an example. Tested it. Works like a charm, and you don't get 10k activity log lines in your workflow context.

View solution in original post

Brian Lancaster · ‎06-20-2019

I have something similar. I put an if activity after the wait for and check if my other conditions. If it fall into the condition where I need to cancel the workflow I send it down the No path which ends the workflow. Otherwise I go down the yes path and continue the workflow.

Jacob Saaby Ni1 · ‎06-20-2019

Hi Brian.

Thanks for that 🙂

My problem here is, that it has to wait a day. When it reaches the timer, I'm out of luck. It's stuck at the timer.

The challenge here is, that the change that happens which should end the workflow, happens while the timer is running. And can happen many times while the timer is running. So, somehow the workflow should be able to handle that change even while the timer is running.

And just when I wrote that, I thought of something: What if it's a 1 minute timer followed by a an if "states have changed" with a turnstile limiting it to 1440 runs? Then it would resemble sort of a polling function. And I don't think the sort of change happening here, would suffer anything if it had to wait 1 minute.

So every 1 minute it would finish the timer, check if the conditions have changed. If they haven't, go back to the timer. If they have, end the workflow.

Pros/cons?

Brian Lancaster · ‎06-20-2019

I'm not sure I follow. Can you give me more details so I can understand your requirement?

Jacob Saaby Ni1 · ‎06-21-2019

Hi Brian.

Ok, so... My problem was, that after the workflow did what it should (send out a notification), I sent it to a timer that waited 24 hours, before sending out another notification.

However, when the workflow reaches that timer, it no longer responds to relevant changes until after 24 hours.

So I was stuck.

What happens if the user answers in the meantime? Then the workflow should end, because the 3 day waiting cycle before resolving the incident due to inactivity should then end, and another one should start if we ask the user for information again.

But it couldn't, because it was stuck for 24 hours.

So what I've done is this:

After the turnstile that limits the overall notification process to running 3 times, I send it to a 30 second timer. That timer goes to an IF (the conditions are still true). If they are true, then go through a turnstile that limits running for 2880 times. If not true, go to End.

That means, if the conditions never change, we still wait a full day. We just don't wait 24 hours in one go. We wait 2880*30 seconds = 24 hours in total. But because it's split into 30 second intervals, every 30 seconds I get a chance to end the workflow if the user answered in the meantime.

So I kinda created a polling timer loop within the workflow.

And by the way: REMEMBER to set "Run Multiple" to true. Otherwise, ServiceNow will go "oh, you already have a workflow context. It's finished, but I don't care, you have one, and what's what you're getting".

When you set Run Multiple = true, it will finish the workflow context gracefully, and start a new one the next time the conditions arise.