Jump to: navigation, search

Composer Versus IRD

Integrated Development Environment

  • Composer is a single Integrated Development Environment (IDE) for creating applications to orchestrate the entire customer experience. Composer-created voice and routing applications can command and control the customer experience through all channels (IVR, voice, e-services, and so on).
  • Composer's open framework enables widely-available, existing competencies to be used to create reusable components that manage the customer experience. The IDE allows both customers and integrators to utilize existing code sets (HTML, VXML, java, perl, REST and others) to control the customer experience.
  • The open framework also allows simplified integration into all Enterprise applications to harness the information within the Enterprise to drive and personalize the customer experience.

Differences from IRD

In the past, Interaction Routing Designer was the only Genesys tool to create routing applications. Genesys Composer is now the tool of choice for creating both routing and voice self-service applications.

A few of the differences between Composer and Interaction Routing Designer are listed below.

Composer Routing Application Types

You can use Composer's predefined blocks and/or write your own code to create routing applications that route based on various criteria such as:

The above list is by no means complete. It represents only a few types of routing applications that can be created in Composer. Since Composer uses open languages (SCXML and ECMAScript), you are not limited to its pre-defined blocks, but are free to create many types of routing applications.

Migrating IRD Strategies into Composer

Note: You can migrate routing strategies created in IRD into Composer. For more information, see the IRD to Composer Migration Guide.

Composer Blocks Mapped to IRD Objects

Composer refers to the fundamental element of a workflow as a "block" whereas in IRD documentation, this element is referred to as an "object." The tables below group IRD objects based on their IRD toolbar category name and point to the corresponding functionality in this release of Composer. Summary information is presented below.  

Data & Services

IRD Object Name Composer Block Name Description
Database Wizard DB Data DB Data retrieves information from the database. Uses a the Query Builder Query Builder.
Web Service Web Service Invokes Web Services. GET, POST and SOAP over HTTPS are supported.
  Web Request Invoke any supported HTTP web request or REST-style web Service. See sample: Routing Based on Web Request.


IRD Object Name Composer Block Name Description


Assign Assigns a computed value/expression or a literal value to a variable.   Variables are defined in the Entry block. Capable of multiple assignments.
Call Subroutine Subroutine Creates reusable sub-modules.
Entry Entry Sets global error (exception) handlers. Defines global variables (see Variables section below).. All routing strategy diagrams must start with an Entry block.
Exit Exit Terminates the strategy and returns control back to calling workflow in case of a subroutine.
Error Segmentation Multiple error output ports can be created in Composer blocks based on each block's Exception property.


ECMAScript Builds an ECMAScript expression using the Expression Builder.  Many URS functions are available as Genesys Functional Modules described the Orchestration Server Documentation Wiki Can invoke multiple functions.
If Assign, Branching, ECMAScriptBlock blocks all open Expression Builder Expression Builder can be used to create IF expressions.
Multi-Attach  ECMAScript Can be used for attaching data to an interaction.


IRD Object Name Composer Block Name Description
Selection Target Routes an interaction to a target, which can be Agent, AgentGroup, ACDQueue, Place, PlaceGroup, RoutePoint, Skill, or Variable. Skill target uses Skill Expression Builder.
Percentage Target Order Property Statistics Order property in Target block, lets you perform percentage allocation. Also see sample: Routing Based on Percent Allocation.
Default Default Route Routes the interaction to the default destination.  
Routing Rule   Orchestration Server 8.1 does not support service level routing rules.
Switch to Strategy   Orchestration Server 8.1 does not support switch to strategy routing rules.
Force Route Force Route Not exposed as a routing rule in Composer.
Statistics Target Although statistical routing rules are not yet supported as in IRD's Statistics routing object, users can use the Target object Property Statistic property to route based on the value of a statistic.  A Statistics Manager and Builder let you create your own statistics from URS predefined statistics.


IRD Object Name Composer Block Name Description
ANI Branching See Your First Application: DNIS Routing for an example.
DNIS Branching See Your First Application: DNIS Routing for an example.
Date Branching See the sample: Routing Based on Date and Time.
Day of Week Branching See the sample: Routing Based on Date and Time.
Time Branching See the sample: Routing Based on Date and Time.
Classification Segmentation Branching For classification segmentation, an ECMAScript function determines if a particular category name or ID exists in the array of category objects represented by an application variable.
Generic Branching Use as a decision point in a workflow. It enables you to specify multiple application routes based on a branching condition.

Also see Context Services Blocks.

Voice Treatment

See Composer Equivalent to IRD Treatment.

eServices Multimedia

See Composer Equivalent to IRD Multimedia.


See Outbound Common Blocks

Context Services

See Context Services Blocks

Business Process

See Interaction Processing Diagrams Overview and Interaction Process Diagram Blocks.

Reusable Objects

In contrast to IRD, which defines variables in a special dialog box outside of the strategy, Composer defines both workflow and Project variables.  

Working with the IWD Business Process (IWDBP)

These topics describe how to work with and adapt the default iWD Business Process (IWDBP) that is supplied out-of-box with intelligent Workload Distribution.

Within this Business Process, from within a routing strategy, External Service Protocol (ESP) blocks are used to invoke methods that reside in Genesys Rules Engine (GRE) (previously these were part of the Business Context Management Service which is part of GRE in release 8.5.0). This approach is used to apply classification and prioritization rules to the interaction.

When a user goes to the Global Task List view in iWD Manager, to monitor the interactions that are in various states, this component communicates with Interaction Server to retrieve the list of interactions and their attributes.

This out-of-the-box Genesys iWD Business Process maps to the iWD state model, allowing you to use iWD-based reporting for other interaction types (for example, you might want to track Genesys e-mails along with other task types, under the same Department or Process).

The Genesys iWD Business Process is completely optional for iWD customers who are using Genesys E-mail, Genesys Chat, Genesys SMS, or even third-party e-mail, SMS, or chat. If the Genesys iWD Business Process is not used, iWD Data Mart and iWD Global Task List functionality may be limited.

For Genesys eServices customers, the Genesys iWD Business Process can be left unchanged if you want to use business rules only. In this scenario, the routing strategies would change. The strategies would use the ESP block to invoke the Genesys Rules Engine. This means that existing Genesys E-mail, Chat or SMS/MMS customers can use the business rules within iWD without having to change their Genesys Business Processes; or, to access some additional functionality, changes can be made to the Business Processes.

References to Genesys Interaction Routing Designer (IRD) can be understood to include parallel functionality in Genesys Composer, where appropriate. There is a summary of the differences between IRD and Composer here.


These pages describe the default iWD business process (IWDBP) that is supplied in the iWD Setup Utility component.

Software Requirements

  • The IWD Business Process that is described in this appendix requires Interaction Routing Designer 8.1.2 or higher.

Other Information Resources

The Universal Routing 8.1 Interaction Routing Designer Help Zip describes how to create, save, import and export a business process, and how to load the strategies that comprise the business process.  

When Interaction Routing Designer (IRD) starts up, it checks for an eServices solution installed by the eServices Configuration Wizard. If none is found, the IRD main window does not contain an Interaction Design shortcut bar. You cannot navigate to the Business Processes list pane or open the Interaction Design window. To change the default, use the Views tab in Routing Design Options, which opens from the Tools menu. Clear the default check box and click OK.

Configuration of List Objects

The iWD Business Process (IWDBP) uses two Configuration Server List Objects (the List Object referring to BCMS in releaseses up to 8.1.1 is no longer required).

  • The first List Object, Iwd_Esp_List, has two lists.
    • The first maps the iWD Solution ID to the name of the Genesys Rules Engine application in Configuration Server.
    • The second list maps the iWD Solution Runtime ID to the name of the Universal Contact Server (USCS) application. This is optional, and is used to allow the business logic in IWDBP to update the interaction record in the UCS database to mark the interaction as done (that is, the value of the Status column in the Interaction table will be set to 3) when it enters the iWD_Completed, iWD_Rejected, or iWD_Canceled queues.
  • The second List Object, Iwd_Package_List, maps the iWD Solution ID to the rules package that will be evaluated when the Genesys Rules Engine is invoked from the IWDBP business process.

Both of these List Objects must be correctly configured for IWDBP to work.

One business process can serve several solutions under the same tenant. The iWD Setup Utility automatically creates these two List Objects for the Solution you indicate in the Setup Utility. In environments with only one solution, no further configuration needs to be done on the List Objects. If you have multiple solutions (or add one at a later time) these two List Objects need to be updated.



The GREServerList list looks like a list of pairs:







Where the Solution ID is the key, and the name of the Genesys Rules Engine Application is the value.


Since release 8.1.1, an additional list, ContactServerList is included. The ContacServerList list looks like a list of pairs:

iWD Solution Runtime_1


iWD Solution Runtime_2


iWD Solution Runtime_3


Where iWD Solution Runtime ID is the key and the name of a Universal Contact Server associated with Interaction Server is the value.

It is very important that the pairs are set up correctly. If, for example, Solution_1 is mapped to ESPService_2 instead of to ESPService_1, business rules for Solution_2 will be applied to all interactions which were submitted by Capture Points from Solution_1. Similar issues will occur if the Genesys Rules Engine application or the Universal Contact Server application are incorrectly mapped.

These key-value pairs in a List Object need to be set up only once per tenant, and can be configured in Interaction Routing Designer (IRD) or Genesys Administrator.

ListObjects IRD.png

List Objects in IRD


List Object Details


The Iwd_Package_List List Object is used to correlate the IWD Solution ID (IWD_SolutionId) to the name of the rule package that will be evaluated when requests are made to the Genesys Rules Engine from the IWDBP business process.

The Iwd_Package_List List Object contains a single list, RulePackageList. Create a new key/value pair for each iWD Solution that you have configured under your Configuration Server tenant, where the key or option is the IWD Solution ID and the value is the Package Name of the rules package.

  Iwd Package List.png

iWD Package List


iWD Business Process

The iWD business process (IWDBP) contains the following strategies:

  • Classification
  • Prioritization
  • Distribution
  • Mark Interaction as Done
  • Removal

The iWD business process contains the following subroutines:

  • DetermineESPServerName
  • DetermineRulePackageName

The iWD business process contains the following queues:

  • iWD_New
  • iWD_Captured
  • iWD_Queued
  • iWD_Canceled
  • iWD_Rejected
  • iWD_Completed
  • iWD_ErrorHeld

The Interaction Queues that are included in the out of the box IWDBP business process must be present, and the names should not be changed. The Global Task List looks for specific Interaction Queue names, as they appear in the business process (such as iWD_New and iWD_Queued ). If you modify the business process to add additional queues or rename existing queues, the interactions display in the Global Task List with the status Queued.


IWDBP Main Process

The above screenshot shows the entire business process as it appears in the Interaction Design window of Interaction Routing Designer.

The group of objects on the left-hand side are part of the “Main Flow” of the business process. The group of objects on the right-hand side represent the “Archiving” section of the business process.

Modifying the iWD Business Process

For most environments, the only modification that will need to be made to the iWD Business Process is to the Distribution strategy. The recommended approach to doing this is:

  1. Add a new strategy into the iWD Business Process
  2. Replace the connection from iWD_Queued/All view to the Distribution routing strategy with a connection from iWD_Queued to your own routing strategy where distribution logic is described.
  3. Link your new distribution strategy to the out of the box iWD_Completed queue.

By modifying the business process in this way, rather than simply updating the provided Distribution strategy, you can easily import any new versions of the iWD Business Process that might be available in the future (the links will have to be reestablished to your own distribution strategy).

You can also add additional interaction queues into the IWDBP business process, based on your business requirements. However, keep the following points in mind:

  • The iWD_Queued queue must be present for Data Mart to properly count interactions/tasks. You can add other queues to the business process, but only after interactions have passed through the iWD_Queued queue.
  • Data Mart can properly determine when to consider a task as complete, only if the final queue in the business process is one of the following:
    • iWD_Rejected,
    • iWD_Canceled,
    • iWD_Completed


This page was last edited on August 21, 2014, at 15:45.
Comments or questions about this documentation? Contact us for support!