Dynamic approvers for douments

Document created by Eric Harris Employee on May 9, 2016Last modified by Eric Harris Employee on May 15, 2016
Version 4Show Document
  • View in full screen mode

Use this workflow to build in document approvals without hard-coding the approvers

 

AuthorBrad Orluk
Long Description

If you’re like me and would like to create a task driven workflow for a team that needs to assign approvers and evaluate variables (such as, approvers based on a geographic location, value of a project, etc.) and you don’t want to hard code those approvers and escalation values in the workflow itself (since that is a much more difficult process to maintain and does not lend itself easily to knowledge transfer when someone leaves the team!) then leveraging a state machine workflow and custom workflow data list should be your first choice.

Dependencies

A Document Library named Customer Documents – Click here to download the template

https://onedrive.live.com/redir?resid=7EE78FF8BAADFBE!8786&authkey=!ACM2aB7BEowlaIw&ithint=file%2c.stpA Custom List named Dynamic WF Data List* – Click here to download the template

You’ll need to create some variables to store data for this workflow:

  • perPriApprover – Stores the primary approver.
  • perSecApprover – Stores a secondary approver if there is another approver for the task.
  • perPriNotify – Stores the primary notifier
  • perSecNotify – Stores the secondary notifier if applicable
  • textExtNotify – Stores an external email address if applicable
  • textCostsinUSD – Stores the costs value from the data list as a string
  • bolHighCost – Stores our Yes/No value to be used a flag for escalations
Support Info

Brad Orluk - Leveraging Dynamic Approvers and then some! | Brad’s Blatherskite Blog

Compatibility

Nintex Workflow 2010

Nintex Workflow 2013

Platform

SharePoint Server 2010

SharePoint Server 2013

Screenshots

 

The workflow will consist of a couple of list queries that will allow us to capture the approvers and notifiers as well that the other kind of data used by the workflow, costs and a state machine to handle the conditional logic and approval tasks.

  1. List Queries (placed into an action set)
  2. Our state machine (configured with three states; evaluation of the costs, our default first approval level and then an escalated high cost approval if the High Cost flag has been set.)

2014-04-14_12-12-43

*Note that SharePoint 2010/2013 lists with more than 8 lookup columns will not work. If you have occasion to build a workflow that needs even more fields you will need to break the lookup columns up across multiple lists. Read more in Marc D. Anderson’s blog post entitled “The SharePoint 2010 “List View Lookup Threshold” and Why We Don’t Change It

Outcome

Now you have a workflow that will evaluate a piece of information (in this case a cost), notify some folks, assign a task to a default approver and, if necessary, escalate it to a top tier approver all by leveraging one list with disparate data types.

Additional Information

Nintex Xchange Terms of Use Policy

Nintex makes no warranty or guarantee about the reliability, performance, quality, or functionality of any assets, and any assets you install are therefore provided as is. By downloading this asset, you agree to the terms of use.

Attachments

Outcomes