Nintex for SharePoint Forum
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Hi All,
I have a lookup list for software, eg:
Item Approver
Word
Excel
Visio John Smith
Photoshop Micheal Wiley
This lookup is used in a Nintex form. Users can select multiple options from the list above. The result gets passed to a Single Line of text (but i could change that), with comma delimited values.
How do I setup the resulting workflow to parse through the selected options on the form, and initiate the appropriate approvals. Let's say for instance all 4 were requested, the workflow should determine that Word and Excel are ok to be installed because they have no listed approver, while Visio requires an approval from John and Photoshop requires an approval from Micheal. I'd rather not have 4 workflows spawned off from the original but handle it some other way, such as a Loop. thanks
Solved! Go to Solution.
Hi!
Not at my computer right now to be able to add any screenshots but will do later if you need. i think you need to:
Does that make sense? I can add some screenshots tomorrow (or perhaps , , might be online to do that)?
If you were storing the names in individual fields rather than a single string it should be fairly easy. You could have a single workflow with a RunIf action to check if the string for each application was populated with an approver. It's populated, then it would create an approval task. Here is a mock up.
If you you foresee more applications being added to your process, and you want to do the loop as you suggested, you could use the single string like you mentioned, but you'd need to add in the name of the Application before each name. Then in your workflow you could use a RegEx to parse the string into a collection, then run through the collection and create your approval tasks depending on if the application had a name or not.
Dear,
1-Create three collections: one for the selected options, one for the "to be installed" ones and one for the "requiring approval" ones. (var_Coll_Selected, var_Coll_ToBeIns, var_Coll_ForApproval)
2-Use a regular expression to split the value based on the delimiter (comma here) then store the result in a var_Coll_Selected.
3-Loop the var_Coll_Selected, for each item inside, query the "lookup list" where "Item(lookup list)" is equal to the item in the collection. then store the "Approval(lookup list)" in a variable called var_Approval.
4-Check var_Approval, if empty, append the iterated item to the var_Coll_ToBeIns collection, otherwise append it to the var_Coll_ForApproval.
5-Now outside the "For loop", you have 2 collections of items that you can deal with.
Cheers...
I don't think this solution is very scalable. There are probably more than 4 applications
The challenges you face are the details, like:
- When someone rejects an application, does this mean all other applications are rejected?
- What to do when someone does not respond? Are all other application requests postponed?
- Is there a deadline before all applications have to be approved?
- Avaiable applications are maintained in a separate list. What to do with obsolite applications?
You probably also want all approvals requests sent at the same time (parallel, not serial), hence a loop with a flexi-task does not work. This will be your main workflow challenge imo. You mentioned you do not want to spawn of other workflows, but what I expect you want cannot be done in one workflow (and one list).
Please reconsider that your solution should be a one-workflow only and investigate time in the details first.
Cheers,
Rick
I listed 2 solutions. The first solution is based on his specific question, which only listed 4 options. The 2nd solution is scaleable and would handle any number of applications. Appreciate the constructive criticism though.
Cassy this is fantastic, just what i needed to get my brain moving.
thanks!
Thank you both. Definitely would need the second option. I'll get this into a proof of concept and see if i run into any issues.
Cheers Rick, your points are all well taken. I agree that parallel would make more sense logically and had thought of the same idea, but then backtracked when I realized I would need to define the number of parallel branches beforehand, and this would presumably vary based on the scenario, so that seemed to put parallel out as option.