Skip to main content
Manage Recipients

Create and manage recipient groups for Alerts and Approvals for Workflow

Updated over a week ago

In order to utilize Alerts and Approvals for Workflow, you need to set up the groups that you want to receive the notifications and approval requests. Recipient groups are available to select throughout the enterprise but may only be created, edit, disable, or deleted here.

There will be two groups already set up to get you started: one for program managers in all programs and one for the caseworker(s) assigned to a participant in any site across the enterprise.


Step 1 - Click Manage Recipients under the Enterprise section on the Navigation Bar.

  1. Recipient Group Name – Displays the name of the group. ETO comes with 2 default groups, Program Managers for All Programs and Case Worker, available to be used with any Alerts users create.

  2. Calculated Name – Displays the parameters of the users included in the group.

  3. Take Action - Column header

  4. Edit – Click here to make changes to the parameters of the condition.

  5. Test – Click here to test the condition against existing participant records.

  6. Delete – Click here to delete the condition

  7. Add New Recipient Group – Click here to create a new Recipient Group

  8. Test Recipient Groups – Click here to test the group and ensure desired users display.

Creating a Recipient Group

Step 1 - Select Manage Recipients under the Enterprise Section on the Navigation Bar.

Step 2 - Click Add New Recipient Group, 

Step 3 - Select the desired Recipient Type from the Area drop down.

The Recipient Types available are: 

  • Users – based on assigned User Role and or Program Security. 

  • Caseloads – based on Users who have Participants assigned to their Caseloads 

  • Entity – based on existing Entity record 

  • Contact – based on a contact record associated with an Entity.

Note: When building user-based recipient groups, always include, "User has security for triggered program" allows the alert/approval to start in the right site/program.

Step 4 - Chose the specific requirements for the recipient type within the Available Values, Operators and Values Drop boxes.

NOTE: The options displayed in the Operators and Values fields vary dependent upon the Recipient Type and Available Value selected.  

Step 5 - Use the + sign under Take Action to add an additional Recipient Type to this group and repeat steps 3 and 4.

Step 6 - Name the Recipient Group and Click Save.

NOTE: There is an option to use parenthesis as well as the ‘and/or’ parameters to create more complex conditions within your Recipient Groups.  When using these, test your group after creating it.

Testing Recipient Group

It is very important to test recipient groups as this is the first item to cause an alert or approval from sending.

If you are making a recipient group for multiple people, using the OR clause is the best option. 

The AND clause is best used when creating recipient groups like "User role is staff AND has security for triggered program."

Note: If you list the same user multiple times the approval/alert will only send to the first instance. 

In the below example, Olivia Benson will only receive approvals/alerts in Austin YMCA. If the triggered site is not Austin YMCA the alert/approval will appear lost. 

It is best practice to make a recipient group that is specific to the site/program where you want the approval/alert to generate. 

The below example is a good example for building a "catch-all" recipient group, 

  • First list "User has security for triggered program" allows the alert/approval to start in the right site/program. 

  • Second list all the sites where the specific user might see the approvals/alerts generated using the OR clause.

Best Practices

Recipient groups depend a lot on security.  If an approval/alert didn't send check the following.

  • Does the recipient have access to the TouchPoint that triggered the approval/alert?

  • Does the recipient have access to view the Participant that triggered the approval/alert?

  • Is the recipient accessing the approval/alert from the site/program where the approval/alert was triggered?

  • Are the Alert/Approval security settings and availability set correctly?

Did this answer your question?