EZ-Workflow does have an integration with Baan IV as well as Baan ERP5.0x. This integration provides:

• ability to capture Baan generated Requisition/PO/etc and initiate appropriate workflow route
• ability to notify specific user that the workflow route has been completed to trigger a Baan transaction to be executed
• ability to launch Baan session when task notification has been set as "application type" (BW middleware and Baan server access required)
• ability to receive from Baan key data attributes enabling the rule-based conditional route/step execution
• automated merge of external application transaction data (Ex.: Baan Purchase Requisition or external application data) into the task notification email, eliminating the need for the user to open the application to see the transaction data (useful in approval and manual tasks)

The Workflow (wms) in BaanIV was only a Beta-Version (Demo) and was never released nor supported by Baan.

Out of usually targeted flows to be Workflow-enabled, the Baan Purchase Requisitions approval process is often selected (because of its high volume and human-intensive nature). For the purpose of education and presentation, a step-by step scenario of how Baan Purchase Requisition approval can be automated is available at http://www.ez-process.com/Demos/EzWorkflowDemo/EZ_Workflow_Demo_viewlet.html. Although the scenario is presented with Baan ERP-5 sessions, it is also applicable/compliant with Baan IV releases.

Other typical areas/processes/canditates for Workflow execution:

• Employees/travel expenses approval
• New employee/account process
• Purchasing & A/P processing
• Change Request validation (IT customizations or Business Process changes)

Any types of transactions are able to be initiated to a Workflow route. Find below some examples:

• any transactions defined/maintained in an ERP/legacy applications (Baan, SAP, others). Upon being created or reaching a defined status, the transaction data (Ex. a Baan Purchase Requisition) can be transfered to the Workflow engine for Workflow execution.
• any transactions defined/maintained in a Microsoft applications (Excel/Word/etc files). Upon the files being created or move to a specific network folder, the Workflow engine can be configured to automatically register it and initiate the appropriate Workflow route.
• any system/network/RFID signals can be defined as a valid trigger to start a Workflow execution.

Any combinaisons of the next 3 modes is possible:

• Automated registration & initiation: upon a transaction being created/updated in an external application, this one can be electronically transfered to the Workflow engine.
• Manual registration & initiation: under the control of a "Workflow Coordinator", a group of transactions can be selected and initiated.
• Online registration & initiation: web-based driven, this mode enables any users (employees, online consumers, associates, etc...) to create and initiate a Workflow instance via a web-based form.

Time intervals can be defined for a combinaison of the following factors:

• defined globally for the environment or specific to each route step
• defined differently based on instance priority (i.e. "urgent" or "normal")

Upon the first deadline interval being reached, the Workflow engine issue a Deadline notification to the Manager/Coordinator responsible for the transaction.

Group sceduling can be defined in two modes:

• Team scheduling: the task notification is sent to all members of the team. The first member available capture the transaction, which dissapears from the other Worklists.
• Role scheduling: when several users are able to execute the selected task (based on their roles), this option will prompt during Workflow execution a Manager/Coordinator to identify which user is to be notified.

Yes. Custom forms with custom layout and fields is allowed.

Two types of routing rules can be defined:

• Route-level rules: Based on user-defined data fields of the transaction (ex. order amount, department code, etc...) these rules (IF amount > 50,000 AND department-code = "abc") will select the appropriate route(s)to be initiated.
• Step-level rules: based on user-defined fields, these rules will dictate if some route steps are to be skipped for the execution of the current instance.

Both types of rules are evaluated through the entire life-cycle of the instance. Any changes in the transaction data values during the execution of the instances (ad hoc changes) will be reflected in the rules evaluation.

Yes, parallel processing is allowed.

Yes. Any combinaison of the following task documentation is allowed:

• extended work instructions text can be attached to the instance being executed
• extended work instructions text can be attached to the route being executed
• extended work instructions text can be attached to the steps being executed
• unlimited ISO documents (Word, pdf, html, xml, etc...) can be attached to the step being executed

Upon these defined, the user notified of a task receives access to all the the above.

Several notification modes can be used:

• Email notifications (work-items are displayed in inbox of the Workflow executor)
• Online notification (available from any PC, this browser-based "Worklist" displayed all tasks assigned the Workflow executor)
• Desktop notification (visual & sound indicators alert the Workflow executor)
• Pager/SMS notification (useful for urgent instance, alerts can be sent to pagers, mobile phones or SMS devices).

Any combinaisons of the above notification modes is allowed.

The following Exception Resolution modes are allowed:

• Resolve step option: the Coordinator completes the rejected step. The Workflow execution resumes with the next step in the route.
• Forward To option: the Coordinator assign an Ad hoc substitute user to complete the rejected step.
• Re-route Step option: upon investigation of the rejection details, the Coordinator can perform a "GoTo" step to either redo some previous steps or skip to further steps.
• Abort Step option: the Coordinator triggers the rejected step to be skipped. The Workflow execution resumes with the next step in the route.
• Abort Route option: the Coordinator triggers the entire route execution to be cancelled. The instance status is set to closed.

For performance optimization, archiving is possible and recommended. Auditors are able to query the detailed history of the instance execution (who did what when) for all instances, archived or not.