Decision Stage

#1
Hello! Would anyone be kind enough to help with a quick process here?

Basically, I have a collection with people to chase based on various conditions. What I need though is to make sure that one recipient does not get sent the same email for the same condition, regardless if it's for a different entry in the collection.

12345 | me@email.email = condition 1 not met = send chaser email 1
12346 | me@email.email = condition 1 not met = check if the email address has been sent a chaser for the same condition
12347 | me@email.email = condition 1 met but condition 2 not met = send chaser email 2
12348 | me@email.email = condition 1 met but condition 2 not met = check if the email address has been sent a chaser for the same condition

Is there an expression in the Decision stage you may be able to share that would basically say
Has this person/email address been chased for not meeting this condition yet?
If Yes = continue sending chaser email
If No = End
Thank you!
 
#2
When a case fails condition 1 and an email is sent, you could copy that case to another work queue (say, Email Sent queue). Use a unique identifier (maybe email address??) as the key field of this queue. Then, use the Email Sent queue as sort of a lookup table as follows: When processing the next case and it also fails condition 1, you could see if the case's key (email address) exists in the Email Sent queue and base your decision for the path to follow on whether it was found in that queue or not. If it is found in the Email Sent queue, then it has already been sent a chaser and you don't have to send one for the case being processed.

Do similar logic for when condition 2 is not met. Use separate Email Sent queues for each condition's chaser email, or use the same queue by adding tags ("Chaser 1 Sent" or "Chaser 2 Sent") to each case upon copying it to the queue, and basing your decisions on 1) existence in the Email Sent queue and 2) the tag.
 
#3
When a case fails condition 1 and an email is sent, you could copy that case to another work queue (say, Email Sent queue). Use a unique identifier (maybe email address??) as the key field of this queue. Then, use the Email Sent queue as sort of a lookup table as follows: When processing the next case and it also fails condition 1, you could see if the case's key (email address) exists in the Email Sent queue and base your decision for the path to follow on whether it was found in that queue or not. If it is found in the Email Sent queue, then it has already been sent a chaser and you don't have to send one for the case being processed.

Do similar logic for when condition 2 is not met. Use separate Email Sent queues for each condition's chaser email, or use the same queue by adding tags ("Chaser 1 Sent" or "Chaser 2 Sent") to each case upon copying it to the queue, and basing your decisions on 1) existence in the Email Sent queue and 2) the tag.
Thank you. I will give this a go. But I may need a little spoon-feeding here if you don't mind. A bit new to Blue Prism and a little terrible at it.
 
#4
From what I understood, you can try this approach.
Create a new collection with fields :
Email | Condition1 | Condition2 | condition3 | Condition4 | so on

Whenever you end up sending an email to a particular Email Address:
Update above collection with values like :
me@email.email | Sent | | | | (This tell you that Email for Condition1 was sent for me@email.email, but other fields are BLANK)

Finally, you will have to do a check BEFORE sending an email on the above collection.
Find the email address from the collection and read the respective Condition Value.
If BLANK = SEND Email & Update Field value to Sent
Else Don't Send Email

Hopefully, this is what you want to achieve.
 
#5
From what I understood, you can try this approach.
Create a new collection with fields :
Email | Condition1 | Condition2 | condition3 | Condition4 | so on

Whenever you end up sending an email to a particular Email Address:
Update above collection with values like :
me@email.email | Sent | | | | (This tell you that Email for Condition1 was sent for me@email.email, but other fields are BLANK)

Finally, you will have to do a check BEFORE sending an email on the above collection.
Find the email address from the collection and read the respective Condition Value.
If BLANK = SEND Email & Update Field value to Sent
Else Don't Send Email

Hopefully, this is what you want to achieve.

What I was actually saying was not using collections as you describe. Instead, I was suggesting that 1 or more additional work queue(s) be used. When a case fails condition 1 and an email is sent, that work item can be copied to a 2nd work queue. Then, when processing the next work item in the main processing queue, if this case also fails condition 1, then use the Collection Manipulation utility's Contains Value action check to see if the current work item's key is found in the 2nd (email sent) queue. In this way, the email sent work queue serves as a sort of lookup table. If it exists in that queu, then it has already been sent an email, and no email needs to be sent for the current case. Use similar logic for condition 2.
 
#6
What I was actually saying was not using collections as you describe. Instead, I was suggesting that 1 or more additional work queue(s) be used. When a case fails condition 1 and an email is sent, that work item can be copied to a 2nd work queue. Then, when processing the next work item in the main processing queue, if this case also fails condition 1, then use the Collection Manipulation utility's Contains Value action check to see if the current work item's key is found in the 2nd (email sent) queue. In this way, the email sent work queue serves as a sort of lookup table. If it exists in that queu, then it has already been sent an email, and no email needs to be sent for the current case. Use similar logic for condition 2.

Thanks, folks! My colleagues and I worked on it together and we got it sorted. :)
 
#7
What I was actually saying was not using collections as you describe. Instead, I was suggesting that 1 or more additional work queue(s) be used. When a case fails condition 1 and an email is sent, that work item can be copied to a 2nd work queue. Then, when processing the next work item in the main processing queue, if this case also fails condition 1, then use the Collection Manipulation utility's Contains Value action check to see if the current work item's key is found in the 2nd (email sent) queue. In this way, the email sent work queue serves as a sort of lookup table. If it exists in that queu, then it has already been sent an email, and no email needs to be sent for the current case. Use similar logic for condition 2.
I understood your point.
I was replying to the OP with possibly a new approach if I understood the problem correctly, which will not involve usage of a work queue.
 
Top