cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Nintex Newbie

Workflow: Approval best practice

Jump to solution

Hi,

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 :)

Regards

Leif

Labels: (2)
Reply
23 Replies
Highlighted
Automation Master
Automation Master

Re: Workflow: Approval best practice

Jump to solution

Great questions, here are just a couple of foods for thought.

  • You can use a unique status field on the item to track the current approval of the item. This field can be set as read only on all forms as to not be manually updated, but only workflow updated.
  • You can use the status field to keep the entire form read only using form rules based on the set status. So while the status is "under review", the entire form is read only. But when "rejected", then it is editable. This provides a sense of item permissions without the actual permission setting.
  • Use a state machine to control the status. Before the state machine starts, set to under review and create the task. If the task outcome is rejected, then update the status AND send the state machine to an Initiator State, if approved, then update the status to approved. In the Initiator state, the initiator will be given a task to update the item. When complete, the status changes and the state changes to be reviewed again.
  • It is possible to fit item permissions within all of the state changes, but use Commit Pending Changes, or pauses to make sure the permission setting is in place.
  • In the email to the approver, provide as much detail as you can in the notification about the item using the item property references
Reply
Highlighted
Automation Master
Automation Master

Re: Workflow: Approval best practice

Jump to solution

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.

Reply
Highlighted
Nintex Newbie

Re: Workflow: Approval best practice

Jump to solution

Hi,

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.

Reply
Highlighted
Nintex Employee
Nintex Employee

Re: Workflow: Approval best practice

Jump to solution

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:

  • User create the item in the list
  • List workflow kicks off
  • Enters a state machine in the "Waiting for Approval" state
  • Remove all permissions except for "Approver"
  • Assign a task to "Approver"
  • Based on outcome, move to new state
    • Rejected - move to "Changes Required" state
      • Remove current permissions and add back in Created By
      • Wait for item to be updated
      • Once updated go back to "Waiting for Approval" state
    • Approved
      • Remove current permissions and add in required permissions
      • end state machine
      • end workflow

Here is a screenshot of the layout:

Hope this helps!

Reply
Highlighted
Nintex Newbie

Re: Workflow: Approval best practice

Jump to solution

Hi Andrew,

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?

Regards

Leif

Reply
Highlighted
Nintex Newbie

Re: Workflow: Approval best practice

Jump to solution

Hi Marian,

I run all my workflows with elevated privileges - does your second point still apply in that case?

Regards

Leif

Reply
Highlighted
Nintex Newbie

Re: Workflow: Approval best practice

Jump to solution

Hi Ramana,

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.)

Questions:

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?

Regards

Leif

Reply
Highlighted
Nintex Newbie

Re: Workflow: Approval best practice

Jump to solution

Hi Jesse,

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?

Regards

Leif

Reply
Highlighted
Nintex Newbie

Re: Workflow: Approval best practice

Jump to solution

Hi everybody,

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

Regards

Leif

View solution in original post

Reply