Have you ever created a boolean variable to set whether specific conditions were met in your ProcessFlow and then used a Branch based off of whether it was true or false?
Did you use the condition variable==true?
Did you know that since your variable is either true or false that you could just reference the variable name as your condition and whatever the boolean value was the Branch would interpret that correctly.
So, instead of using variable==true you could just use variable.
Give it a try - it's pretty cool.
O Happy Array!
I've recently had to read through a lot of data within ProcessFlow, comparing lists values, etc. and have found that using arrays is a great way to read and compare data.
Most recently I built a flow to review the HR Supervisor records and compare it against ProcessFlow Approvers to make sure the records were in sync. My old method of doing this was to cycle through HRSUPER with a Query while running another Query within the HRSUPER Query loop to see if a matching record existed in PF Admin.
While this did work, I really didn't like running that 2nd Query 900 times! My solution this time around was to run both queries once, saving the values into two different arrays.
I then used a couple of JavaScript Expressions (within an Assign node) to compare my two arrays - one to produce a new array of new Approvers to add and the other to produce a list of Approvers to remove from PF Admin.
I then cycled through these two new arrays with a DataIterator node and used 3 WebRun nodes to add or remove the PF Admin records (User, User Task, User Task Category) as I cycled through the records.
You can do a lot with arrays. I used them recently within Design Studio to assign values from a DME and manipulate and sort the records before presenting them on my form.
O Happy Array!
Most recently I built a flow to review the HR Supervisor records and compare it against ProcessFlow Approvers to make sure the records were in sync. My old method of doing this was to cycle through HRSUPER with a Query while running another Query within the HRSUPER Query loop to see if a matching record existed in PF Admin.
While this did work, I really didn't like running that 2nd Query 900 times! My solution this time around was to run both queries once, saving the values into two different arrays.
I then used a couple of JavaScript Expressions (within an Assign node) to compare my two arrays - one to produce a new array of new Approvers to add and the other to produce a list of Approvers to remove from PF Admin.
I then cycled through these two new arrays with a DataIterator node and used 3 WebRun nodes to add or remove the PF Admin records (User, User Task, User Task Category) as I cycled through the records.
You can do a lot with arrays. I used them recently within Design Studio to assign values from a DME and manipulate and sort the records before presenting them on my form.
O Happy Array!
Change the System Reference in Design Studio
A couple of years ago I referenced how to
Drill Down from another form in Design Studio and I recently had to revisit this option.
When I have to create a custom form, I often just use WFWK.2 as a blank template and build the form, adding the labels, fields and buttons I want to use.
Most of the time this meets my need, unless I need to include a list of employees.
I was able to pull in the Company and Employee fields with their key numbers from HR11 but the select field still wouldn't find any matching employee records. I realized that if I went into the Source of my form and changed the reference to System="HR" that the select field now worked.
Since I'm just using WFWK.2 as a blank template I didn't need to retain the default System="WF" reference.
What a nice work around!
When I have to create a custom form, I often just use WFWK.2 as a blank template and build the form, adding the labels, fields and buttons I want to use.
Most of the time this meets my need, unless I need to include a list of employees.
I was able to pull in the Company and Employee fields with their key numbers from HR11 but the select field still wouldn't find any matching employee records. I realized that if I went into the Source of my form and changed the reference to System="HR" that the select field now worked.
Since I'm just using WFWK.2 as a blank template I didn't need to retain the default System="WF" reference.
What a nice work around!
User Level Work - proxy approver solution
I was asked recently about how to set up a proxy approver for User Level Work tasks. I had previously provided solutions at the Task Level, but not when a UserAction is designated to a User instead of a Task.
What I would do is to create a special “Out of Office” service and flow. The approver would log into an “Out of Office” UI form modified by Design Studio (I usually use WFWK.2) and enter their proxy approver. When they click submit then an OoO service is triggered.
The OoO flow file will add a new Task to that approver and place itself into a UserAction with one available Action – ‘Turn off Out of Office’. Once that is selected the “Out of Office” task is removed and the WorkUnit closed.
The separate approval flow (like for Personnel Actions) would have to query open WorkUnits to see if the pending approver has an open “Out of Office” WorkUnit and read the proxy user id variable. That variable value would be used in the UserAction so both the original approver and the proxy approver are both represented.
The UserAction would also have to be set to “Any Approver Takes Action” so the WorkUnit Metrics records will close correctly once either approver has taken action.
What I would do is to create a special “Out of Office” service and flow. The approver would log into an “Out of Office” UI form modified by Design Studio (I usually use WFWK.2) and enter their proxy approver. When they click submit then an OoO service is triggered.
The OoO flow file will add a new Task to that approver and place itself into a UserAction with one available Action – ‘Turn off Out of Office’. Once that is selected the “Out of Office” task is removed and the WorkUnit closed.
The separate approval flow (like for Personnel Actions) would have to query open WorkUnits to see if the pending approver has an open “Out of Office” WorkUnit and read the proxy user id variable. That variable value would be used in the UserAction so both the original approver and the proxy approver are both represented.
The UserAction would also have to be set to “Any Approver Takes Action” so the WorkUnit Metrics records will close correctly once either approver has taken action.
Subscribe to:
Posts (Atom)