This content has been marked as final. Show 16 replies
I actually created exactly what you described:
- Every time a Team gets create a Contact Group gets created too
- Every time someone is added/removed from the Team they get added/removed from the contact group
- The contact group listing gets transferred to the Service Request/Incident into a field called TeamMailList
- The notifications use the "TeamMailList" field as a TO:
Works fine for me.
Said that... Now that you expose your way of thinking.... not sure if you really need the "Contact Group", you probably can bypass it and remove one layer of difficulty... But, I wanted to let you know that it is achievable, and if you are interested I can relate to you how I did it.
6 of 6 people found this helpful
We have implemented another approach:
- The "TeamEmail" field of the "StandardUserTeam" is recalculated (using a similar expression) via a workflow every time a member is linked or unlinked from the team.
- Then we can use the HEAT standard functionality of the "Address Book" (using the tab "Contacts related to ...") to select the "Team Email" as recipient of an email.
This avoids storing the recipient list in every incident (or other object). Moreover, if a member is added or removed from a standard user team, this is automatically reflected in the recipient list.
I am hating you so much right now!!
That sounds like a great approach, easier and more maintainable that what I did
It goes straight to my bookmarks to be implemented the next occasion I have a bit of time!
Thank you very much Andreas.
could you please provide us your "similar expression"?
I tried to configure a "Triggered Action", which should update the TeamEmail field on Link of an employee. But i got some errors.
Thanks for your help
5 of 5 people found this helpful
We use the following expression which only considers members with an employee status of "Active":
"if Status == 'Active' then PrimaryEmail + ';' else ''",
Note that calling this expression from within a triggered action will not produce the desired result because the triggered action seems to be executed before an employee record is really linked or unlinked, i.e. if called from within a triggered action the resulting recipient list does not include a newly linked employee or still includes an unlinked employee.
Therefore, we have defined a boolean field within the "Standard User Team", e.g. called "Recalculate", which is just set to 'true' by two triggered actions (one triggered if an employee is linked, the other if an employee is unlinked). The change of the value of this field to 'true then triggers a simple workflow which just updates the "TeamEmail" field using the expression above and resets the trigger field back to 'false'
You sir, are a saint
You can call direct form the Triggered relationship action without the workflow the problem I expect you are seeing is this
The data saves but is in red, this is because the field has an annotation attached for email address so it is testing the email address format which is going to be wrong for anymore than a single address. Remove the annotation.
Also you need to change the field control from a type of Email to a type of Read Only Text as we want the system to manage it.
Now you can just use the relationship and no workflows so the change is instant.
update: you will need to triggered actions one for a dding and one for removing.
1 of 1 people found this helpful
If you remove the "Email Adress" field annotation, then this field is not listed anymore in the "Contact related to ..." tab of the address book. It is sufficient to change the control type of the field on any form from Email to 'Text Field' or 'Read-only Text' in order to fix the "red display problem".
Thank you I hadn't noticed that
I have created two identical Triggered Actions (copy and past the function) which overwrite the existing list of addresses I'm storing in Team Email as suggested by AlasdairRobertson
The action triggered by Link updates the the list of emails in TeamEmail flawlessly
The action triggered by Unlink does not remove the address from the list. This is likely the issue mentioned by lgtandi
Linking another member at this time would add that address and remove the previous one.
I'm wondering if there is a way to delay that save until the Unlink was detectable. Suggestions?
As a fallback, I am considering trying it as Before Save Action. Maybe having to force a second save to recognize the Unlink.
Not as efficient, but low overhead task (unless very large teams) and StandardUserTeams should not be something that is altered too often
I now use a workflow for this, upon link/unlink I set a flag on the team record then I have a workflow set to be triggered by that flag that runs the ForEachChild statement to generate the email string. This removes issues just trying to use the Business Rules capability.
Use a Triggered Action to set the flag on both Link and Unlink?
Then test that flag to launch the workflow?
Yes add a field for example AR_CalcEmailAddress as a boolean. this gets set when an new team member is linked to a team (use a business rule with the relationship on link). Then your workflow runs and the last action in your workflow is tp update the StandardUserTeam object and set AR_CalcEmailAddress to false to it is ready for next time.
What about using a Calculation Rule to update the address list since it can be set to update after save? Is there a high overhead on this?
When specifically does Also Recalculate On Load process? Only when editing the Team or is it something more obscure like when TeamEmail is selected anywhere and in quick actions?