Result Variables for a User Action

WFMETRICS is the table you want.

I have a similar query to validate actions taken on requisition approvals. WFMETRICS.TASK will tell you the task on which the action was taken, WFMETRICS.WF_RM_ID will tell you the person who took the action and WFMETRICS.OPERATION will tell you the action they took.

Just let me know if you want me to send you the full SQL query by email.

Thanks TBonney for your quick response. I have the query built, thanks for the details on the tables and fields. For now I will use the query but I was hoping to pull the value from the flow and avoid using a query.

Why the aversion to putting a query inside the Process Flow? Are we missing something here? Queries are about the easiest thing to do in a Process Flow.

I am not opposed to using queries but it seems like the answer I need was created in the PF and then written to the table and now I have to use a query to go outside the PF to get the answer and bring it back in. Not a big deal, the query works great and the flow is doing what I want so I am happy.

I re-read what you posted and I think I "may" know what is happening. What if you create the variable as a global variable in the START node. Then update it as normal. I recall something about variables losing their values in between User Actions. That might solve it.

Hi Terry
I found the below information in one of the Lawson help guides. It describes the variables that come out of the UA, in particular I was trying to look at the _users variable which is an array. I did set up several variables in the Start node and would capture the information as it came out of the UA. The first time through the UA node it would capture the approver name but I found as the flow looped back through the node again and again, the array never grew to more than one element and the value never changed after the first pass. For example if "A" approved the first time and "B" approved the second time the _users variable still contained "A" as the value. If I let the node time out and reassign to "B" on the first pass then B would always be the value in the _users variable even if “C” approved on a subsequent pass. I am pretty happy with the results I am getting using the SQL query so this is no longer a pressing issue but something that might be useful down the road.

Variables for accessing data about actions taken by users
The variables shown in the following table are available for sending and receiving information about users' actions after they have taken them.
Variable Description
NodeID_users Contains users who took action on the specified node.
NodeID_actions Contains actions taken on the specified node.
NodeID_reasons Contains reasons selected by users who took action on the
specified node.
NodeID_messages Contains messages sent with the specified node

I am having this same problem with our req approval that was written by a Lawson consultant.  She used the _users variable on every UA node (of which there are many).  I am just finding out that the _users does not change after the first person takes action.  This really seems like a bug to me.  I have one now where several users have tried to reject it, but it still thinks it's the first user.  The problem for me in doing the query on WFMETRICS is that there are numerous records with 'Reject' as the task.  The days they did it are the same too.  Does anyone know what the ActivityID variable is called on the UA?  That seems to change with each UA taken.  If I could select based on that, I would be sure to have the correct user. 

What information are you trying to retrieve? The last user who rejected? That would be the last "reject" record in your DME call so you could run your query and then use an Assign node right after the query ran to get the information.

Yes, I am trying to get the last user that rejected it.  If I run a standalone query to test this, they aren't sorted in chronological order.  So, I need a way to know that the one I am looking for is the last one.

I do something similar to find an approval. Mine is a little easier because I allows know the filter to apply but in your case to accomplish what you need I would capture and store the ID's after each action and apply as a filter in your lookup. This means dynamically creating the Query string (Build and store as a variable). The net affect is that you filter out previous actions leaving only the action you want to see. There is one issue and that is if the same person can act on this node multiple times in which case this will probably not work. Just a thought

Check the index that you're using. I've always gotten this type of query to work in the past for the last approver. Are you sending the UserAction to more than one user at a time? I haven't tried it in that case.

Thanks, David. I found an index that is sorted by date/time, so it looks like that will work. Yes, we do send the UAs to more than one user at a time. I don't think that will cause a problem here, but I will test it.

Thanks also, Robert, for responding. We do have the same user trying an action repeatedly time and time again due to the fact that they forget to enter a message. If you know of a way to have a pop up box telling them they didn't enter a message, that would be terrific. It sends them an email after they've gone through the process which is not user friendly at all.

Lynne, what I ended up doing is running a query (I use the table WFMETSUM) right after the UA, I sort desc by END_DATE then END_TIME and I select the first result so I have the most current user for the UA. I think that is what you are saying you are going to do but I wanted to let you know it has been working for me.