Drop AO participants based on power list that is used in the sync

You are right that this isn't the model of how AO (and most business process systems) work.  However, there are extremely legitimate use cases.  (Curious to hear specifically the ones you have encountered.) E.g. if we select participants based on low usage then if they no longer have low usage you may want to pull them out.  The team is definitely looking hard at that scenario through the lens of Goals that can be met and cause the participant to jump to a different step or exit.  For now you can effectively add that yourself using Calculated Fields and Conditional Wait.  Specifically, I suggest adding a calculated field in the AO that measures the key condition that would make you want to pull out the participant and then a Conditional Wait step that would check that calculated value and, if the value indicates that they should be removed, then branch to an Exit. 

Hi Alex,

Thanks for sharing this. Can you help me understand the use case of what tokens/fields you want to update once the participant is live in the journey?

Thanks
Abhishek S

Based on what I've learned, we can essentially "drop" participants by filtering the default email template to exclude those that would normally drop from the power list.

I think what would help deflect some of the tickets (like the one I had sent in that was followed by Alex posting this):

1. Clarity or best practices around power lists
-- i.e. Don't bother with doing a bunch of criteria filtering here
-- Get a standard group of contacts in your power list, then rely on template filtering in an AO
-- This results in less power lists - which in turn results in less AOs
[i](not sure if it'd work the same for outreaches, I haven't worked with those much)

2. Clarity around the default template filter in AOs
-- Make its use-case a little louder so we, as end-users, know that if we want to "drop a participant" based on power list filters, that it should be filtered out through the AO itself.

That said, there's still benefit in adding a toggled feature to "drop a participant" as it falls off the power list, but as an end-user, if there's a solid workaround, we'd rather see that time spent on other improvements.

And is there a legit "Best Practices" section for each major feature of the product? I haven't found it yet, but it'd be incredibly useful to reference. Large ROI if it doesn't exist and you all put effort there. 

Thanks for being so involved in the community and product feedback; I haven't seen many services do this. ++ 

Thanks for the info and suggestions.  The idea to use the template filter is clever.  I do worry a bit that the process will become a bit opaque.  I encourage you to try an explicit "Conditional Wait" step before your email in which you use the Calculated Field feature to fork off the participants who no longer meet the criteria for getting the email. On this branch you can either exit the flow or skip the following step and continue (or do an alternative action but that wouldn't seem to fit your use case). 

Thanks for the suggestion, Karl! I didn't think to try doing this through conditional wait (still learning and implementing our instance). 

In the next AO we build, I'll try using it to drop participants.