ITRP_reporting includes audit records

Product sheet

Many customers asked whether the automator is involved in our ITRP_reporting solution or not. No. We use our PowerShell framework to populate the SQL database. Right now, this is the most efficient and effective technology for that purpose.

Audit records

Audit records can not be exported by using the ITRP standard export functionality. Audit data need to be exported via the API. This is the newest capability of our reporting solution.

For what purpose do you need the audit records?


  • How often have tickets changed assignments / Service Instances?
    • If your Service Desk follows a “Capture, structure, solve or assign (change the Service Instance in ITRP)” approach, it tells you how well the Service Desk performs in terms of narrow the issue down to the root cause, when they structure the ticket
  • How often has a ticket being touched?
    • Depending on detailed data this could be an indicator of working not efficient or people are simply not trying to solve the ticket in one go.

Easy to generate standard dashboards

Our PowerShell framework normalizes the database automatically, including the audit tables. Based on that easy to use structure it is easy to generate dashboards in PowerBI or another tool of your choice instantly.


Product sheet



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.





Lift the CMDB to a completely new level


The CMDB (Configuration Management Data Base) in ITRP can not only be used for ITIL’s definition of a CMDB but also to provide configuration parameters for automator packages. That way you can specify the specifics of your automations in ITRP.

Business case

Especially service forms add major capabilities to ITRP’s Self Service. Recently I released the Service forms blog post. There the automator provides a simple wizard and saves the customer entries in the request module and provides a couple of other automations like adding the person if the person can not be found in the people module and so on.


Advantages of that approach

There are several advantages for ITRP administrators:

  • Configure the behaviour of Service forms within ITRP
  • No coding necessary
  • Maximize the business value with one automator package

Real world examples

  • Structured surveys
  • ITRP wizard – step by step easy to use Request Fulfilment front end for customers
  • CI based Self Service form


Automator service forms can be configured for different purposes by using the ITRP CMDB. That way business benefits can be maximized in an easy way.

ITRP projects and Kanban


Project implementation teams and maintenance teams certainly benefit from agile methodologies because it mainly reduces confusion and offers transparency. The benefits of Kanban are:

  • transparency in the context of project progression
  • transparency in the context of pressing problems
  • faster task completion
  • lower resistance during adoption
  • faster non bureaucratic response to changes

Kanban itself is not a full project management method – it is more of an idea of how projects could be managed by the team itself.

IT people appreciate that they can respond to changes quickly, that they can easily iterate and that they select what to do, so it gives them more autonomy.

On the other hand, a flexible system like Kanban can make it difficult to focus and push a project to completion if not careful enough. There is less set in stone, and no process to make sure the project is continuing smoothly – so it easily happens that a project loses direction.

Combine traditional project management with agile

To have more control over projects it might be a good idea to combine traditional project management with agile.



That way the business or business representatives in IT control the input and output factors of the agile development and can make sure to not loosing direction.

IT people can work with their Kanban system and appreciate the flexibility.


Agile alone might not be enough. Traditional alone might not work either, because IT people work not at their best if too much control is enforced. So combining both, might be worth a try.






During our first automator steps we introduced a “JavaScript – like” language to script automation packages. This was a necessity because of our execution engine back then.

After a year of automator experience we decided to adapt a different by far more powerful execution engine and pure JavaScript in its version V2016.


What does it mean from a business perspective?

  • Every JavaScript developer can write automation scripts after a short introduction.
  • If you decide to cancel your automator subscription, you can simply take the automation scripts and use them in your own environment. Only small parts have to be added by your JavaScript developer.

What does it mean in technical terms?

JavaScript developers can make use of the following possibilities:

  •  Base language features
    -> Variable declaration with var, let, const
    -> if and else with {} Blocks
    -> let x={}; Blocks to create new data objects
    -> for, for of, break
    -> while, do.. while
    -> switch
    -> regex
    -> template Strings
    -> Block and line comments
    -> functions (named, anonymous, self calling, nested)
  • Base functions like
    -> isFinite, isNaN
    -> parseFloat, parseInt
    -> decodeURI, decodeURIComponent
    -> encodeURI, encodeURIComponent
  • Base objects like
    -> Math, Number, Date
    -> Infinity, NaN, undefined
    -> true, false
  • Standard Operators like
    -> Logical Operators (==, !=, <, >, <=, >=, ===, !==, ||, &&)
    -> Math. Operators (+, -, *, /, %)
    -> Ternary Operator (condition?then:else)
  • Default set of functions:
    -> stringify and parse – for JSON handling
    -> log, logError, logVerbose an logDebug
    -> date and moment – to create a Date and Moment object
    -> newMap and newSet() to create the Map and Set Objects
    -> setProperty and getProperty to access a property by its name
    -> isNull, isArray, checkNull
    -> uuid, atob,btoa, encodeHTML, decodeHTML
    -> formatdate, formatDateTime, formatNumber, …
  • HTTP, REST, GRAPH, MAIL, Proxy functions
    -> http functions that can be used e.g. for SLACK integration
    -> rest functions can be used e.g. for JIRA integration
    -> graph functions can be used for Office 365 & Sharepoint integrations
    -> proxy functions that can execute powershell scripts on premise
    -> In detail:
    -> http_get, http_post, http_put, http_patch, query_stringify
    -> rest_get, rest_post, rest_put, rest_patch
    -> graph_get, graph_post for office 365 access
    -> sendMail
    -> executeOnProxy
  • ITRP functions
    -> fetch, fetchAll, fetchFilter
    -> update, create, deleteItrp for Itrp Accounts
    -> addNote, addApprover, link, mergeAudit
    -> isUserTokenValidInAccount, hasUserTokenRoleInAccount
    -> exportPromise, importPromise, waitForPromise
  • Template Management
    -> templates now support the smart {{variable}} style
    -> templates allow ASP style development (<%=variable%> and <% /* code */ %>)
    -> templates can only access global package variables
    -> text in variables can be used as template now
    -> in detail:
    -> createTemplateTextMail, createTemplateHTMLMail, createTemplateText
    -> textFromTemplate, subjectFromTemplate,
    -> bodyFromTemplate, bodyFromTemplateText
    -> useContentAsTemplate
  • NOT implemented
    -) Use of classes, and therefore no use of the “new” keyword
    -) Asynchronos calls or use of functions – all is handled synchrone
    -) continue is not allowed in loops
    -) All elements that are not listed above


Every JavaScript developer is now able to develop automation packages within the automator framework. Workflow automation is now easier than ever.

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




Advanced trusts


Business case

Some ITRP customers run the premium ITSM application on-premise for different reasons. The implementation partner and the support Organization of ITRP have their accounts in the cloud.

The question is how to pass ITRP related requests to the implementation partner and the support Organization of ITRP?

Automator – advanced trusts

techwork faced the same situation with the setup and its customers. The challenge we faced was to pass requests/tasks from an customer account to our cloud account as flawless as within ITRP (trusts). Hiding the complexity for our customers was of course an additional important factor.


Standard packages

The automator packages that are needed for this are developed in a generic way. You can just plug in the 2 automator packages

  • Sync – cloud to onpremise
  • Sync – onpremise to cloud

and experience it working in less than an hour.





Surveys in ITRP | Option 2 Survey Monkey


In the context of surveys we provide 3 different options:

Survey application Anonymous results? Approach
automator Service Form No Survey result is saved in the custom data field of the linked request. Read more.
SurveyMonkey Yes The automator collects at a configured time the results and stores the aggregated results in a specific ITRP record.
Google forms Yes Similar to SurveyMonkey.

The process


Design:  is done in SurveyMonkey. Surveys are already beautifully designed and you can use a wide range of components.

Connect:  SurveyMonkey and the automator need to be connected. Whenever the automator triggers a survey the link to the SurveyMonkey form is sent out to the customer/end-user.

Get responses: People provide feedback. Details are stored in Survey Monkey. You can start using SurveyMonkey analytics.

Collect: The automator collects already aggregated results periodically based on your insight needs.

Gain insights:  The techwork ITRP_reporting solution automatically provides normalized ready to use SQL fields and tables including the collected feedback/survey data. You can instantly use the data in PowerBI, Excel or other Reporting and Business Intelligence solutions.