Hi all, I've seen few enough instances where my workflow doesn't start automatically when created. The workflow runs on a list where item level permissions are being set the first thing on the workflow. When the workflow fails to start immediately, this means to us that some users are able to see what they shouldn't be seeing which is a security issue. IT doesn't get notified unless a user comes and reports that they can see something on their list that they shouldn't .
Can someone please advice what can be done on SharePoint or Nintex to guarantee that the workflow will eventually start! even if it takes 3-5 minutes, that's fine.. but not whole hours when someone else is able to see secure data.
what makes Nintex or SharePoint unable to start a workflow? I'm using Nintex 2010 on prem.
Thanks! your input is appreciated.
Solved! Go to Solution.
The workflow sometimes doesn't start automatically esp. with conditional start.
But I have suggestion for your scenario, Instead giving view permission to everyone when it creates. Do the setting in the list so that only the contributor can see when the record is created. Later you can assign permission to others if needed using the workflow.
Thanks for your reply Sojan Mathew.
I actually have this setting setup on my list, where the users should be able to only view and edit their own items. However, because the list requires approval, the minimum permission level required to be able to do so is designer level (when this setting is setup). I've tried so many levels such as approvers, contributors and the adjusted the permission levels in sharepoint, nothing seemed to fix the issue except the "Designers" level; if it is not deisgners, my users used to get an access denied message ... So I let it be and made the workflow do the permissions upon creation. But because designers is superior on contributors, those SharePoint settings mean nothing to it. Designers is like users have full control on all items upon creation. in other words, the below settings only work when the users have "Contribute" permissions. If they got full control or designers, they will be able to see everything.
On a side note: I've honestly tried to run away from Item level permissions in SharePoint but it is an expense claims form where different types of access for each line is a requirement. The person's permissions change from one stage to another, finance don't approve but they need to see it all and managers need to track only their team's... so it won't be an easy fix with the option to see only their personal claims. I honestly not sure why SharePoint demands to give users designer permissions to start with in order to be able to approve their assigned items. or may be I'm missing something.
Speaking of which. I will retry to give the users contribute only on the list and see if that solves it. may be I missed something the first time I tried.
I think you should use flexi task to get the approval. It seems you are giving access to the item to do the changes for approves.
Use flexi task approval and the approves needs only view permission on the item. The workflow manage the item to update based on their approval status.
hmm.. I am using flexi task for approval And even the flexi task form is modified to look exactly as the original form, some approvers need to do modifications to the item before passing it to the next step, so it was needed to give them a minimum of contribute permission. Anyhow, I've changed the initial permissions to contribute until the workflow starts and I didn't hear screaming this morning...yet Thanks for your help Sojan ..
update: I found out (the hard way) that the list advanced settings of the screenshots above override whatever is given through the workflow. So if one user is given full control on a list item (that is not created by him/her) and on the list settings they can only read their own items, then the user will not have access to the list item to view or approve.
I heard the screaming the next day when the users started reporting that they couldn't view the claims assigned to them for approval and get access denied (web part maintenance page ..."sharepoint typical misleading message".. ) so I had to revert to the original settings which is read all and add/contribute to all. Then the workflow is the one to do the magic. We'll just have to live with the fact that sometimes the workflow won't start and will have a brief security breach till somebody notices it and starts the workflow manually ... Unfortunate but that's all we could do right now given how sharepoint deals with the permissions overriding in this case.
Has anyone found an issue for the original issue?
We have several workflows on a list with conditional start (some created, some modified, etc.), and at some point some workflows STOP starting.
How do we fix this ??
I was having issues with many workflows on a list. Sometimes it works and sometimes doesn't. I fixed this issue by redesigning the workflow. I designed it in way that only one workflow is active, this will be the main workflow that controls other workflows. This main workflow runs on creation and modification. We need to call other workflows based on different conditions that we need. It will be like calling a function from the main execution control. Triggering multiple workflows on a same item at the same time is not good idea.
Hope this helps.
thanks for your reply. this is smart, I had considered theapproach (master workflow which launches all others)
I removed the conditions for one of my workflows and republished the important one which fixed the issue.
I also found a link to remove the nintek workflow XML file for the list but have not tried that.
Nintek should either remove the functionality or fix the bug...