Design Studio - clearing a text field when you Inquire (or Next or Previous) a form.

Here's a simple command to add to your Design Studio Script to clear a field you've added:

function FORM_OnAfterTransaction(fc)
{
lawForm.setFormValue("text15","",0);
}

ProcessFlow Job Requisition Approvals
After a job requisition is in the ProcessFlow approval process if you make a change to the Job Requisition (PA42) your WorkUnit is cancelled by the system and a new one is kicked off. This restarts your flow at the beginning of the approval process and may not be the way you want to go.
One way around this is to use your initial JobReq Approval Service to kick off a new service (using a WorkObject in your flow) which will then handle the approval process of the Job Requisition.
The down side is that a WorkUnit will still be created when a change is made to your Job Requisition but you can design your flow to check whether or not the 2nd service was already kicked off and simply go to the End of your flow when true.

ProcessFlow Inbasket PA52 "soft edit" messages.
Because of other customizations with Design Studio, the department that used to see the PA52 soft edit messages, like salary out of range, doesn't see them anymore. They do, however, use the Inbasket to review the Action so I added a function to look up the salary range and provide a pop-up alert if the pay rate is outside of the range.

I use another function to check for WorkUnit messages and provide a pop-up alert for that as well. Now the approvers don't have to click on the Messages folder to see if any comments have been added to the Work Unit.

ProcessFlow offline escalations.
One of my clients wanted to customize their escalaton notices and the Inbasket WorkUnit titles so we moved their escalation process to a completely seperate flow which will run nightly and escalate the approval levels every 48 hours.
We're updating the WF46 records to the next approver TASK and sending a custom email. We're also revising the WorkUnit Title to reflect that the requisition has been ESCALATED so the approvers will see that in their task list.

Are PA52 soft edits giving you problems when you try to add records via MS Add-Ins or an AGS call from Design Studio or ProcessFlow?

Add the following hidden field value: XMIT-HREMP-BLOCK=1000000000
and those soft edit messages will be ignored.

See Lawson Knowledge Base article 1037326

The problem with ProcessFlow non-persistent variables.

What the heck are those? When you run a Query and reference that Query later within your flow - Query_FIELD_NAME - those are non-persistent variables. Persistent variables are ones you create on the Start node or are passed to your flow from a Service.

So, what's the problem? Apparently non-persistent variables are cleared out after you come to a UserAction in your flow. If you need to reference these variables after a UserAction (and who doesn't?) you will need to create persistent variables and then Assign the non-persistent variable values to them.

I like to use variables in my User Node notifications and have them available later in my flow so I'm going to have to start making them as persistent as I am.

ProcessFlow Escalation is a beautiful thing - most of the time. I recently discovered that if ProcessFlow escalates a task from one UserAction to another that it won't escalate again from the 2nd UserAction to a 3rd (even if I have escalation built into that 2nd UA).

I was told that it shouldn't HAVE to do that - to which I replied "tell that to my client." So how did I escalate a task twice? I created a 2nd flow that would Query the WFWUQUEUE (joined to WFACTIVITY) table for any record which had been escalated - Display Status = 1 and Reassign Flag = Y (already escalated) and Reassign Task != (not equal blank) and the WFACTIVITY Start Date = whatever date.

When I found these records I used an AGS call to WF46 and simply changed the TASK to the next level UserAction that I wanted to escalate to. It's that simple. This flow runs nightly from the ProcessFlow Scheduler.

If your users don't get their notifications from your ProcessFlow UserAction, check your log. If the log contains the following error when sending a notification within your UserAction check your Mail_From setting on RD00. This error occurs when you don't have a value in your mail from.
ErrorLog in Process : level1_V1 WorkUnit : 999, ActivityType=UA, ActivityName=UserAction3100, ActivityId=UA164142609350 Date:08/16/2006 Time:16:41:05 Error while executing UserAction activity java.lang.IllegalArgumentException: null source Stack Trace : java.lang.IllegalArgumentException: null source at java.util.EventObject.(EventObject.java(Inlined Compiled Code)) at com.lawson.javaworkflow.processflow.workFlow.flowGraph.LogEvent.(LogEvent.java(Inlined Compiled Code)) at com.lawson.javaworkflow.processflow.workFlow

Here's the Query string you would use to check the Lawson queued jobs either with a status of "Needs Recovery" or "Invalid Parameters."

PROD=GEN&FILE=QUEUEDJOB&FIELD=JOBNAME;USERNAME;STATUS;STOPDATE&
SELECT=STATUS=34STATUS=35&OUT=CSV&DELIM=~

Add the results to a Message Builder and then Email them to your BA's or system admin.

ProcessFlow and variables - another consultant and I were playing with variables and wondered why the variable wouldn't accept the value we were trying to assign to it. We finally discovered that you can't use a number as the beginning character of your variable name.
"8weeks" is not a valid variable to ProcessFlow, but it doesn't tell you that when you create it.

An Escalation tip for ProcessFlow:

You can update the WF46 form's "Hours" for your UserAction escalation to account for weekends. The WF46 escaltion timing is in Hours (even if you set it to 1 day - it converts to 24 hours) and you can use an AGS call within a "escalation" flow to push out the number of hours to wait before escalating.

You can also update the "Task" assigned to the WF46 record to escalate to a different approver than the one set up in your UserAction.