Stimulate experimentation

Companies increasingly rely on the automator to perform workflow automations. In most of the cases our consultants develop and maintain automation packages. To constantly deliver high quality, all requirements get CATWOE checked before we start with the technical development. Of course the output gets checked against CATWOE too. During technical implementation consultants use 3 different environments – Development – Sandbox and Production.

In addition to that we implemented the possibility to save versions within each environment in order to encourage experimentation. Encouraging experimentation likely increases the quality and readability of the automation package further.


How does it work?

It is very simple:

  1. Create a new version
  2. Experiment
  3. Whenever you want switch to a previously saved version
  4. Happy!


During the summer 2 – Automator audit report

Following the last blog post, the 2nd major development for the automator during the summer 2017 is the “Automator audit report”.


The purpose is to get a document about automator packages describing the nature of your automations. It can be used for internal and external audits or to get a quick overview about what’s happening.


A side effect is that switching costs get lower again. That means the following: should you ever decide to switch from the automator environment to your own development- and operating- environment your Java Script developer gets a nice overview what needs to be configured. After that your JS developer simply uses the automator package code and develops missing components. Your risk to use the automator is basically zero.


During the summer – physical button

We are going to develop 2 new automator capabilities in Summer 2017.

  • Physical button
  • Automator audit report (will be a another blog post)

Physical button

Everyone can push a button right? We are connecting the physical button to ITRP.


Well, but what could be a purposeful function?

An Example

One example is printer maintenance. Some companies outsource printer maintenance completely i.e. the vendor is changing, maintaining everything except adding paper. Right now, without the button a toner change request could work like that:

  • User goes to the printer
  • Printer is low on toner
  • User contacts the Service Desk
  • User uses another printer
  • Service Desk looks for the Printer Serial No.
  • Service Desk calls the printer company or writes an email

With the button it will work like that:

  • User goes to the printer
  • Printer is low on toner
  • User pushes the button
  • A Service Request in ITRP will be created automatically and an email including Serial No. etc. goes to the printer company, of course automatically


Time and nerves saved for Service Desk staff.

Other Examples

There are many other examples for using such a button. The spectrum goes from ordering Pizza, creating a request because the vending machine run out of coffee to automate orders of spare parts.





Service Forms



Service forms enable humans to add information to be processed by their automations. Not knowing what I am talking about?


Let’s take our favourite ITSM tool – ITRP. Assume you want to get information (register a request) from an unknown customer. This makes sense for organizations/teams operating in the Business-to-Consumer space. Via the automator it is possible to create a record of the customer and register what he/she needs.

Ok. We need to provide the possibility to enter that information. Service forms enable the automator to provide forms and process the inputs.



The screenshot shows the minimal information required to register a person in ITRP.

Tired of reading?

I created quickly a wizard where you can register automation ideas as a working example. The purpose is twofold:

  • You can experience Service forms and the automator right now and completely risk free
  • We get more ideas what we can/could automate

So, just try it

automator goes mobile


Business case

Even automator package configurators are sometimes on vacation. Now, they can modify a package on their mobile phone or tablet.

The animation below shows how the automator looks like on a cell phone. You can switch between packages and modify values.


Graphical components

The graphical components of the automator make configuration on mobile devices possible. Writing code would be a bit impractical.

Graphical User Interface to create automator packages


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.


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…


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