I have been making som e approval workflows, but am uncertain of what model to use. Hopefully some of you will contribute with your views of best practices for approval workflows.
My overall scenario is something like this:
1) Somebody creates a list item, and thereby triggers the approval workflow.
2) A task is created for the approver. Since the approver just looks at the mail and lazy-approves, he will not see the actual "live" list item. Therefor it is important, that the item cannot be changed while we are waiting for approval.
3) If the item is rejected, then the person who created the item must now be allowed to make changes to the item, and send it for approval again - again locking the item for updates while we wait for the approver.
4) When the item finally gets approved, it must still be locked for updates - we cannot allow changes, because we would then lose track of what was actually approved.
My dilemma is in regards to the locking down of update-rights. I read a alot of places, how we should avoid setting permissions on list item level, but I cannot see how this can be avoided, and still protecting the item from being updated while we wait for approval and again after approval.
Please share your thoughts :)
Solved! Go to Solution.
Great questions, here are just a couple of foods for thought.
I would stick to Andrew Glasser last but one option ("It is possible to fit item permissions within all of the state changes...") since none of the other option prevents any privileged user to make direct updates to sharepoint list.
just be cautious regarding your pooint "2)" - since an approved has to approve a task on the list item he has to have change permissions on the item.
I have one question, how many times you are assigning the task to approver. If it is (unlimited times) until approved then you can use foreach loop. If its is limited number you can insert no.of level.
Here I am sending just model workflow.
Hello Leif Frederiksen -
All of these suggestions are great and it really all depends on how you want to approach it and what you are comfortable implementing/supporting
Personally I would use a state machine to manage the life-cycle of the item as it is the most straightforward. Here is a high level view of what to do:
Here is a screenshot of the layout:
Hope this helps!
I actually did something kind of like the status field that you suggested. Only I created a timestamp field for EACH of the possible states, and filled in the corresponding field whenever state changed. That way I could see when each of the states were set: Created, Accepted, Rejected etc.
However I am not quite happy with this method of tracking. Is there another way to examine how the "lifecycle" of an item has been, without creating such fields?
I was not aware of the "Request data" action. I have read up on it now, but I don't think it is appropriate for my typical cases which are like this:
1) User creates item.
2) Approver rejects the item - must send signal back to user, that user must "try again".
3) User modifies data thinking "I hope my request for ... can be approved now". New signal to approver that the item must be looked at again for approval/rejection.
4) Step 2 and 3 can cycle until either:
a) User gives up (I am never gonna get approval for this).
b) Approver gives up and approves (She's never gonna stop bugging me for this.)
Step 2: What is the best way to send the signal back to the user? So far I have just used a "Send notification" to the user down in the "Rejected" branch. Would a "Assign to-do task" be a better choice?
Step 3: I begin to see the greatness of the state-machine in this case. If I used the to-do task in Step 2, then I could just change the state to "Waiting for approval" after the completion of the to-do task. Am I Right?
4a) If using the to-do task for step 2, then when the user marked the task as complete, the item would go for approval again. But if the is "giving up" how would she handle the to-do task? What happens if she just deletes the task?
Thank you for your input and detailed explanation.
I am starting to fall in love with the state machine :)
Quick question: The signal back to the user, that changes are needed before the item can be approved, and the signal back to the workflow that the user thinks she has made "sufficial changes" for another go with the approver - could a to-do task somehow help accomplishing this and optimizing your suggested diagram even further?
Wow - this is such a great discussion. I had never imagined that I would get so much highly qualified feedback. Please keep it coming - I am getting new insights from each and every one of your replies :D