SharePoint 2013 Quick Tips: Workflow And The User Profile Service

I ran into a real annoying scenario where I couldn't use Visual Studio 2012 to build SharePoint 2013 Workflows. Creating the workflow and right-click-deploying its WSP to my local farm worked fine. So I hooked it up to the root web's Pages library of the associated site collection, created a new page, and kicked off an instance of the workflow. When it was done, its status was "Canceled." Here's why:

Jesus. This is basically a lot screaming about a 401. But how could it be a 401? I'm in my local development site, which means I'm the domain administrator logged in via Windows auth. I'm the only user in the farm; how could I ever be denied access? Well, because just like with the app model permissions, the User Profile Service is the default identity provider for SharePoint 2013. You can read more about that here.

The point is that we need a User Profile Service to exist, and within it, a profile for whichever user is performing these actions (weather it's kicking off a workflow or the impersonation context for an app). The research I did to get me this far also elucidated me to that face that in addition to standing up a User Profile Service, I also need to have executed a successful profile synchronization therein. But since I'm running SharePoint 2013 on a domain controller in my local development environment, the sync won't work; the User Profile Synchronization Service simply refuses start under this configuration.

Well, after much consternation, the quick tip here is that you do not need to have a synchronization complete successfully (or even configured) to get workflows to flow work on SharePoint 2013 development machines. Just create profiles for your service accounts, and make sure that the User Profile Service is associated with the "default" Application Proxy Group. Since I was provisioning my service apps via PowerShell, I had omitted the DefaultProxyGroup switch that associates the service app's proxy with this group.

This was the missing piece of the puzzle. Once I fixed this in central admin (and updated my PowerShell scripts) everything began to work. Hopefully your service applications are provisioned correctly on your dev box so you don't have to deal with this. My main point, however, is that people shouldn't be discouraged from building local SharePoint 2013 workflows in Visual Studio 2012 because of something that's advertised as not being supported - when in reality, it's not even needed.