Where to invoke "Email" component to ensure that multiple files created by the job are emailed in one batch?

Hi all,

I have a process which uses a state machine and within the Initialise state collects PDF reports from a site and adds those files, along with a number of excel files in the same directory, to an orchestrator queue, and then in the Process state I either simply print, or print to PDF then print, respectively.

I would then like to attach all the PDFs (direct PDFs and the excel files which were PDFs) to one email, and I have a component for doing this which should work fine, but I was wondering if it would be advisable to invoke this in a new “State” or if it could be included in the Process or End Process States?

I feel if in Process it will send individual emails for each report as it iterates through, but I think I read it could be included here, so would appreciate some advice please. If in a new state, where in the flow would this go? Between “Get Transaction Data” and “End Process”, or would it simply be best to be invoked in “End Process”?

Many thanks in advance,


Here is my advice:

Init - scrape and push to queue
GetTransaction - read each item from queue and then set the transaction item
Process - get the item and print(if pdf) or print to pdf (if other) then print. Also set them to a directory(say processed) or set a status in queue to something

so now this repeats until all items from the queue are processed, then it moves out and comes to end process

before that add a state machine - sendEmailWithAttachments

Here you check if your processed folder has any files/or status of messages which is put before, then you send and email and attach all the files to it.
Else you transit to end process

Why i say this: Look at the REF Framework it supports this kind of logic.
Here is what one of my framework looks like for a similar requirement


Perfect, thanks, that makes a lot of sense! The more I thought about it the more I thought either own state machine, or within End Process.

1 Like

i agree, i went through the same thought process.
But the click is End Process - in the frame is just to end it all, even if init fails it goes there, so rather keep your logic out of it :slight_smile:

Hadn’t thought of that, great point. It’s now being invoked within it’s own state in a try/catch.

Out of interest, if it fails here to send an email for whatever reason, where do you throw this? I have the catch emailing the process owner to let them know, but…if emails are down then that seems redundant anyway really.

Yes, the whole logic of email dosent work then.
But then in that case what would you as a human do, is the question?
Ping , wait, check for the issue, resolve then try again. That’s what you need to handle, teach the bot :slight_smile:

Too much? :stuck_out_tongue:

This is still my first automation project, I think I’ll need at least 1 or 2 more before I head down the machine learning path to resolve issues! :stuck_out_tongue:

1 Like

Hey @nadim.warsi.

would you be mind to share screen print of logic written in MailTrigger state machine?

Thank You,
Happy Automation! :slight_smile:


Thanks for asking, I was quite interested in that too! :smiley:

1 Like

I can tell you the logic: :stuck_out_tongue:
A state machine which waits for one or more emails using filter.
If any it will go and init, getdata and process, if not it will quit

1 Like

Is this process running on an attended or unattended bot?

I was originally building my automation to have a state to check for a kick off email however we realised having a schedule to check for an email was using up valuable resource time, so switched from unattended to attended to allow this step to be bypassed. Have you got many processes which rely on a kick off/trigger email, and how do you cope with this? Is it not 5 minutes every hour that one of your bots is now being used for non processing?

Actually for me the count is very less.
So, i had a schedule and then it checks the mail box, and im picking top-30 which is good number of email at one point of time to process.
My process was more of a bulk process at one point of time through the day.

Ok I guess that works well for once a day tasks, I was facing the issue that we were having to get the bot to run as soon as possible after email was received, so would almost need to be constantly checking. I think triggers could work then if you had an unattended bot constantly skimming an inbox and sending jobs to a host of other bots, but in a smaller organisation it’s a waste of resource.

agreed :slight_smile: