Features

GUI Workflow Designer

Risk IDS gives the end user complete control over the design and implementation of Workflows using the Risk IDS Workflow Builder. The Risk IDS Workflow Builder allows the end user to create new workflows and allocate these to a Workflow Group dictating how, where and when the Workflow may be executed.

Once saved, the Workflow definition is stored in the database and immediately available for execution. When Workflows execute, an XML document is stored in the background containing all information passed at launch and collected throughout the workflow execution.

Send Notifications that solicit complex responses

Notifications are sent by the Workflow Engine to solicit a response from a variety of sources, which are merged into the Workflow XML. Notifications are made up of headers, footers and a body that is constructed by iterating through the results of an XML Procedure or SQL statement.

Notifications to the Web-User Interfaces 

When a Notification is sent to the Risk IDS Web-User Interface, it will display a screen capture form, known as a screen step, to collect responses from the user who has launched the Workflow. These responses are taken and merged into the Workflow XML.

Notifications to Risk IDS Users

The Workflow Engine can send notifications to Risk IDS users, placing these in the Notification Browser and sending a copy to the user’s email. The notification can be configured to request a response from a list and demand custom data fields.

SMS Notifications

Notifications can be sent to a mobile phone via the Risk IDS Automated Contact Cloud. The response received from the mobile phone will be merged into the Workflow’s XML.

IVR Call Notifications

The IVR process is managed entirely by the Workflow Engine. The communication with the person on the other end of the telephone is achieved by the dispatch of Notifications.

Recoded Voice and Text to Speech

The notifications sent to the IVR are a mix of .wav files and text-to-speech instructions. This allows a generic recorded voice, perhaps to introduce a call, to be blended with more dynamic text to speech, perhaps for reading the details of suspect transactions.

Transferring an IVR Call

Notifications can be used to transfer a call to another telephone, and will then play a .wav file or text to speech prior to transferring the call.

Execute XML Procedures or Adhoc SQL

XML Procedures are a standard type of database procedure used by the Risk IDS system. Every interaction with the database occurs via an XML Procedure. XML Procedures take XML as its parameter, extracting required XML elements from this. The Workflow engine can call upon any XML procedure in the Risk IDS system and merge in the XML response.

Additionally, the Workflow Engine can execute an SQL statement, converting this into XML and merging the response into the Workflow XML.

Merge XML Elements, Perform Arithmetic and Construct Loops

The XML being stored contains any information merged by Workflow processes. XML Elements can also be merged explicitly or as the result of arithmetic performed against existing XML Elements.

This means that the Workflow XML can be used to store variables without the need for these variables to be explicitly declared.

By using arithmetic and channelling to a previous stage in the Workflow Definition, complex conditional loops can be constructed.
 

Channel Workflow Execution to Multiple Outcomes

Workflows can have many possible outcomes depending on the decisions that have been made in the Workflow. These decisions could be driven by notification responses, database operations or the results of arithmetic. Based on evaluation criteria, a workflow can be channelled to a specific outcome or to further processing.

The Workflow engine can gracefully handle errors that occur in workflow execution, such as a database error by channelling the Workflow to a separate outcome or simply stepping over the error.
 

Defer workflow for later execution

Workflows do not have to run straight-through.  There are occasions when a workflow needs to be paused for a period of time before execution should continue.  This is known as deferring a workflow. 

An example of where a workflow might need deferring is when making automated outbound calls to a customer.  In the event that an answer phone is reached, the workflow can be deferred for an hour or two, before trying again.

Integrate to external systems with Integration Event queues

Real-time integration from the Workflow Engine to external systems is performed by the Workflow Engine using Integration Events. The Workflow’s XML is placed onto an outbound queue where it is picked up by the integration service.

The integration service will communicate with the external system, obtain responses, and merge this into the original XML. The new XML is placed on an inbound queue where the Workflow Engine will collect and merge into the Workflow XML before continuing Workflow execution.

Audit of Workflow Definition and Node Execution

An execution of a Workflow Definition is called a Workflow Instance. Full audit of Workflow instances is maintained including all activities executed as part of the Workflow Instance.

Workflow Instance Audit is available in both the Relationship Browser and the Workflow Audit screen in the Risk IDS Web-User Interface.