Sequence runner actor
What does the Sequence Runner actor do?
The Sequence Runner actor allows one sequence to be started from another one.
Although the Sequence Runner actor will quite often be used together with the Relation Lookup actor so that an action such as assigning a task or updating a field may be carried out against the parent or child records which the Relation Lookup has identified, (view the guide), there are many occasions when it will be used alone.
The Sequence Runner can be used at any point in a sequence to run another sequence for a sub-process against the same object class. This allows you to keep sequences from getting overly large and therefore difficult to maintain.
How do I use the Sequence Runner actor?
Click, drag and drop the Sequence Runner actor onto your sequence workspace at the point where it is appropriate to start another workflow or sub-process.
Right click on the Sequence Runner actor and select Configure. The Sequence Runner Configuration window will open.
Without a Relation Lookup actor
When used without a Relation Lookup actor, the Record field will contain only one option ie Self.
This means that only sequences for the same object class will be shown in the Sequence selection field AND you will only see sequences which have a starting trigger of "When sequence activated".
Select the required sequence and save the config.
Important: remember to label the starting trigger of the sequence being activated to state which sequence is starting it.
With a Relation Lookup actor
When used with a Relation Lookup actor, the Record field will contain another option, From Relation lookup.
In this case, the Relation Lookup is looking for children of the sequence object class in an object class called "Lender". The Sequence Runner actor will display any sequences for that child object class which can be activated ie they contain a starting trigger of "When sequence activated".
This Sequence Runner will trigger the sequence for all the children that match the relation lookup conditions.
Naming and description
As with all sequence actors, it is best practice to label Sequence Runner actors with meaningful names that reflect their purpose. Particularly with Sequence Runners, it is a good idea to indicate the ID and Name of the sequence they are starting.
Right click on the Sequence Runner actor and select Properties.
Enter in the Name field the ID and Name of the sequence which will be run.
The Description field provides more space where additional information can be stored if needed.
| Save the Properties so that they replace the default actor name and clearly indicate what the sequence Runner is doing. | Screenshot 2026-04-15 at 10.45.49.png |
Example use cases
There are two Sequence Runners in the below screenshot - see the pink actors.
The preceding Trigger will determine whether a Sequence Runner is triggered for any particular record in this execution of the Sequence. By adding Trigger Conditions, you can determine whether this Sequence Runner should apply to all records that reach this point in the Sequence, or to a subset.
A Sequence Runner could be used to activate sequences by subject matter. For example, you could have a starting sequence for intake of a number of different types of matters or claims in which would be included your KYC tasks. You could then use the Sequence Runner to commence different processes for Real Estate, Commercial, Employment and other types of case.
Alternatively, your use case may be to do with the additional legal compliance required when operating in different countries, or screening compliance for working in different sectors - this type of sub-process could be triggered from your main sequence once the common core checks have been completed.
The following example shows how you might use one sequence for all escalation tasks relating to Mortgage Applications. If these tasks are all escalated to one user or a group of users, you can make them the default task assignee(s) when creating the sequence to be activated from the main one.
The above screenshot shows the first few steps of the main sequence. You can see that once data consent has been given in the "GDPR Agreement" task, there are two further tasks:
- Review application - intake
- Check affordability
Both of these tasks require the task owner to make a decision as to whether this part of the mortgage application can be approved, or if it should be rejected or escalated.
The task template for the Affordability Check is shown below.
Each of the 3 outcomes has a very distinct route in the process:
| The applicant meets the affordability criteria - the Application Status is updated to "Affordability passed" and the next task called "Primary terms" is created for the record. |  |
| The applicant DOES NOT meet the affordability criteria - when this option is chosen in the task form a new field is presented where the user can enter the reason for this decision. This input is merged into an email to the applicant(s) informing them of their failure to meet the criteria. The application status is updated to "Application rejected". The process would stop at this point. |   |
Escalate - this is where the Sequence Runner is used.
The first screenshot shows that the application status is updated to "Escalate affordability".
Following this, the Sequence Runner has been configured so that it is looking at "Self" records which means records in the same object class as the current sequence is running against, in this case, Mortgage Applications.
The sequence which the actor will run is one called "Escalations".
The below screenshot shows the part of this sequence which relates to the escalation at the affordability check in the starting sequence.
The trigger configuration is set to "When Sequence Activated". However, because this sequence is activated for more than one type of escalation, there is a supplementary condition which is looking for records where the field "Affordability check outcome" is equal to Escalate.
If a record matches this condition, a task called "Affordability Check - escalation" will be assigned. This check has two possible outcomes:
Affordability failed - the application status is updated to "Application rejected"; an email is sent to the applicant(s) to let them know of their failure to meet the criteria. The process would stop at this point.
Affordability approved - the application status is updated to "Affordability passed". An email is sent to all record owners to advise them of this outcome.
Going back to the starting sequence, because the task "Affordability Check - escalation" was of the "Update object record" type, the field where the outcome was recorded can be used to rejoin the main process at the appropriate next stage.
The sequence trigger is "When Record Updated" with a supplementary condition using the field which was updated in the escalation task. Following this update, the "Primary terms" task is created for the record.
The process will continue through the main sequence workflow.
Useful info
- There is no limit to the number of sequence runners you can use in any one sequence or any one instance of Catalyst.
- A Sequence Runner is a terminal actor (it cannot be used to trigger any later actor).
- Only a single actor can trigger a single Sequence Runner. If you have two branches in the sequence that could trigger the same sequence and have no shared final actor in those branches, you will need to duplicate the Sequence Runner actor once for each actor that could trigger it.