Long running attended flow Best practices

Hello,

I have very specific use case where an attended bot (after doing some UI automation steps of a BP on workday) needs to wait for a notification (system notification) to be arrived (which usually comes automatically 4 weeks before a specific end date).

In this case the bot seems to be long running flow. Any suggestion on how to handle this situation ? Which activities or logic should I use ?

Thanks.

Hello @Debartha_Mitra_DE
Kindly use FlowChart workflow,
In which, Loop the connection for getting the notification, once Notification received, the process will goes to true and next process will continue, otherwise it will in loop , go and check for notification or message.

thanks for your reply.
Is it best practice or wise to use loop in this case ? As the system notification may come after months.
Also, which activities should I use in loop ? Some thing related to Wait activities ?

@Debartha_Mitra_DE
If you can determine the duration to receive the Message or notification you can use the static delay option.
Otherwise use the loop, with delay. Check the condition , If its true pass to next flow or process, else again loop to check the condition.
image

@Debartha_Mitra_DE
For the best practice, Trigger the bot once daily, If the certain input get, it will strat run, otherwise it will stop the process

ok so it should be a separate un-attended bot (separated from the main bot)?
So the first bot will do its UI automation and completed and then this un-attended bot will be resumed and run daily or weekly and check for notification and do its task when notification arrives right ?

@Debartha_Mitra_DE As per your requirement, you can design.
If process 1 and process 2 are independent, you can build 2 bots.

Hi Debartha,

I would not consider this a long running workflows. Those are typically for something with a human in the loop (via action centre), a fixed delay to resume or waiting for an external application to complete a task.

An easy example for long running processes is looking as smart document understanding.
Imagine you have a scenario where a robot reads from a mailbox and grabs an invoice, it then passes it to a third party SDU system such as ABBY, it can provide the document to ABBY and then create an ‘external task’, the job will go to a suspended state and stop running on that machine. Other jobs can now run on it in the meantime.
Once ABBY completes its SDU work it can complete the ‘external task’ and the job will automatically resume.

Perhaps then it needs some human validation and creates an action centre task, again the job needs to wait for a human so can suspend the job so the machine is free to run other jobs whilst waiting for the human. Once the action centre task is done again the job resumes.

The other poster was not talking about a long running process, they were proposing an infinite loop, this will block the machine until the condition for the loop is satisfied. If you need to wait 4 months that means you can only run this one job for 4 months and cannot restart your machine. Not practical.

I see two choices. One is to completely separate the two jobs and have some bot that keeps checking for new notifications.

The other I see is to indeed use a long running process but on this one you will check for the notification, if it isnt present then suspend the job for 24 hours. This frees up the machine, when it wakes up tomorrow then it can again check and suspend. This loop can continue until the notification appears and allows you to use the machine for other tasks in the meantime.

1 Like

thanks a lot for the tip

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.