Aegis Workflow 101 - Decision Making

Aegis Workflow 101 - Decision Making

Welcome to Part 6 of Aegis Workflow 101.  Decision support in Aegis allows users to choose how workflows are started, which flows in a workflow are followed and what decisions need to manual intervention by a user at run-time.

Decision Making in Aegis is split into 3 general areas - Conditional Connectors, Triggers and User Input Forms.

Conditional Connectors

Connectors connect between activities in a particular direction and it is always a one to one relationship.  You can have multiple  connectors entering and exiting a single activity, but only one between the same pair of activities.  So far we've only seen standard connectors, also referred to as unconditional connectors.  Now we look at Conditional Connectors, which are basically a standard connector with some rules applied to it.  To view or modify connector rules, double click on a connector to open the Connector Properties.


On every connector, the connector has a Connector Name property.  By default on an unconditional connector the 'show label' tick box is disabled - the connector names are generic 'connector1' 'connector2' etc.  Enabling labels to display the connector name is handy when a condition is set so you have an idea what each condition connector relates to, in fact when you set a condition labels are automatically enabled but this can be overridden by the tick box.

The radio buttons for 'Always traverse this connector' and 'Only traverse this connector when the following conditions are met' decide if the connector is unconditional or conditional.  To create a conditional connector you need to add a filter which as we have seen in previous posts uses input builder so we can make decisions dynamically based on what has happened previously in the workflow.  Conditions can even be created based on which trigger triggered the workitem so you can immediately make a decision to handle the condition in different ways.

When looking at a workflow, visually connectors differently.  Conditional connectors have a diamond shape when leaving an activity while unconditional connectors do not so it is easy to tell them apart.



With your first conditional connectors you normally introduce some nice logic problems and general unexpected results.  Firstly, any time you say "Go this way IF Condition1 is TRUE" you will most likely need another connector which says the opposite "Go this way IF condition1 is FALSE".  This is a bit simplistic, often there can be 3 or more connectors and then you need to make sure all the conditions are correct.

For example : Conditional Connector 4 should be for any condition which does not match 1 - 3.

Conditional Connector 1 : "Go this way if (Email Subject Contains Emergency) AND (Email Sender EQUALS  "theboss@sigea.moc")

Conditional Connector 2 :  "Go this way if (Email Subject Contains Emergency) AND (Email Sender NOT EQUALS "theboss@sigea.moc")

Conditional Connector 3 : "Go this way if (Email Subject Contains Major)"

Conditional Connector 4 : ????

Connector 4 must exclude all the scenarios of 1, 2 and 3.  The easiest way to get this correct is by testing - test each scenario ensuring one connector runs.  The last connector added is most often the most complicated as it must exclude all other conditions.

To make life even more difficult, it could be you actually want to have more than one connector run depending on what has gone before.  This is definitely a case where having a workflow flowchart will help a lot.

So what will happen if no conditional connector exists to match the criteria.  Using the example above, you've created 4 conditions but what if a condition occurs which matches none of them - what then?  The workflow flow that came to that set of connectors will end as it has no connector to follow.  If there are no other active flows in the workflow, the workflow will end, without reaching the end of workflow - this is always an indicator of workflow logic issues as this should never happen!  (Unless you did this by design!).

While 'Endless loops' were a common occurrence with the early versions of the 'For Each' and 'For Loop' activities, we still see endless loops caused by  bad conditions on connectors.  Any time there is a loop in a workflow there is the potential for the loop to run forever if you get the logic wrong on the connectors.  If a connector is setup to exit after 5 runs, you need to make sure that the counter that counts runs is set up correctly - otherwise endless loop!


Triggers, their definition, consumption policy and append / block rules all have big influences on how Aegis will handle incoming events.  These are decisions made before workitems are started and are often harder to understand problems relating to them unless the trigger architecture of a system is documented.  Many times I've dealt with situations where events which are expected to trigger new workitems do not, only to find they have been appended/blocked to a different workitem.  Trigger specifics are looked at in more detail in the Aegis Workflow 101 - Triggers post.

Connector logic relating to triggers generally cone down to  these decisions :

  1. Was the workitem triggered Manually or which trigger triggered the workflow:


2. When an event starts a new flow in the workflow, it could be its initiating the workflow or being appended or blocked to the workflow :


User Input Forms

User Input Forms are a neat feature which allows users to interact with a workflow by using an Aegis generated form to provide some information or request information from a user and then to submit the form with configurable buttons, like 'Approve', 'Deny', 'OK' etc.  The Cancel button does a special operation in that it it does not submit any values and remains running for another input of data.

The workflow designer then needs to provide conditional connectors based on the information provided by the user in the form.  Users can be sent a link to the input form using input builder so you can control the way users input data by using drop down lists rather than risking misspellings in other manual steps like responding to an email.  You don't want to have many input forms though, it can get annoying for people to have to continuously connect back to an input form to progress a workflow.  Input forms can be accessed via the standard web console or via a separate page so none of the workflow data or progress is visible.

In summary then, only the most simplistic workflows contain no decision making at all.   Decision making allows workflows to implement complicated logic, do different operations on data in parallel and control different flows.  Decision making while it may sound easy can often lead to workflow problems if they are not thought out fully.

Next up is: Aegis Workflow 101 - Error Handling!

Labels (1)


Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Top Contributors
Version history
Revision #:
6 of 6
Last update:
‎2020-01-09 16:44
Updated by:
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.