Decision Stage

GORJUSMARSH

New Member
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!
 

Pete_L

Active Member
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.
 

GORJUSMARSH

New Member
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.
 

sahil_raina_91

Active Member
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.
 

Pete_L

Active Member
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.
 

GORJUSMARSH

New Member
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. :)
 

sahil_raina_91

Active Member
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.
 

GORJUSMARSH

New Member
Congratulations! What approach did you use to resolve the issue?
We managed to create a way to collect each email address per case once the chaser is sent to it and use that as a reference to decide whether the email address has been sent something for that condition yet or not. similar to what you suggested but a new collection rather than a queue. works well. thanks.

View attachment 1590672531693.png
 

GORJUSMARSH

New Member
@Pete_L I need help on another thing but unrelated to this topic. Thought rather than writing a new thread just carry on with this. I just need to change same date filters on the process and it's doing my head in. Basically I just need the expression for this.

Start Date = Filter is 3 months before of end of (current) week date

End Date = Filter is 1 month after end of (current) week date

Do you have an expression I can try to use?
 

Pete_L

Active Member
This should be in a new thread so people can better find it in the future, but here is your answer:
Assuming Start Date is in Date format: StartDate -3 months would be calculated using AddMonths([StartDate],-3), and EndDate -1 month would be AddMonths([EndDate],-1),
 
Top