The June Mission is your opportunity to show us how you'd build a workflow for the following:
A service team has a SharePoint list where users submit requests that they need to fulfill. There are currently 5 different types of requests that they can receive and each request type has between 20-30 steps that have to be completed in order to fulfill the request. The team has been having some difficulty keeping track of the status of each request and knowing whether all of the steps have been completed or not. This has led to some request falling through the cracks and the users are none to happy about it.
The current request types are:
This is a sample list of steps for an Inventory request. Each request type will have it's own unique set of steps.
|1||Create master schedule|
|2||Notify the affected departments|
|4||Clean all areas for counting|
|5||Group like items|
|6||Ensure there are no hazards present|
|7||Mark package quantities|
|8||Count and seal partially packaged items|
|9||Mark items not to be counted|
|10||Label each area to be counted|
|11||Validate all items are identified with part number.|
|12||Update storage area floor plans|
|13||Organize couing teams|
|14||Distribute written instructions|
|15||Conduct physical counting|
|16||Conduct 2nd physical counting|
|17||Compare results for accuracy|
|18||Turn in count sheets|
|19||Reconcile counts with the system|
|20||Turn in final inventory results.|
The manager of the service team would like there to be an automated way that when they receive a new request, the system would create the correct steps for that request type that need to be completed. Then as the steps are completed the system would update the overall status of the request so that they could look at any request and know how many steps are remaining. The manager wants to track all of this in SharePoint.
Using SharePoint lists and Nintex workflows, design a process that will create the steps for each request type, and then track the status of each request as the steps are completed. The solution also needs to account for the fact that a new request type could be created in the future, with it's own set of steps, and the manager would want to be able to add it without having to modify the workflow each time.
The team is currently using SharePoint on premise with Nintex Workflow, but they may be moving to O365 in the future. So you can design a solution either for SharePoint/Nintex on-premise, or for O365.
To receive the points, build your solution and click here to create a document in the Nintex Gallery about your solution, detailing exactly how you would solve this issue. Post a link to your solution below below to earn 400 points and the June "Request Quest" badge!
We look forward to your solutions!