Introduction to Workflows

Workflows provide the flexibility of the Trustbuilder platform.  A workflow is made up of a number of activities that are linked together by connections. 

A workflow is executed from its initial state to its final state.  

The route through the workflow is determined by returned values from scripts. So a return value matches a connection value/label, that determines the route and executes the next activity.

Workflow Elements


A Connection is a link between two other elements. It marks the route that the workflow can take. Each connection can be given a Label and a Value (by right-clicking on the connection).

The Label is for display purposes, whereas the Value has to correspond to an element's output value, for this connection to be followed.  
As best practice, define the same 'value' for value and label. If no value is specified, the workflow takes the label into consideration. 


A condition evaluates one or more input parameters, and determines the outcome of a decision as to which step to execute next.  

A condition will always return a single value, which will determine the route to follow.  This value is marked on the exiting connection.  Connections marked "otherwise" are followed when no other connection can be followed.


A piece of Javascript code which is executed. This can execute anything.

Each activity in a workflow (adapter, component, condition, sub-workflow, script) can have a script related to it to process, for instance, a response from an adapter.

Say we have a JDBC adapter that does a query the response from the query is read in a script and processed possibly then set to data or a template.


Templates are used within scripts to return, for instance, an html page or a JSON message to the client.

In that sense, they differ from Templates within the scope of IDHUB. Which are used as pages used by the gateway/orchestrator for rendering, for example: password/login pages,  IDP selection for a specific SP, etc.


Components are pre-configured complete configurations. They can contain adapters, services, workflows, scripts and a configuration of their own. The scripts within a component are, however, not configurable.

A Component activity is created within a workflow and is called as a step in the workflow. So a component might do a task such as validate a certificate against certificates within a certificate store, for instance. All the logic and scripting will be contained within the component, but it can be configured for urls, ports and such. 

The workflow will call the component and continue with its response.


Services are a way to interact with 3rd party code from within a workflow run by the TrustBuilder Core. 

A service is a wrapper around a java library, that is then exposed to scripts within the workflow. This way the java code can be called directly from the scripts.

There are also several packaged services within TrustBuilder that expose Java methods; Eg. date and time, or encryption.


An adapter is used by the TrustBuilder Core within a workflow to connect to any resource. This could be a call to an LDAP server or a call to a database to get details of a user for instance.

Within the adapter such things as connection URL/port or datasource name or JDBC URL or database username password are configured. 

An Adapter Activity in a workflow is a refence within a workflow to a pre-configured adapter.

Usage in TrustBuilder

Workflows can be created to serve several purposes. Below we have listed the different ways workflows can be used within TrustBuilder/IDHub.

Derived Attributes

Applies a workflow to derive a new User Attribute from other attributes.   Derived attribute workflows are executed when the user session changes. 

A simple example is to derive the Full Name from the First Name and the Surname.

Internal IDP

Applies a workflow to authenticate and/or authorize a user. 

For example, a company has several Active Directories (AD). For any given user, they don't know which AD to look into. The workflow will look in each AD separately, and may even store which AD the user can be found in as an attribute. The workflow can reuse this attribute to make future look-ups more efficient.

HTTP Request Handling

A stand-alone workflow can handle any kind of HTTP request, execute logic and make a response.  

These workflows are accessible by the path /idhub/tb/{workflowname}

Session Workflow

Go to: Settings -> Authentication -> General -> Session Workflow ID

The session hook is called by IDHub when a session is created or destroyed. This allows you to create custom logic whenever one of the actions above occurs. 

An example when this is used is to destroy an ISAM session. The workflow adds additional headers in the response.

Was this article helpful?
0 out of 0 found this helpful



Please sign in to leave a comment.