Nintex Workflow – Declarative workflows and the System Account
You may have encountered some “Workflow Infrastructure” messages in your SharePoint logs that state :
“Declarative workflows cannot automatically start if the triggering action was performed by System Account”.
There are two possibilities for this that come to mind.
- You are logged in as a System Account and you caused an event that would normally result in a workflow automatically starting.
- Something else is using the System Account credentials or context and it caused the event that would normally start a workflow.
Firstly, you should know that SharePoint will not automatically start a workflow if the initiating account is the System Account. If you take anything away from this post, that is a biggie!!
What actually drew my attention today, was a situation where I have many workflows that can potentially run in my environment and one of them must have caused an event that resulted in the above error.
So the challenge is, how do I find which workflow caused this?
The reason I need to find this, is because I need to make sure that this workflow is in fact logically sound. It could make sense that this workflow does need to update the item as a System Account, because I don’t want different workflow instances to kick off as a result of this update. But I won’t know for sure until I know exactly which workflow caused this. Once I find it, I can document it for future generations of Workflow Designers.
Where to look?
Unfortunately, I’m not seeing much information in the SharePoint logs to tell me what workflow caused this error message.
My big assumption here is that it is a Nintex Workflow, since I use Nintex Workflow to design all my workflows in this particular environment.
The SharePoint log entry does give us one important piece of information :
10/11/2013 21:47:40.693 w3wp.exe (0x10A90) 0x21C90 SharePoint Foundation Workflow Infrastructure b9vu Unexpected Declarative workflows cannot automatically start if the triggering action was performed by System Account.
The date/time, highlighted above was when this occurred. With this little nugget of information, we can now go to the Nintex Workflow database and find every workflow instance that was running at that time.
Building the query
SQL expected a date/time format slightly different to the one in the SharePoint logs.
10/11/2013 21:47:40.693 actually becomes 2012-10-11 21:47:40.693
Now to the ugly SQL Query:
SELECT tblResult.InstanceID, tblResult.WorkflowName
FROM
(
SELECT DISTINCT WI.InstanceID, WI.WorkflowName, MIN(WP.TimeStamp) as ‘StartWork’, MAX(WP.TimeStamp) as ‘EndWork’
FROM WorkflowInstance WI
INNER JOIN WorkflowProgress WP
ON WI.InstanceID=WP.InstanceID
GROUP BY WI.InstanceID, WI.WorkflowName
) as tblResult
WHERE tblResult.StartWork <= ‘2012-10-11 21:47:40.693’ AND
tblResult.EndWork >= ‘2012-10-11 21:47:40.693’
Conclusion
What this query will do if give you the name of the Workflows that were running at the same time this error message occurred. Since you could have multiple workflow running, it will at least narrow down the list of culprits.
If you wanted to, you could add SiteID, ListID, ItemID and really narrow down the information on which workflow, what site, list and item it ran on.
When I run my query, I get the following:
As you can see in the screenshot above, I received 2 results. Both of these workflows were running at the time of my error message and now I can look at the design of those to figure out what is going on.
There are other scenarios that could cause the error in the logs. But this query will tell whether a Nintex Workflow was running at the time. If it was, you have somewhere to look. If there wasn’t, then it something else, like a user logged in as the System Account or a piece code calling the Lists.asmx web service as the system account and performing an UpdateListItems or possibly something I can’t think of at this point. But it’s a start.
