Symptoms
Object reference not set to an instance of an object
Diagnoses
We're hitting the beloved "Object reference not set to an instance of an object" in all instances of a workflow at a SmartObject step.
K2 log:
"1966325","2015-03-19 13:57:21","Error","General","28083","ExtenderExecuteError","ProcessInstance.HandleException","28083 ServerEvent: Message: Server was unable to process request. ---andgt Object reference not set to an instance of an object. ServiceName: Workflow ServiceGuid: c8323cfd-73bb-4157-be5f-c9d908fbafbd InnerExceptionMessage:
InnerException: Message: Server was unable to process request. ---andgt Object reference not set to an instance of an object. ServiceName: Workflow ServiceGuid: c8323cfd-73bb-4157-be5f-c9d908fbafbd InnerExceptionMessage:
","","","K2APP01:C:Program Files (x86)K2 blackpearlHost ServerBin","1966325","97a73e23d4d74a7186ca516d8ca5fb25",""
So firstly I ran the SmartObject in the tester and it works fine. I then confirmed the service instance GUID matched the one in the log and it does. This is the first time this particular workflow has been run since we migrated to SP2013. We have other workflows that use SmartObjects with SharePoint lists and they work fine, not sure why this one is giving an error. One thing I did notice is that the service name in the log is "Workflow" but the actual name is "WorkflowCentral". When I look at a SmartObject that works I see the name of "WorkflowCentral". Would this matter or be the possible cause? Is it possible to change that reference in the SmartObjects that don't work, rather than renaming the ServiceInstance? Because some work so changing would cause them to break then.
We discovered that the execution of this Smartobject was successful with the user's account but throws the same error in the Smartobject Service Tester tool when executing with the K2 Service account (as the Smartobject call from within the process instance will be made with the K2 Service account).
Resolution
We determined that permission inheritance was broken on this list, such that the user's account had Full Control access but the K2 Service account did not. Giving the K2 Service account same level of permission (Full Control) on this list resolved the issue.
