Where you are getting the error, exactly after which step? The below might be helpful which happened in my requirements.
But after task has been approved, do you have any Update any column information of document library? Or is your workflow just ends after the approval task? If so workflow might be trying to update the default workflow column option with a status Completed, and which can't be done without check out.
could you share how exactly you implemented validation?
Hi again Marian,
The Review Task assignees are set as variables at the start form. I have it set up for three reviewers max, each with an individual review task running parallel to control permissions uniquely for each user as tasks are completed. (as soon as one reviewer is complete, their increased permission level is clawed back but the others remain open until they are done)
For validation, on the task form's "OK" button (set to "continue" decision), the control is invalidated if "Document Checked Out User"="the user in that task's reviewer variable"
This is would be to ensure they check it back in before their permissions are revoked but if it is checked out to someone else it is validates fine.
SB
I will also add the even with the default Nintex form this error occurs. It seems I cannot submit a task form on a checked in item when check-in/check-out is set to required in the library using a Nintex form. It does work with the same workflow using the default Sharepoint form. The Nintex start form work just fine.
Anyone else see this?
from what I understood I tried to reproduce your scenario, however, I was able to respond the task regardless of whether I used SP standard form or nintex form and regardless of document check in/out status or who had the document checked out. library setting ' Require documents to be checked out before they can be edited' was to yes.
since was not sure what you mean with 'Task review' (there is no such workflow action) I tried it with 'Request review' and 'Assign flexi task' action. both could respond the task.
can you provide more details what your workflow is exactly doing?
what are the circumstances you get the error? - I mean who is workflow initiator, who is task assignee, who has document checked in/out, etc.
do you experience the same problem with just one approver (no parallel approvals)?
Hi again,
It is indeed the "Request Review Action"
Versioning is set to 'Require documents to be checked out before they can be edited'
I have now created a one action workflow with the "Request Review Action" and the default Nintex form.
I even ran this with a freshly created a barebones library with the basic "document" content type and still get this issue.
Scenario 1.
I am the workflow initiator, I am the Task assignee.
Document was checked in to start workflow. Document is never checked out during the workflow. I get the error when I respond to the Task.
Scenario 2.
Same as above except another user with contribute access to the library and workflow task list is the assignee.
Same error in both scenarios. If I change 'Require documents to be checked out before they can be edited' setting in versioning to no, then it goes through fine. It also works if I check out the document and then respond.
I am running 3.0.8.0 so maybe there is a difference there which is why it is working for you. Perhaps there is a setting somewhere either Sharepoint or Nintex that I, as more of an end user, do not have access to.
This is the first time I have tried using a Nintex form for a task. Ironically the reason I wanted to use it (to ensured documents are checked in) is the reason it is not working.
I do appreciate you trying this out.
Soni,
My original reply to you isn't there, or maybe it didn't save. I tried your suggestion of disabling the status column and even custom history messages and still run into the issues.
Thanks for the suggestion though. That seemed like a very logical reason that it might not be working .
I've tried both your scenarios, both with standard and nintex form, but can not reproduce the error.
I'm not sure what might be different with your setup.
Thanks for trying Marian. I guess for now though not ideal I will just use the workflow to ensure it is checked-in and kick it back to the user there. Just curious though what version you are running?
Thanks again.
SB
Hi Marian Hatala, Soni Reddy,
So, I recently was able to get this issue solved (for me at least). I had to revisit this and although by no means scientific or totally exhaustive, here is what I noticed/did.
Assuming, the default Nintex task form properties controls are the same as the input controls, although they are disabled they seem to be submitting the data back causing my issue of it needing to be checked out. I have run into this before and seen it mentioned in other posts.
Previously, I deleted all of the item properties controls (leaving the labels) figuring nothing would be submitted if there were no property controls on the form at all. This still did not solve the issue, and I was still getting the error requiring it to be checked out. In a moment of clarity I noticed that the default Nintex task form also had layouts for smartphone, mobile, tablet. etc. and that they were linked to the original item property controls on the Desktop Layout. (I have only ever been concerned with and or manipulated the Desktop layouts so I never really paid much attention to the other layouts)
After deleting the property controls on the Desktop Layout, I deleted all of the other layouts except for Desktop, and now the form would work with the document checked in.
I reloaded the default form, left all the layouts but deleted the item property controls from ALL of the layouts and it worked with document checked in.
I left all of the layouts and deleted all of the item property controls except for just one on the smartphone layout, and back came the error.
So... although I was using the Desktop Layout, and had deleted the property controls (and even labels) on that layout, the item property controls on the other layout seem to be what was giving me grief. Perhapss some relationship remained to the controls on the other layouts even though they were deleted on the layout being used. In the end, I deleted the layouts I don't need, deleted all of the item property controls and replaced them with labels/reference data. I am happy I can get this to work, and get this info in my tool chest. But, is this the expected behavior? I would still consider myself a novice on this but it does seem a little counter-intuitive. Any thoughts?