Staff outflow: Provide necessary information at a glance

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:

Within a staff outflow workflow one of the tasks is often that the person who leaves has to return Configuration Items like the notebook and the phone. This saves a couple of clicks and provides instantly what needs to be done.

Staff_outflow_inbox.png

In my example task 21504 is the version without the automator package. The subject of Task 21505 is different. It states the name of the person who needs to return the items. Furthermore the task reflects the CIs assigned to the person.

Staff_outflow_tsk.png

Configuration time:

10 minutes – with 1 iteration.

The automator package:

Picture1.png

Conclusion:

These simple packages do not take long to implement but provide significant value for the IT Staff.

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

 

 

ITRP monitor+ mail subscription package

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.
  • You already configured the ITRP monitor+ in your demo environment. If not, goto the ITRP monitor+ blog post.

Business case:

ITRP currently does not provide a function to send out updates on a request to a person who is not involved at all. However, sometimes C-level managers want to be updated on any changes of major incidents/requests because of its significance. The package below sends out an email to every subscriber. The beauty of the implementation is that the package does not send out an email if subscribers changes.

$request = request;
mergeAudit($request);
$sOld = $request.audit_old_custom_data.monitor_subscribers;
$sNew = $request.audit_new_custom_data.monitor_subscribers;

$mailData = createTemplateHTMLMail('request-watch-all-notes');

if ($sNew && $sOld === $sNew) {
 for($item of $sNew) {
   $mailData.to = $item;
   sendMail($mailData);
 }
}

The email the subscriber gets

ITRP_Monitor_email

The code with comments

$request = request;
mergeAudit($request);

//check who is in the custom data field
//the old value(s) and the updated one(s)
$sOld = $request.audit_old_custom_data.monitor_subscribers;
$sNew = $request.audit_new_custom_data.monitor_subscribers;

$mailData = createTemplateHTMLMail('request-watch-all-notes');

//if new is equal to old then the mail(s) are sent
//
//the line below prevents sending out an email if someone
//subscribes or unsubscribes
if ($sNew && $sOld === $sNew) {
 foreach($sNew) {
   $mailData.to = $item;
   sendMail($mailData);
 }
}

Interesting to note

The mail is not sent, if someone subscribes or unsubscribes even though it is an update of the request. To get that done the “mergeAudit” function is of great help. This function merges audit information into an ITRP object. In our particular case it allows to send the email if anything changes except changes within the monitor_subscribers custom data field.

k.konwalin@techwork.at