Event Data Filters for Integration Service released!

We are excited to announce Event Data filters for Integration Service with our 22.5 release! When using Event Data Filters, Integration Service will only schedule robot executions when all of your data filter criteria have been met. This results in cleaner and more simple implementation in your automation and less robot execution scheduling keeping your logs more insightful.

Data filters are available across our supported connectors in the catalog. You can find and use them by adding a new trigger on any of your connections, select the desired event from the drop down and configure your filter criteria.

For more information, please find our docs @ Triggers

9 Likes

Great. Now integration service is finally useful! Would be great if there would be a possibility to “queue” the triggered process, in our use case we would like to start it only after work hours so that the production license is available for work-hour scheduled processes.

2 Likes

That’s great to hear @lavmang
Reusing queues is being requested fairly often and one of our roadmap items for later this year to further enhance our event triggers

Awesome and much needed addition. On this way we can optimize runtime even more.

@lavmang - There is various ways to do this through studio, altough it’s not too convenient.

  • Use “Now.ToString” to get current time and just if/else whether the process should be processed (if it’s the correct time). On this way you will still need a little bit of runtime, but not run the whole process.

  • Another way is to use Dispatcher/Performer with a similar scenario, to reduce runtime even lower.

Could you elaborate a bit on this?
Let’s say process X is triggered due to incoming email with matching subject line. The process starts and checks Now.ToString and determines that it shouldn’t run for another 2 hours. How would I then trigger it in 2 hours and free up the license in the meantime?

Thanks in advance

Yeah, maybe I’m also not understanding your use case correctly.

Let’s say you receive an e-mail, which triggers the process. The Process is triggered and starts running, but at the very start of your process you can implement a variable with “Now.ToString” and have a mapping somewhere at what times the process is allowed to be fully run. Basicly “if Now.ToString is in between 6pm - 6am (or whatever time you desire) it is allowed to be processed”, if it’s not “then” → end process.

It’s not a “nice” solution, but sometimes it can do the job to free runtime - especially if the process being triggered is one taking up much time.

We use a similar logic to evaluate whether SLA times are met or not for service delivery reporting.

Thanks for your answer Adrian. This however does not fix our use case. I could implement what you suggested but what I need is for the process to be “re-triggered” at certain time, for example lets say incoming email triggers it at 15:00, robot is running and evaluates that it should not run for another 2 hours.

Would this be possible within studio?

If it was first triggered at 11:00, would it also need to be re-run after 2 hours 13:00 or should it wait until “worktime” is over and run after 17:00?

@GuyVW Maybe the conversation from @lavmang and myself could be moved to Studio Topic? :slight_smile:

I think there might be another way, but you’d have to test things out here.

What if, for the the emails that arrive outside of working hours, you would push them to a specific “pending queue” with a postponed flag set on the queue item.

You would then have a queue trigger in your triggers that will hopefully fire on those postponed items within working hours, bulk processing them in one go to clear the pending queue.

To make it more neat, the queue item content could probably be the event information that originally fired for that new email - I think those are persistent and will allow you to “find back” the event, which should in theory allow you to have one process to process everything. But that’s a question to @GuyVW that it is indeed how it works.

Now that I think of it a bit more, maybe you could even have a routine in your original process that simply pushes items to a pending queue outside of business hours, but also checks at the beginning if there are some items in the pending queue. You could then either simply stop the execution if outside of business hours, or run the normal process within the working hours with an extra workflow that queries for pending queue items and clears those too.

Just some loose thoughts, as mentioned above - there is typically more than one way to achieve things.