Action Orchestrator System Elements

The following diagram shows the major functional elements of the Action Orchestrator system. These elements are discussed in the sections that follow:


Use Action Orchestrator to automate an IT es by defining a workflow, then running instances of the defined workflow. 
The workflow defines the automation steps (activities), the logic or flow between these steps, and how to flow data from one step to the next.
The engine manages the state and lifecycle of a workflow, bringing it into existence, running its steps, and finally terminating it. During and (by default) after workflow execution, the engine retains information so that operators can view the status of their running workflows.

Related Topics

Creating a Basic Workflow


Action Orchestrator workflows, tasks and several other elements of the functional model can be placed into categories. Categories in Action Orchestrator work just like Microsoft Outlook categories with respect to tagging objects for grouping in the UI. Objects such as workflows can be in multiple categories. For example, a workflow can be both a network best practice and a security best practice.
The Categories feature provides a way to organize your workflows based on your organizational or functional requirements. Action Orchestrator ships with predefined categories but provides the functionality for you to create your own business-specific categories. When creating a workflow, you can assign the workflow to a category. You can also add other categories to a category to create a hierarchy.


Activities are the steps in a workflow. They are customized to perform integration with some environment. Activities can be provided by adapters (binary components in Action Orchestrator) or by automation packs. Therefore both adapters and automation packs can contribute to a particular integration. Workflow activities provide the logic or flow aspects of the workflow. Workflow activities are exposed in the Logic tab of the workflow Editor.

Related Topic

Adding Logic Components to a Workflow


Many workflow logic elements perform tests to control execution. Conditions implement these tests. For example, a Condition Branch can split execution to take one path if a condition exists, and another if it does not. A While Block can iterate execution while a condition exists.
Conditions can also be placed on a workflow trigger, allowing control of situations in which the workflow can run. For example, a scenario might require the workflow to run during two different time ranges, which would require two triggers: one trigger with an 8am-5pm condition and a totally different trigger with a 5pm-8am condition.
There are two basic types of conditions:

Composite conditions

A composite condition builds a compound condition from individual conditions. It allows combining conditions with AND logic, where all of the conditions must be TRUE for the composite condition to be TRUE, or OR logic, where any of the conditions can be TRUE for the composite condition to return TRUE.
Compound conditions can be used in other compound conditions to produce complex logic, such as ((X AND Y) OR (A AND B)).

Account Keys

A account key record stores information about the user security context and passes this information to the adapters for activity execution, event monitoring, and some target operations (such as availability monitoring and discovery). Account Key instances can be shared across targets and workflows. For example, if a single set of credentials can be used to access a set of network devices, only one account key instance must be created. When it is time to change the credentials, users can go to the account keys list and edit the single instance to change the credentials. This greatly reduces the configuration load when credentials tend to change often in some environments.

Account Key credentials can be used in a workflow, but no workflow can retrieve credentials. If your workflow must access credentials, use hidden string variables.

The account key user concept allows the product to implement delegation. For example:

  1. An IT help desk operator comes to Action Orchestrator to run a workflow.

  2. This operator is presented with a list of workflows that Action Orchestrator role-based access control allows them to run. These workflows might include activities that require a level of security permission that the operator does not natively have.

  3. The operator can perform actions as a part of the established workflow that are not possible for them to perform manually.

This concept can also be leveraged to reveal where operators make changes outside of a workflow. By examining auditing logs such as Windows logs for things being done under the operator's credentials rather than the Action Orchestrator  account key user credentials, it is possible to determine how the operator is doing things outside of workflow and determine how to close things down. So a side effect of Action Orchestrator automation is that customers might be able to tighten security in their environment.


Targets are instances created from a target type. For example:

  • A terminal target allows SSH or telnet to some specific network device.

  • A database target allows connection to specific supported databases.

A workflow or activity executes an action within some environment. The specifics of the definition of the connection to the environment are encompassed in the target. For example, a target for:

  • An SSH command might be a specific UNIX system or network device.

  • A database query might be a specific database.

Workflows can restrict the type of target which they can accept. For example, it is not appropriate to run a workflow to change a network device's configuration against a Windows computer.
A workflow acts on a target. This allows the workflow to perform actions against an external tool or environment. Although a default target instance can be specified directly by a workflow, more commonly it is associated to the workflow at run time.
Activities, which are the steps in a workflow (see Activities), can also specify a target. Typically, activities default to use the workflow target, but a step in a workflow might need to happen against a different system than the workflow target. For example, a workflow overall might deal with a network device, but a step in the workflow might need to update a database. Often workflows can determine the target on which an activity may act by using a relationship to the target for the workflow, or doing a query on some data such as a name to find a matching target instance.

Related Topics

Target Groups

Target groups are collections of targets. Often automation might need to run against all machines in a collection, or against one of the machines in a collection. Target groups provide this functionality. 
Adapters can provide target groups to leverage grouping definitions where they exist. For example:

  • Active Directory OU: Customers are frustrated when they must recode their grouping information into yet another product. The Active Directory adapter seeks grouping information where it is defined. For example, an Active Directory target group looks up computers in some organizational unit (OU) in the directory.

  • Target Type group: Using queries of their attributes, the Action Orchestrator provides type-based groupings of targets. For example, use a target group to group all targets of a given type, or to perform additional filtering to pattern match against a field in the target definition.

  • Virtual group: A target group can be a virtual group. Use a virtual group to specify an explicit list of targets, providing the capability to manually select targets and establish group membership. A virtual group can also allow the inclusion of other target groups so that group membership can be defined hierarchically. For example, a virtual group called "Production switches" might include all members of the "Houston data center switches" group as well as all members of the "London data center switches" group, but not members of the "Engineering lab switches."

A default target for a workflow can specify a target group along with a target selection algorithm:

  • Typically, a target selection algorithm chooses one or more members of a target group to specify the target instances on which the workflow will act.

  • At execution time the target selection algorithm resolves the then-present members of the target group and selects a target.

  • When a user or API call interactively runs a workflow ad-hoc (on demand), the user can accept the default target specified in the workflow or override it with a specific target.

  • Where a target selection algorithm resolves to multiple target instances, the engine spins up separate workflow instances for each target. Thus at execution time, a workflow instance has a specific target on which it will act, against which the workflow encodes actions.

Related Topics

Target Types

Target types provide a way to define a service or other IT element that is not represented by any target type provided by an adapter. A target type can:

  • Extend an existing adapter-provided target type

  • Extend another target type

  • Define a completely new target type

All new targets are created based upon a target type. Some target types are 'abstract', meaning they cannot be directly instantiated into targets but are only available for inheritance by other target types. In Action Orchestrator, these target types are marked as either 'creatable' or 'not creatable'.
A target type:

  • Exposes (and inherits from its ancestor target types) properties and inter-target named relationships that can be read and set either manually or by an Update Target activity.

  • Defines property default values.


Workflow instances can come into existence in the following ways:

  • A workflow can be invoked manually.

  • A workflow can be invoked by another workflow.

  • A trigger can fire, which initiates the workflow.

  • A workflow can be invoked using the API call. 

Triggers are events and conditions in the system that determine how or when the workflow will be executed. Multiple triggers can be added that can be initiated when certain conditions are met.

Action Orchestrator supports two types of rule-based triggers: events and schedules.


The Action Orchestrator can monitor for events from the environment, and you can specify triggers that initiate workflows when the subscribed event occurs. For example, an event might be an incoming stop trap or a fault on a UCS system.

Workflow Events

Workflow events allow one workflow to pass an event to other workflows. For example:

  • A Raise workflow Event activity can post a workflow event, and a trigger can monitor for a specific event.

  • A Correlate workflow events activity allows monitoring for an event within a workflow.

Workflow events include elements of the Action Orchestrator functional model so that they are aware of internal schema elements. For example, you can include a target type in your subscription criteria.
Workflow events are exposed in the web service, so an external system can programmatically submit an event to Action Orchestrator. However, the use cases for workflow events generally center more around Action Orchestrator-internal use cases; Advanced Message Queuing Protocol (AMQP) is preferred for external message passing.
For internal use cases, Workflow events have the advantage because they are native and lightweight within Action Orchestrator. It is easy to create message driven architectures within Action Orchestrator using workflow events. Since these events are not persisted to the database, they are very lightweight. Workflow events have the advantage that they do not require external setup and installation, as would be the case with AMQP.


Schedules allow triggering workflows at some time by leveraging another object called a calendar. Calendars define which days something can occur. Calendars can be selected days or sequences of dates such as weekly or monthly, they can represent dates like fiscal quarter end, or they can be combined hierarchically. Schedules then associate a time with a calendar. When the day is in the calendar, the time is evaluated. Times can be explicit or repeating (for example, hourly).


Calendars are reusable for schedules within many workflows. For example, you can define a calendar for Saturdays. When defining a workflow that you want to run on Saturdays, you reference the Saturday calendar. Other examples include a calendar that includes weekends and company holidays when IT might perform scheduled maintenance, or the last week of a fiscal quarter when IT might exclude non-essential automation or deny change requests.
The calendars feature defines the calendar to be associated with a schedule, time, or condition. This feature simplifies:

  • Reusing calendar definitions across workflows.

  • Building complex calendars from other calendars.

  • Viewing the workflows that run based on a specific calendar.


The variables feature provides a storage area for information that is used on a regular basis to avoid having to specify the same information in several places. Data stored in a variable can be altered to affect workflow execution behavior.

Activity Configuration

One of the most common uses of variables is to define activity configuration. Any field in an activity can refer to a variable value rather than an explicit value. For example, you can use a variable to:

  • Specify the target as the machine where an event occurred.

  • Specify the start date of the workflow' operations window as a parameter to an operating system command.

  • Specify a condition, such as a file that should not exist after a job is initially triggered by the arrival of that file where a prior activity should have deleted the file.

Workflow Control Components

Workflows can use variables to define the control components. For example, you can use a variable to define:

  • A Conditional activity to look at the exit code of a prior activity.

  • A While Loop activity to loop until a query fails or loop for a number of times corresponding to a number of objects pulled from a query.

Workflow Parameters

Variables can be parameterized so that a workflow definition can be vague enough to be reused in multiple places and the specifics can remain undefined so that they can be defined by the person or workflow that invokes the workflow or activity.
For example, a workflow called notify server owner might use a variable server for the name of the server that has a problem. The workflow retrieves the email address of the owner of the server and sends an email.
This workflow might be called from multiple places; a step in a server maintenance job fails, so the maintenance job populates the Server variable and invokes the notify server owner workflow. Another workflow might notify the server owner when a backup completes.

Formulas as Variable Values

You can specify a formula anywhere a variable value is used. For example, an operating system command's parameter might be formed from concatenating two variables' values or from parsing the output of a prior command.

Variable Types

Variable type provide a way to define a new user defined variable type that is not represented by any default variable type. All new variable types are created based on system built–in type variable such as boolean, secure string, and so forth., but creating from these system built–in types are not supported.
You can add properties to the new variable type such as Boolean, Encrypted string, Identity, Number, String, and Table or you can add reference to either target or another variable.

  • No labels
Terms & Conditions Privacy Statement Cookies Trademarks