I have been working with SharePoint for almost 8 years, but I am still amazed at two things. One, even though I have largely confined my work to SharePoint Designer workflows and the odd edit of some of the code behind a Data View Web Part, there are gotchas that I haven’t yet encountered. Two, most of those have to do with permissions.
A few weeks ago I wrote about the fact that I like to divide things up into little self-sufficient chunks when I develop a SharePoint solution. Since that is my preference, it comes as no surprise that when I started helping
the young woman (OK, she says that I can call her Stacy, so) Stacy develop our Step Tracking application, that I would encourage her to divide and conquer, too.
This was working very well. It was working for all the reasons I mentioned in that post and the reason I added two weeks ago and it’s a great way to support learning. It helps to have a good student, too, but I have that covered. Developing things in tiny bits makes it easy to keep the whole bit in your head, to stay focused on the single objective. I love working this way – until it doesn’t work.
One of the last bits of step processing we had to add was to allow people the ability to email their step count into the system. So, after a long walk, I can take out my iPhone and mail my step count to MySteps@ourDomain.com. I explained how email-enabled libraries worked and I explained how we could use Regular Expressions to make sure that the email Subject included a date and a separate integer number. Actually, we just remove the date from a variable so everyone doesn’t always get credit for 2014 steps. I did the explaining over Lync while she did the work at her desk – technology at its best.
The really cool thing was when we discussed the fact that all she had to do to “process” the inbound steps was to add them to the Step list. The workflow that she had already written in that list would take it from there and add it to the appropriate Team count. Well, actually, it was a little more complicated than that. The email processing part has two workflows.
One verifies that the step entry is properly formatted. If not, it creates an error task and the task list notifies the sender. If the email is valid, the first workflow updates a couple of fields and adds a little data. Now that the list item has been updated, a second workflow enters the steps. This way, it would be easier for the Wellness Administrator to correct the item and have the steps counted. It was also a good way to point out how workflows can start when an item is new and when an item is updated. It was also a great way to break a Microsoft rule.
SharePoint will not start declarative workflows on items created by the System account
Since the new item in the Steps list will have been created by the System account, the workflow that processes the steps to the Team count will never run.
You can read more about that here, but the best I can figure out is that it’s a security thing. We could have worked around it by switching to Nintex workflows (which we now own) but that would mean starting over – and it’s unnecessary. Microsoft put a barrier in place, but they also provided a way around it, impersonation. By putting the workflow tasks into an Impersonation Step, the tasks are run as the person who created the workflow, i.e. Stacy. Since Stacy has the permissions to run that step, it’s all good.
Frustrating problem, easy fix and an extended learning opportunity. Since I always look for the bright side in a situation, I’m walking away from this happy. Next up for this project will be to play with the Lightening Conductor Web Part to make some pretty widgets. Stay tuned.