Inteface development methodology and standards

Just some ideas/tips.

1. Branch Rewiring: When doing a branch in Process Flow you may want to put an empty assignment node after the branches. If you don't do this and you need to re-wire were the branch connects the order can get messed up and you may get to redo the entire branch.

2. Out of Office: Consider what you want to do with out of office situations. It will always happen. How are you going to handle something like the CEO or VP wanting something to reach them and the work unit is stuck on Fred's inbasket because he is on vacation? We wrote some code so people can set a 'Out of Office' that removes themselves from routings however the users don't always set this. Also users can forget when they have turned this on. I wonder what other people have done on this? I have considered adding an inbasket action of 'forward' which instead of an 'approval' would simply move an inbasket item up one level in the approval process. Yes it is technically possible for the process flow admin to go in and do approvals but that I think would probably be a bad idea. We here do not have the process flow admin(me) do approvals. Right now we set peoples 'Out of Office' and then restart processing on process flow units that are stuck.

3. Escalation: You may not be looking at escalation but if you do consider things like three/four day weekends and other scenarios like that. Also sometime people want to hold onto things for legitmate reasons. We ended up not using it. Consider writing reports or SmartNotes as an alternative.

If I can comment on item 1. As long as it is a small flow that is fine. Adding unecessary nodes to a flow adds overhead. How the product works is that all workunit variables, and variables that you define in the Start node are tracked as to their value at the point of each node (WFACTVAR table). Even if you do not change a variable in a node a record exists. So if you have 40 variables in a flow, there are 40 writes to the WFACTVAR table after every node including the "dummy" nodes, not to mention the flow tracks other data in other WF tables when a node is executed. Giving up efficiency on the small chance you have to change a branch node in the future would not be worth doing in my personal opinion.

The biggest weakness in the product is the Proxy for inbasket. For some reason the temporary assign logic is an all or nothing per Task. It is the one aspect I have to customize with every client I work with. The best advice I can give is keep you Task definitions simple, use the User option instead if you can because administration of Task in processflow is horrible.

I have developed flows for clients to bypass weekends. it runs on Friday evenings and automatically adds 48 hours to the wait time for all Inbasket entries where no action has taken place yet. Escalation is configurable on a flow by flow down to approval level to approval level and can be progmatically changed. Not having escalation can run the risk of workunits sitting "unnoticed". I have had clients that had flows in progress for more than a year. Having a ProcessFlow administrator can help that from happening, I have also written scripts and reports for clients to report on dormit flows.

But it sounds like your intent is more to use the Integrator aspect of the product. It is very versitile and processing files like CSV's or parsing XML for Web Services to get information into Lawson and out. You have the ability to access tables from non Lawson systems as well through SQL and JDBC.