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

 

Mail interface to small external service providers 2

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:

Please find the full description of the business case in blog post “Mail interface to small external provider 1“.

In this post we provide an automator package to read the mail the service provider sends back and stores the information in the note field. What needs to be done?

Minimal requirements:

  • We need to look for the ITRP Request Number in the subject (Request # …)
  • We need to fetch the request in ITRP
  • If the request is there we need to look for custom data to apply the internal Service Instance, Team and Member, so that the request is back in the correct inbox.

 


log('******* Mail back from the external provider ********')

$subjectMatch = mail.subject~'Request #(\\d+)';
$itrpRequestNr = $subjectMatch[1];

if ($itrpRequestNr) {
  $request = fetch('requests', $itrpRequestNr);

  if ($request) {
    $teamID = $request.custom_data.wdc_team_id ? $request.custom_data.wdc_team_id : $WDC_Default_Team;
    $memberId = $request.custom_data.wdc_member_id ? $request.custom_data.wdc_member_id : '';
		$serviceInstanceID = $request.custom_data.wdc_si_id ? $request.custom_data.wdc_si_id : '';
    
    $bodyMatch = mail.text~'([^]*)Your original request description:';
    $providerText = $bodyMatch ? $bodyMatch[1] : mail.text;

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

    update('requests', $itrpRequestNr, {
      team_id: $teamID,
      member_id: $memberId,
      service_instance_id: $serviceInstanceID,
      status: 'assigned',
      note: '```' + $tzDate + ' -- Email back from external provider```:\n\n' + $providerText;
    });
  }
}

log('******* Mail back from the external provider END ********')

 

What it does in human language:

Line 3 and 4: Looks into the subject line of the Email for “Request #” and stores all numbers (digits) after the # in variable “$itrpRequestNr”.

Line 6 and 7: If there is a number stored in $itrpRequestNr then it fetches the request into variable “$request”.

Line 9 to 12: If there is a request stored in “$request” we look in the custom data field for the team id, member id and service instance id and store them into variables.

Line 14 and 15: In the mail body everything above “Your original request description:” is stored in variable “$providerText”. The assumption is that the provider sends the original description at the end of the email. If the line can not be found the whole body content is stored in variable “$providerText”.

Line 17 to 22: Like I described in the last post is to get a valid timestamp for the note. Therefore it will be easy to read when the email came in from the external provider.

Line 24 to 30: It just updates the request with all the data mentioned.

Wrap up

This post and the last post explain how to build a cheap email based interface between ITRP and another Service Management tool. The whole interface takes 2 hours to set up in a live environment.

k.konwalin@techwork.at

 

 

Mail interface to small external provider 1

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 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).

automator_simple_mail_interface

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 = request.audit_old_team.id;
  $custom_data.wdc_member_id = request.audit_old_member.id;
  $custom_data.wdc_si_id = request.audit_old_service_instance.id;

  update('requests', request.id, {
    custom_data: $custom_data
  });
  ...

 

The ITRP record with its custom data:

automator_write_custom_data

The complete script:


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

mergeAudit(request);
log(request);

if (request.audit_is_changed_team && request.audit_new_team.id == $GigaTera_Storage_Team) {
  $custom_data = request.custom_data;
  $custom_data.wdc_team_id = request.audit_old_team.id;
  $custom_data.wdc_member_id = request.audit_old_member.id;
  $custom_data.wdc_si_id = request.audit_old_service_instance.id;

  update('requests', request.id, {
    custom_data: $custom_data
  });

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

  $mailData.to = 'klaus@techwork.at';
  $mailData.subject = 'Widget Data Center - Request #' + request.id;
  $mailData.body.text = 'Requested by: ' + request.requested_by.name +
  											'\nService Instance: ' + request.service_instance.name +
    										'\nImpact: ' + request.impact +
    										'\n\n\nLast Note: ' + $lastNote
  sendMail($mailData);

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

  update('requests', request.id, {
    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.

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

 

 

ITRP monitor+ demo configuration

Prerequisites:

  • You already have an ITPR demo account or a production account. If not, you can easily request one with demo data.

Enabling the ITRP monitor+ in your demo environment:

  • Login as “howard.tanner@widget.com”
  • Password “itrp”
  • Goto Settings / Custom Links

ITRP_monitor_Plus_demo_env

Enable the subscription function:

ITRP_monitor_Plus_demo_settings1

The subscription function is not enabled by default. To enable the subscription function you need to go to settings.

ITRP_Monitor_settings1_1

In order to send out real emails you need to add a webhook and a techwork automator package (or just use one of the the already implemented “ITRP Monitor Subscription…” packages in the techwork automator demo environment). For an explanation please read the ITRP monitor+ mail subscription package blog post.

Preparing the Webhhook

A “request.update” webhook needs to be added if you don’t have already one.

If not or you don’t know how to do that please follow the instruction in the registration blog post.

k.konwalin@techwork.at

 

 

 

Cancel unnecessary tasks

automator-logo

Prerequisites:

  • 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.

Working with the “Personal computer for new employee” template:

IT user

  • Login to your ITRP demo account
  • Login as beatrice.baldwin@widget.com
    Pwd: itrp
  • Click “Submit new request”
  • Select Service “Personal computing”
  • Select “Personal computer for new employee”

PC_for_new_employee_SelfService

  • Press “Save”

IT operations – Change manager

  • Login to your ITRP demo account
  • Login as howard.tanner@widget.com
    Pwd: itrp
  • Go to the Records console / Changes

Records_changes

  • Click on the change “Purchase Request for “Beatrice Baldwin”

Tasks_are_automatically_cancelled

 

 

 

 

 

 

 

 

Without the automator:

Without_the_automator

Without the automator 5+ manual steps are necessary.

Effect:

The unnecessary tasks, “Security badge” and “SAP account” are automatically canceled. The change goes immediately to “implementation” without the delay of manual interference.

Standard approach ITRP workflow automation benefit Potential saving
Change manager has to check the request or change description n/a
Compare it with the tasks of the change n/a
Cancel tasks that are not required n/a
Complete theCancel unnecesary taskstask n/a 4 manual steps saved. Potential manual errors eliminated. Potential time delay (CM most likely does not act instantly) eliminated.
Change runs through automatically