We have a custom workflow that has instances that run for months or years. With employees coming in and out of the company, an instance can last longer than the user who created it.

When this happens, the Initiator on the Workflow Status screen will show as Anonymous:

Initiator: Anonymous

The problem is that when the instance advances to the next task in this state, we get the following error:

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object. at Microsoft.SharePoint.Workflow.WorkflowTaskUpdateMailUtil.GenerateEmailBodyForNewTask(SPListItem item, SPUser author) at Microsoft.SharePoint.Workflow.SPWinOETaskService.UpdateTaskInternal(Guid taskId, SPWorkflowTaskProperties properties, Boolean fSetWorkflowFinalize, Boolean fCreating, HybridDictionary specialPermissions) at Microsoft.SharePoint.Workflow.SPWinOETaskService.CreateTaskWithContentTypeInternal(Guid taskId, SPWorkflowTaskProperties properties, Boolean useDefaultContentType, SPContentTypeId ctid, HybridDictionary specialPermissions) at Microsoft.SharePoint.Workflow.SPWinOETaskService.CreateTask(Guid taskId, SPWorkflowTaskProperties properties, HybridDictionary specialPermissions)
--- End of inner exception stack trace --- at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at System.RuntimeType.InvokeMember(String name, BindingFlags bindingFlags, Binder binder, Object target, Object[] providedArgs, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParams) at System.Workflow.Activities.CallExternalMethodActivity.Execute(ActivityExecutionContext executionContext) at System.Workflow.ComponentModel.ActivityExecutor 1.Execute(T activity, ActivityExecutionContext executionContext) at System.Workflow.ComponentModel.ActivityExecutor 1.Execute(Activity activity, ActivityExecutionContext executionContext) at System.Workflow.ComponentModel.ActivityExecutorOperation.Run(IWorkflowCoreRuntime workflowCoreRuntime) at System.Workflow.Runtime.Scheduler.Run()

I have found that this exception is happening because SPWorkflow.AuthorUser is null.

Both SPWorkflow.AuthorUser and SPWorkflow.Author are read-only properties.

How can I programmatically change the author of a workflow instance?

  • Is it necessary to remove users from your site collection when you've removed them from your company? In my experience, people get access via Active Directory or FBA in the first place and so even if someone has Full Access permissions to your site collection, if they don't have an AD account any longer there's no way for Windows to understand their credentials. The only real issue I've ever seen with this is that if you later re-use the same domain/login, you'll have to then delete it (and re-add it) from (to) the SP site collection. Oct 4, 2013 at 0:13
  • I've presented this as an option. But since there are more factors related to user management that need to be considered than just this application, we'll see if they go for it. Thanks. Oct 9, 2013 at 16:31

1 Answer 1


I hate to be the bearer of bad news here, but... the Author field is read-only and is essentially only writable internally when the given list item (workflows reside in a hidden list) is created. Additionally, SharePoint isn't really designed to deal with removing user profiles that are actually being used out of site collections. You can do this via Powershell but, well, there are a number of not-quite-supported things you can do via Powershell.

A couple strategies you could use:

  • Upon termination of an employee, leave their site collection info in the DB but change it to being all but blank (the object is referenced by its domain/login so that would have to stay there but you can remove everything else).
  • Consider creating a workflow which doesn't directly reference the Author field. For example, you could create a field called Requestor whose default value is the Creator but which could be changed at any time.
  • Restart any dead workflow under a new name. This would literally require having to backtrack everything you did up to that point, but perhaps you could incorprate some initiation logic into the workflow which would allow you to bypass / manually enter some of the steps...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.