I have a workflow that includes a "set permission" action which changes the permission of the person who filled out a form. The username is picked up from the "Created By" field. I use this system generated field rather than a people picker field on the form, because it guarantees that it's the same user which submitted the form.
There's a scenario where the following occurs:
1. An employee fills out the form
2. The employee leaves the company
3. The AD account is deleted
4. The workflow reaches the "set permission" after point 3 above
5. The workflow tries to set permission on an AD user that does not exist, so it errors out.
Is this a bug in Nintex workflows or is that normal behaviour for it? I've tried this on Workflows 2013 and Workflows 2007 with the same issue.
Shouldn't the set permissions task skip an AD user account if it can't resolve it?
I've been advised that:
a. I must use the "Created By" field
b. The AD accounts on ex-employees must be deleted.
Any help would be most appreciated. Thanks.
Solved! Go to Solution.
First, in relation to the "AD accounts on ex-employees must be deleted", I've had this argument with AD administrators before and in the end everybody agreed that disabling the accounts rather than deleting them was a must better option for a range of reasons outside of SharePoint, like having orphaned SIDs in your file system permissions, but then there may be reasons why they "must" be deleted. I'm not an AD expert so I'll leave that up to you.
In your case, it might work if you have the "set permission" action in a separate workflow (which DOESN'T start on creation or editing), and is started using the "Start Workflow" action.
I would say this is rather sharepoint 'feature' then nintex one. you neither can manually update/change permissions for an account that can not be resolved against AD.
if it's a real issue for you use LDAP query action to check existence of an account first and just then decide how to set item permission (it's good chance to make a clean and remove the account from access list)
Yes i agree with Marian. You can use LDAP query action to check if user exist [ may be in loop for all users] and then assign permisisons.
I have also faced similar situation and another oberservation in this is, if user is added to site then you will able to search the user in SharePoint using profile picker [as its been cached in the site collection].
We had the same issue, so we worked with corporate security to place the former employee to Disabled for 3 months and then delete them on 4 given dates in the year (and 2/29/YYYY is not one of those dates ). We added the LDAP check in the workflow prior to the permission check so it could skip the permission check if user did not exist. Since it was an Approver workflow, we instructed all the managers that they had to respond to the approve/reject notification within 10 working days (so a week vacation would be ok) to ensure that the workflows would complete while the person was disabled.
AD deletion is used to keep the AD from getting to large in high turnover situations and is required by the FDA in certain situations for the Food and Drug industries. The above method meets those requirements and satisfied the FDA, the NSA also have security requirements for the Food and Drug industries that must be met.
Thanks Marian and for everyone's feedback.
We ended up temporarily using another field rather than the Created By field. The LDAP check will be the permanent solution as you recommended.