of the
When it comes to workflow design, one of my least favorite things to see in a workflow is a notification set to go to a specific person. Sure you need it sometimes, but there are some definite downsides. If someone gets promoted or leaves the company, you have to update you customization to change the notification email to send to the replacement. Also, if additional people need to see the notification, you have to add them to the workflow.
One alternate approach that works well is to use an Exchange email distribution list. Create a DL and then add a contact (or some other email enabled entity record) to CRM with the email address of the DL. Then specify the contact in the “To” like of the workflow send email step. Benefits of this approach:
- You can have the notification go to multiple people.
- You can have someone who is not a CRM System Administrator manage the notification recipients.
- You can change the recipients of the notification without having to modify your customization
This is a great tip that I use often whenever I need to send out email notifications to a list of specific users.
There is one thing to consider when you are working with test and production environments. The contact created in each of those environments will have a different GUID so if you ever migrate a solution from test to production that contains this workflow you will have to go into the workflow and reassign the contact so the GUID is valid. Of course restoring your test environment from production will remedy this issue once the contact is in production.
Yes, good point. One way to avoid this is to create the notification contact data in an empty org and then package it up with the Configuration Migration utility that we mentioned in Tip 329. http://crmtipoftheday.com/2015/02/23/resolve-missing-record-dependencies/
then you can import those notification contacts into subsequent organizations, preserving the GUIDS and your workflows will resolve correctly.