Process Automation

Workflow Design

In general, when designing a workflow, it is recommended to keep it as simple as possible. Large designs that cover more than one business goal tend to cause issues when updating or enhancing them.

• Whenever possible, use subprocesses to improve readability.
• When workflow design is becoming complex, involving a lot of steps, consider the technique of calling a workflow from within a workflow to simplify the structure and understanding, and especially if there are any activities that can be executed in parallel, as this has the potential to improve efficiency.
• Consider grouping activities in a new Workflow when no human interaction is needed and there is no relationship with the other activities in the main workflow. This will allow reusing the new Workflow in another business workflow. Consider that no Drill back will be possible to the design of the Workflow from the main caller workflow, by means of the Workflow Viewer widget (formerly known as Workflow Activity Locator widget)
• When designing a workflow, it is important to have meaningful titles in the Main Workflow and on the Tasks.
  Also in the description box have type the key information about the business process the WF is doing.
• Consider using the pre-defined Application specific workflows whenever possible. Those are included in the Content Pack for the specific application or in the Implementation Accellerator. It is often easier to use these as a template and modify them to suit your needs than creating a workflow from scratch.
• Avoid using Workflows for tasks that are Integration tasks and don’t involve any user interaction. Use
  Document Flows instead.
• Distribution of Tasks or Notifications in a Workflow should be done preferably to a Group instead of a single user, this to prevent that Workflows must be adjusted when users leave the organization.
• By default, a standard template is provided for emails sent by the Activities engine for tasks, alerts, and notifications. This template is described in the email_template.htm file.

---

Using API Calls

• API calls have the potential to cause response and performance issues and the number of calls should be minimized if at all possible, but generally if they are only being used to fetch data then that is acceptable. If possible, have the application that is triggering the workflow pass in the data that is required.
• API calls which post data should be avoided if possible. Frequently, these types of calls will generate BODs in the receiving application which have to be handled in some way – so perhaps consider placing these types of calls within a Document Flow instead of a Workflow, if feasible.

---

Using Waits

Make a good use of the ‘Waits’ when designing a Workflow. Consider reducing the number of uses instead of increasing. Consider that, if no relationship between activities, might mean that a new workflow needs to be created.

---

Using Loopbacks

When using LoopBacks, be aware of limit of 999 retries. Put a guard which will exit the loop.

---

Using Business Rules

• There are two types of Business Rules. A Decision Matrix is used to set parameter values based on a combination of other parameter values. An Approval Matrix allows approval tasks to be sent to multiple approvers in sequence depending on parameter values (e.g. the Purchase Order Amount). Both types of Business Rule can be defined directly inside the workflow definition or can reference a separate Business Rule object.
• Use external Business Rules whenever the data set is not technical but business data, for example approval users or approval thresholds. That way business data can be modified without involving the workflow designers (Infor or the IT department).
• Approval of changes to values in a Business Rule is required. There are separate Security Roles for editing and approving Business Rules:
  • DECISIONSERVICE-Editor
  • DECISIONSERVICE-Approver
• When using a Decision Matrix that checks more than 3 parameters, it is recommended to build a Business Rule instead.
• If using an external Decision Matrix that uses the “Keep Original Value” option for a parameter to set, this parameter needs to be passed in as a parameter to check as well. This is because the external Decision Matrix runs in a separate process to the Workflow and does not know the value of the parameter.

---

Starting Workflows

• There are different ways of starting a Workflow:
  • Via Activation Policies, only possible for Sync BODs!
  • Via Workflow schedules,
  • Using a Workflow activity in a Document Flow,
  • Using the Process Workflow BOD sent by an application,
  • From an Alert (Monitors), only possible for Sync BODs!
  • From another Workflow,
  • Manually by a business user, using e.g. the Start Workflows Widget
  • From an API call (/workflow/start method has been added), see ION API IONSERVICES/process/application and IONSERVICES/process/user for information.

• Study and consider the best way to start a Workflow in each situation which will depend on the Business goal.
• Multiple ways of starting a workflow can be combined for a single workflow definition. For example, a workflow that has an activation policy can also be started using a Process.Workflow BOD.
• When using Activation Policies, use Sync.BOD to trigger. Other verbs like Process or Acknowledge are not able to trigger an Activation Policy! For other verbs put the Workflow in the Document Flow to start it.
• If it is required to update data in the originating application, only starting the Workflow through an activation policy, a Document Flow or a Process.Workflow BOD will enable that.

---

Using Activation Policies

• When using Activation Policies to start a workflow – there are 2 policy types, the ones that ‘start’ a Workflow under certain circumstances (specific events) and other to ‘cancel’ a running Workflow, also event specific. Think carefully in which conditions and values each type should be triggered. Not always a cancellation type is required.
• A workflow instance is started each time a document is received for which the activation policy rule evaluates to True. By default, if a workflow instance is already running when an update of the same document is received, the document update is ignored. To cancel the running instance and restart the workflow for a document update, select Cancel running Workflow.
• When a document is received, a workflow instance started by another activation policy might be running. If so, and the rule of the activation policy of the Cancel Workflow type evaluates to True, this workflow instance is canceled.

---

Alerts and Messages

• The main limitation in Volume of Workflows is not ION but the end users. When too many Tasks and Notifications are generated, the users will not be able to process them.
• When due to Data Load or other changes in the Applications which are sending the BODs a high number of BODS are generated, consider the option to deactivate the Connection Point or the Workflow temporarily.
• Check if connected applications send BODs on each and every minor change, this may need adjustment in the connected application to send BODs only when all changes are processed. For example Infor LN triggers a Workflow for Purchase Order approval only when the user has finalized the PO and approved it in Infor LN.

---

Diagnostic and Debugging

• Use OneView to first troubleshoot an issue/problem with an activation policy or a Process. Workflow BOD. In there you could see the value of attributes, value of conditions which trigger the workflow one way or another.
• For additional monitoring “Logging of Triggers” can be activated: You can change the settings for logging triggers through this ION menu: Configuration > ION Service > Properties > Event Management engine.

---

Import/Export – Lifecycle management

• Naming conventions for Workflows – Avoid using Tenant Name on the Name of the Workflow, it will facilitate deployment to Production.

• We recommend that you import and export workflow definitions and related items, such as activation policies or document flows, together.

---

Workflow Parameters

• When defining a workflow parameter, spend some time planning where and how the parameter will be used, then set it up accordingly:
  • What data type should it have (String, Integer, Decimal, Date etc.)? This determines what the user can enter.
  • Does it need to be an input parameter, output parameter, none or both?
  • Can you provide a sensible default value?

• In a Task or Notification, should the user be able to see the parameter value? If not, remove it from the Content.
• In a Task, does the user need to be able to modify a parameter value? If not, make the parameter Read-Only.

---

Structures

• If you need to manage structured or multi-instance data in a workflow, you can use Structures. Structures can be passed to a Workflow through an Activation Policy, a Process. Workflow BOD or through the ION Process API when starting the workflow instance.
• When mapping structured data from a BOD, e.g. Order Lines to a structure, only include the data in the structure that is needed in the Workflow. If the user requires more detail, a drillback to the application should be provided.
• Individual values from the structure can be retrieved and assigned to a parameter using the Set Parameter action. It also allows using aggregate functions (Average, Sum, ..) for numeric values.

---

Workflow Authorizations

Limit the users that can start a workflow manually or through API calls with Workflow Authorizations. Use the appropriate Security Roles or create a specific one if required.

Codes

In Workflow, you can use Codes to specify possible choice values for workflow parameters of the Code type. When these parameters are used as input parameters in tasks, they are displayed as a dropdown in Infor Portal.
This saves user typing errors on the textbox fields showed on the tasks as we limit the input of the user by a predefined list