Graphical User Interface to create automator packages

automator-logo

Business case:

Until now the only option to generate automator packages was to write code. The automator code is easy to learn and very efficient, meaning that with a couple of lines you can achieve great things.

However, some people don’t like to code. For that reason we created the graphical UI to create automator packages. We call it the automator-editor. In that early version the automator-editor generates the code for you.

automator-editor

Despite many pre-developed components like “send Mail” or “Custom Data” you need to know 2 things:

  1. What do I want to achieve?
  2. and a basic understanding of how algorythm work…

Conclusion

The techwork automator enables everybody with a basic knowledge to create automator packages for ITRP and soon for other applications with a REST API.

k.konwalin@techwork.at

 

Summary pdf for the accounting department

automator-logo

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:

In some organisations the accounting department needs a pdf file after an order has been executed. With ITRP this is easily achievable via an approval task because such tasks send a summary pdf file to the approvers.

However, there is no need for the accounting department to approve or reject something because the goal is simply to get the pdf file in an email – in that sense it is of course a workaround. To achieve this, the automator automatically completes the “Purchase – Order summary to accounting” task automatically, therefore no human interaction is required. In my example this is done via the user “Howard Tanner”. In a live environment we use an “Automation” user instead of “Howard Tanner”. Further we pretend that and “Chet Baker” works in accounting.

PO_summary2.png

The pdf file “Chet Baker” (accounting) gets

change_summary_pdf

The automator package to complete the task automatically

The package is executed whenever the task “Purchase – Order summary to accounting” changes from “Registered” to “Assigned”.

/***** Begin send pdf to the accounting department *****/

mergeAudit(task);

if (task.template.id == $Summary_pdf_to_Accounting &&
task.audit_is_changed_status && task.audit_new_status== 'assigned') {
update('tasks', task.id,{
note: '``` Completed by automation - Summary pdf sent to Chet Baker ```',
status: 'approved'
});
}

/***** END send pdf to the accounting department *****/

Note

This automation package takes 5 minutes to write. Without the automator nobody would probably automate this simple task. Some would probably choose to complete it manually or forward an approval email from someone else.

k.konwalin@techwork.at

 

Relink Incidents from a Problem to a Change

automator-logo

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 Incidents linked to a Problem makes sense for the team investigating the root cause of a Problem because Incidents may provide important information. By the time the Problem is solved all related Incidents should have been completed  – a workaround provided by the problem record should have helped.

Implementing the solution for the problem in the production environment is often done via a Change. Therefore a Change will be linked to the Problem.

An Incident can be linked to a Problem or to a Change. For the Change manager and the Change team it might be of importance to  have the Incidents linked to the Change.

With a short automator script the Incidents are relinked as soon as a Change gets related to the Problem.

mergeAudit(problem);

if (problem.audit_is_changed_change && problem.audit_new_change) {
  foreach(req in problem.requests) {
    update('requests', req.id, {
      problem: null,
      change_id: problem.change.id,
      internal_note: '``` -- Relinked from Problem: '
        + problem.id + ' to Change: ' + problem.change.id + ' --```'
    });
  }
  update('problems', problem.id, {
    note: '``` -- Requests relinked to Change: '
      + problem.change.id + ' --```'
  });
}

What it does:

The script looks if a Change is newly linked to the Problem. If yes each Incident (‘requests’) gets updated with a ‘null’ Problem value. The link to the problem is now cut. The new link created via the change_id relinks the Incident to the Change. To make it easier for the IT staff an internal note is added to each Incident indicating that the Incident has been ‘Relinked’ from the Problem to the Change. The Problem gets a note too.

Any variation is possible. For some organisations it might be of value to relink only open Incidents to the Change, for others all.

The script with comments:

//get Audit data of the Problem that is being updated
mergeAudit(problem);

//New change linked to the problem?
if (problem.audit_is_changed_change && problem.audit_new_change) {
  //run through all Incidents(request) linked to the problem
  for(let req of problem.requests) {
    //update each request. Set the problem link to 'null' and relate
    //each request to the change and add an internal note
    update('requests', req.id, {
      problem: null,
      change_id: problem.change.id,
      internal_note: '``` -- Relinked from Problem: '
        + problem.id + ' to Change: ' + problem.change.id + ' --```'
    });
  }
  //update the problem with a note too
  update('problems', problem.id, {
    note: '``` -- Requests relinked to Change: '
      + problem.change.id + ' --```'
  });
}

Interesting to note:

The Internal_note field is updated of each of the Incidents, therefore the user does not see the note in Self Service.

k.konwalin@techwork.at

 

 

Dynamic approvers for a purchasing process

automator-logo

Prerequisites:

  • You already have an ITPR demo account or a production 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:

In ITRP it is easy to design business workflows. For instance purchasing processes are implemented using change templates and related task templates. In some companies an additional approver is required if the value exceeds a certain amount.

In my simple example the chief controller “Matt Leach” is added as an approver if the investment exceeds 50.000 Euros otherwise Matt is not part of the process.The automator code is as usual very simple:

AddApprover

I created a purchase request worth 60.000 Euros. This is how the task list looks like before I start the change:

Automator_task_approval

Now, the change has been started and Matt Leach has been added by the automator package as an additional approver. Of course, the “Purchase Automation” task has been completed by the package too…

automator_task2

The code with comments

Automator_task_appr2

Interesting to note

The webhook event I chose is task.status-changed. I could have used task.update as an alternative. However, using task.update needs a couple of additional lines and mergeAudit is necessary to check wether the status changed or not. In addition the task.update webhook triggers each time a task is beeing updated.

Therefore task.status-changed is much more efficient.

k.konwalin@techwork.at