ITRP Workflow transfer Test 2 Production


Business case

Workflows can become complex when considering different stakeholders. Customers usually want to have intuitive Self Service forms. IT teams aim to streamline their activities. Manual and time consuming tasks are low hanging fruits to gain efficiency to free up time for the customer or other more important things.

When it comes to ITRP workflows the transfer from the “” environment to the production environment (“”) is manual. Most people know that finding tiny mistakes during a manual transfer can be time consuming and annoying.


What does one ITRP based workflow usually contain?

In a more advanced form it contains the following components:

  • a Request template
  • linked to a Change template
  • linked to task templates
  • Request-, Change- and Task templates linked to UI extensions

How people approach ITRP workflow configuration:

Everything is developed / configured in the Test environment (“qa”). Components like UI extensions are getting tested during development and at the end of the cycle a couple of test cases are entered to ensure that the whole process works.

Everything is tested and works fine.

Now, the “manual” transfer starts…

and a couple of annoying and sometimes time consuming difficulties. Services, Service Instances deviate between test and production. Teams are not defined. SLA’s need to be created, modified, and the list goes on.

How does the automator help?

The automator’s latest feature lets you transfer selected workflows from production to test and from test to production. That way the environments don’t deviate that much over time. In ITRP language the automator transfers selected Request templates, Change templates and dependencies like Task templates, UI extensions etc.

Intelligence of the automator:
Before a workflow can be transferred the automator analyses the source and target environment. Whenever costs are involved (i. e. ITRP users with a role), contracts (i. e. SLA’s), or IT people could be confused (e. g. teams that do not exist in the production environment) the automator simply creates a manual “to do list” before the automated transfer can be performed. As all required dependencies are transferred additional testing in the target environment is not really necessary, it’s just to gain more confidence.


Goal reached

ITRP developers/configurators save time and can therefore spend more time with customers or refining other workflows.

List of most wanted ITRP integrations @

All the best




Automator mail attachments


Business case:

If you integrate a small service provider via an email interface it is important to send attachments too. Thinking the other way around, attachments from the Service provider have to appear in the ITRP note of the request.


Email out attachments:

Adding a couple of lines of code to your existing mail out package makes it possible to send inline images and non-inline attachments.

// attach all inline images
$mailAttachments = [];
//Exec Engine v1: foreach($note in $request.notes) {
for($note of $request.notes) {
for($noteAtt of $note.attachments) {
        if ($noteAtt.inline) {
                filename: $,
                path: $noteAtt.uri,
                cid: "link-inline" // looks better on apple mail
                //cid: uuid()      // instantly loaded on outlook

//and non-inline attachment of last note
$lastNote = $request.notes.last();
for($noteAtt of $lastNote.attachments) {
    if ($noteAtt.inline == false) {
            filename: $,
            path: $noteAtt.uri
$mailData.attachments = $mailAttachments;

Email in – add attachments to the note:

Adding attachments from an incoming email to the note is even simpler. In that case you just need to add one line to the update statement.




These couple of lines of code help significantly to reduce coordination problems because of missing information.


Mail interface to small external provider 1


Prerequisites if you like to try it:

  • You already have an ITPR demo account. If not, you can easily request one with demo data.
  • You already signed up for a techwork automator demo account. If not, goto the registration blog post.

Business case:

Having a small specialized service provider with a homegrown Service Management tool often rises the integration question. Of course, there are various options. The best one is that the small service provider uses it’s own ITRP account and you simply create a trust.

Sometimes, this is not possible for whatever reason. Easiest is to integrate via email. In my demo example I use GigaTera to showcase that scenario – even though GigaTera has it’s own ITRP account, therefore I pretend they don’t have one.

Now, you probably ask the question, why we need to write a couple of lines of automator code for that and not use the standard ITRP email functionality?
Answer: The requests may go back and forth between the external provider and the internal team and I want exactly the same assignments if information comes back from GigaTera.

How does the request go back and forth?

To the external service provider (GigaTera): The internal team (in my example the windows server team because the affected service instance is “Windows for Email”) simply applies the “SAN1 for Widget Houston” service instance, to assign the request to the GigaTera team. This assignment triggers the automator package that sends the email. I apply the service instance and avoid “manual” Team changes because I want all Service Level agreements to be correct. (Subject of this blog post).

Back from the external service provider: On the other hand the external provider most likely sends an email with information back to us. What I want to achieve is that the Service instance “Windows for Email” is automatically applied alongside the “old” team and member. If a team member was assigned I want this team member to work again on the request. In short the request should have the same meta data as before plus information from the external provider. (Subject of the next blog post).


To achieve that I simply write data to the “custom_data” field. I remember the team id, the member id and the service instance id.  No custom data will be erased or overwritten, we just add data from the audit.

  $custom_data = request.custom_data;
  $custom_data.wdc_team_id =;
  $custom_data.wdc_member_id =;
  $custom_data.wdc_si_id =;

  update('requests',, {
    custom_data: $custom_data


The ITRP record with its custom data:


The complete script:

log('******* External Provider mail interface - create request ********')


if (request.audit_is_changed_team && == $GigaTera_Storage_Team) {
  $custom_data = request.custom_data;
  $custom_data.wdc_team_id =;
  $custom_data.wdc_member_id =;
  $custom_data.wdc_si_id =;

  update('requests',, {
    custom_data: $custom_data

  for(let note of request.notes) {
		$lastNote = note.text;

  $ = '';
  $mailData.subject = 'Widget Data Center - Request #' +;
  $mailData.body.text = 'Requested by: ' + +
  											'\nService Instance: ' + +
    										'\nImpact: ' + request.impact +
    										'\n\n\nLast Note: ' + $lastNote

  $date = date();
  $m = moment($date);
  $tz = $"Europe/Vienna");
  $tzDate = $tz.format("DD.MM.YYYY, HH:mm");

  update('requests',, {
    note: '```' + $tzDate + ' -- Request email to GigaTera has been sent ...```'

log('******* External Provider mail interface - create request END ********');

Interesting to note:


I also write a note to the request with a timestamp to indicate that the email has been sent on a particular date and at a particular time.

The timestamp can be formatted in various ways because the automator integrates the “moment.js” framework. This framework parses, validates, manipulates and displays dates.