Send Email through Visual Studio Workflow in SharePoint 2013

EmailActionWhen building a custom SharePoint 2013 Workflow using Visual Studio I ran into a very odd problem trying to send a notification email to a group of users using the Email action (specifically Microsoft.SharePoint.DesignTime.Activities.Email). 

I could send email from a SharePoint 2013 workflow created using SharePoint Designer, but could not do the same from my custom workflow created in Visual Studio without the workflow throwing an error.  I’m not even going to post the error because as it turns out it’s a generic error message that could show up for any number of reasons and has little to nothing to do with the problem which was partially why it took so long to solve.

My colleague Bob German (Blog ~ twitter: @Bob1German ) gave me an assist debugging and testing out the issue… By using Fiddler, set up to run on my SharePoint server under the Workflow Manager App Pool account, I was able to see why the call works from a SharePoint Designer workflow but not my custom VS2013 workflow. What I found was that when the call was made from the SharePoint Designer workflow, the “To” address was in the form of the users login name and not the email address.  So even though the documentation states that the “To” property “Gets or sets the user names or email addresses that represent the recipients of the email message.”, that is apparently not entirely the case.  By tweaking the value I pulled from the LookupSPUser activity from Email to LoginName and adding that value to the recipient’s collection, everything worked beautifully.

LoginName

As an aside, from this same Fiddler investigation, I also found that the SharePoint Designer email action formats the body as an HTML message and if you want to use that you can by embedding your body in between the following tags:

<HTML><HEAD> <META name=GENERATOR content=\"MSHTML 11.00.9600.17924\"></HEAD><BODY><FONT face=\"Segoe UI\">

<Email Body Here>

</FONT></BODY></HTML>

Future Proof – Javascript Dashboard Code Samples

To support my colleague Bob German and his great talk on Future Proofing your SharePoint solutions I helped him by building a SharePoint charting dashboard that used client side scripting libraries to pull data from a SharePoint list and display it using commercially available client side charting library.  He has asked me to share those solutions and so finally here they are.  I really appreciate all of Bob's great feedback and hope these examples can help people out there get started on building their own dashboards.

ScreenShot_2010

For all the great information, please see Bob's article that talks about Future Proofing your apps at http://blogs.msdn.com/b/bobgerman/archive/2013/10/05/future-proof-solutions-part-1-take-a-walk-on-the-client-side.aspx

Javascript Dashboard Demo

More Future Proof Code Samples from Bob German

Quick Primer on InfoPath and SharePoint 2010 Time Zones

InfoPath functions such as Today() and Now() pick up the time zone based on the settings of the SharePoint server.  By default the web is set to the time zone of the server, which is thereby the default of any new sites created as well as new user profiles created.  For global organizations with users around the world, there are situations where you will want the automated date/time stamps to display the local time for the user rather than the server time.  This article will show you how to set that up.

The time zone of the web can be changed in central administration.  The time zone of the site can be changed by going to site settings / regional settings.  In addition a user can change their personal time zone settings by going to “my settings / my regional settings”. 

The InfoPath form I created to test the scenario has 2 fields.  The first is set by default using the now() function when the form is created, the second is set by an action on form load, again using the now() function.  The first field is also used to name the form when it’s first submitted.  Using the magic of VMs, I set the time zone of the host machine and the site settings to be Hawaii time zone (GMT-10).  I then have a separate test user whose regional settings I set to Pacific (GMT-8) and am using the browser on a machine whose time zone is set to EST (GMT-5).

On the machine whose time zone is set to Hawaii, I created an instance of the InfoPath form.  Note that not only are the two fields set to the current Hawaii time but also the Created and Modified dates show as Hawaii time (Figure 1).

  Image5

Figure 1: Form in Hawaii time zone from machine in Hawaii time zone.

If I log into SharePoint as the same user but from the host machine whose time zone is set to EST I still see the exact same results.  Note the machine’s time is 12:35. (Figure 2)

  Image6

Figure 2: Form in Hawaii time zone from machine in Eastern time zone

Now, by logging into SharePoint as the user who changed the regional settings to Pacific time, I see something very different (Figure 3).  Note that the Created and Modified dates in the SharePoint list are adjusted to my regional settings which are Pacific time zone.  And when I open the form the refresh date time uses the now() function which uses my regional time zone setting to set that date/time.

  Image7

Figure 3: Form in Hawaii time zone from machine in Eastern time zone as user in Pacific time zone.

Conclusion

If you need all the date/time stamps to appear the same regardless of the user’s location, then either override or leave the default regional settings for your web and make sure the users do not change the regional settings of the web.  If the users want to see the information converted to their own time zone, they should change their regional settings to their own time zone.