I think I answered the second question on my own, "how else might we get a user's manager?" Here's how I did it, in case anyone else is interested, or can recommend a better way to do it.
First, I created a Group for the managers, as a prerequisite step. All of the managers for all of the departments are made members of this group. While I did this manually, I can imagine it would be easy to set up an Identity Policy to automatically populate that group in the future, by triggering off the Title attribute. I also tested it using Access Roles and Admin Roles, which were created previously for other tasks.
The "trick" is to use the group/role members list to identify all of the managers, and use the System/List Iterator function of Custom Data Elements to step through each one of them, capturing their email addresses in another CDE. A Comparator CDE is then used to evaluate the user's department string against the manager's department string. Finally, an Entry Rule tests for the value returned by the Comparator CDE, proceeding with the email policy only when it returns "EQUALS" (the user's dept matches the manager's dept). The email policy use's the captured manager email CDE as the Recipient TO value.
Custom Data Elements
| Data Name | Category | Type | Sub type |
|---|
| User Name | Tasks and Events | Event Information | Subject Name |
| User Dept | Attributes | Attribute of a Specific User | Get |
| Dept Managers | Groups | Group Members List | Get Members' User IDs |
| Manager Name | System | List Iterator | Next Value |
| Manager Dept | Attributes | Attribute of a Specific User | Get |
| Manager Email | Attributes | Attribute of a Specific User | Get |
| Match Dept | Comparators | Comparator | Compare Strings |
Data Element: Dept Managers
Name: Dept Managers
Category: Groups
Type: Group Members List
Function: Get Members' User IDs
Group Name: Department Managers Group
Data Element: Manager Name
Name: Manager Name
Category: System
Type: List Iterator
Function: Next Value
Value or List: {'Dept Managers'}
Data Element: Match Dept
Name: Match Dept
Category: Comparators
Type: Comparators
Function: Compare Strings
First String: {'User Dept'}
Second String: {'Manager Dept'}
Email Entry Rules
Match Dept Equals "EQUALS"
My only concern is that this approach may be "expensive", as the CDE System/List Iterator function restarts the entire policy for each item in the list provided. Our environment has 15 departments, so the policy executes 15 times. The email itself is generated only when the Entry Rule matches, so it's not sending 15 emails -- it sends only 1 per match (assuming that there's a one-to-one relationship between manager and department).
What do you think? I welcome your feedback. Thanks!