Workflow: Approval best practice

L
Badge +7

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

20 replies

A
Userlevel 7
Badge +17

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
E
Userlevel 5
Badge +14

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.

R
Badge +3

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.

180933_pastedImage_0.png

jesse_mchargue
Userlevel 6
Badge +12

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 happy.png

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:

181071_pastedImage_10.png

Hope this helps!

L
Badge +7

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

L
Badge +7

Hi Marian,

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

Regards

Leif

L
Badge +7

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

L
Badge +7

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

L
Badge +7

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

E
Userlevel 5
Badge +14

yes, with to-do task you can afford that.

but it's just one of several options. depends on your specific needs you can use (as well):

- flexi task (the most common, the most "flexi"-ble)

- request review

- request data

- request approval

each of them have its pros & cons, and is suited for different use cases

A
Userlevel 7
Badge +17

If it is important to track the changes, such as when the state changed, I typically create a tracking list just for this purpose. I also put in task data, such as when and who responded. This has been a great help for auditing processes that are a year old. Especially when SharePoint truncates history data.

E
Userlevel 5
Badge +14

yes, the approver needs at least contribute permission on item level.

this topic should explain it in full details

"You are not authorized to respond to this task." message

V
Badge +3

"For sending back" also help "comments of Approver".

You can mark "comments" as "required" for "approve" or "reject" outcome.

Then insert "label" with "Approver comments" on "changes required" Branch and vice versa on "Approver" branch of State-machine.

WF_comments.png

V
Badge +3

I am looking for solution how to do the next thing.
Show only "last comment" (for focusing attention), but when user press the button "Show all comments" - show all of comments (for details and history).
It should work not on JS. Because "Nintex Mobile App" do not support JS. Only Form Rules, Regular Expressions, Workflow variables, calculated fields can be used. May be it is easy – only Button click action and set value of Label comments = All Approver Comments. Don’t experiment yet…

E
Userlevel 5
Badge +14

Vlad Yarygin​, here is one of many topics on how to get last approver comment. ​I describe there my approach.

https://community.nintex.com/message/30631#comment-30631

if you want to switch between last and all comments on mobile form, you will need to place on your form a control for each of them and with formatting rules ensure that one is displayed and second one is hidden.

if this doesn't answer your question I would suggest to start new discussion.

V
Badge +3

Hello Marian!

I do as you told me. Everything is working. Thank you! This is my print screen of rules

WF_Last_AllCommentsSwitch.png

W
Badge +9

Leif,

It is certainly great discusion . Is it possible to query/ display the last  state of a state machine in the SharePoint list. Should we constantly update The Workflow Status.

Daniel

A
Userlevel 7
Badge +17

I typically use a stats field that is separate from the workflow status field to keep track of state machine or workflow status. That way I can restart my workflow at the same point in the workflow using the state machine. Also, the workflow status field is a little bit unique, it does take other values, but it uses database values for its storage. I like the practice of persisting the status in a list field instead.

W
Badge +9

Andrew,

I had the same thoughts.  I want use the status field to indicate to the user the previous approval step as in which representative worked on the document last.

Daniel

A
Userlevel 7
Badge +17

Leif Frederiksen‌ I went ahead and marked one of your responses correct to give this thread some closure. You're right, there are so many great responses here that marking your response shows future readers to consider other possible options. If you feel you still would like to continue the conversation we can create a discussion post, or work on an additional specific question. I'm thrilled to see so many helpful responses here.

In summary, it would be easy to say that are some obvious bad practices to avoid. But there are many options to choose from that are all best practices for their use cases. It's just tough to see if one if above another.

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings