I recently ran into a situation where the fulfiller on a certain set of incidents needs to send emails to differing recipient groups so that all of the correspondence stays with the incident. For these purposes, Additional Comments or similar will not work.
The challenges for this were:
- Needing for the appropriate email client template to open
- Defining the various templates based on specific criteria
- Making sure that the criteria are set before a template is opened
- Setting up the UI Actions (form buttons)
The obvious first step is to get the templates built. The online documentation is quite good once you know that the menu option for the templates is under System Policy as opposed to where the documentation points. You can get very specific on the criteria for a given template. In the "easy" case where the criteria are based on something like Assignment Group things work pretty easily. In my case, it wasn't that simple. There was no obvious value onscreen that I could use to differentiate. The answer I came up with was to add an additional checkbox to the form and a UI Policy that keeps it hidden.
One thing to keep in mind is that the criteria for evaluating which template to use come from the onscreen form and not the database.
With the templates defined, I set out to build the UI Actions. After some searching in the community and a bunch of trial and error I came up with the following:
The only things to remember about this set up are:
- Check Client
- Set Onclick to name the primary function in the script
I don't care what value is stored in u_communicate_to_colleague since the UI Actions will set it appropriately.
This worked as needed until I cloned it for the other option. After changing the script so that the value is set to false, I clicked on the buttons and nothing happened! It turns out that starting with New York, the Onclick function names must be unique. It's not clear to what level that uniqueness applies. Once I changed the Onclick and corresponding function in the cloned script to anything else, everything works exactly as needed.
The end result is a clean and simple interface that makes it very easy for the fulfiller to create the emails. When I first showed the setup to my fulfiller counterpart, the reaction was "that's so cool and easy".
In my case, I was able to do what I needed with a simple checkbox. Obviously, there are many ways to extend the concept with more check boxes or using a string that can hold any value needed.
I hope that the above helps you avoid a couple of annoying "gotchas" and speeds up your development.
Thanks to Jeff Blodgett at Cognizant for his help on this.
