Ticket Communications (3)

This is the last of the three articles on Ticket Communications and will focus on the Communication Templates and Roles provided for Tickets in the out of the box Maximo system. The illustrations will show two of the Global Ticket Communication Templates in action, one for Incidents and one for Problems, which can be used to distribute solution details to everyone who has raised an issue that has been marked as a Global Issue. The article completes with a couple of System Properties.

The first article introduced the Create Communication action on a Ticket and can be found here – http://maximosecrets.com/2021/12/02/ticket-communications-1/

The second article continued the first with a few more advanced topics, particularly involving a Person Group based Role, and adding attached documents and web pages to the Create Communication dialog. You can find the second article here – http://maximosecrets.com/2021/12/02/ticket-communications-2/

Standard Communication Templates

There are a set of Communication Templates supplied with Maximo.

Service Request Communication Templates

Incident Communication Templates

Incident SLA Communication Templates

Incident Escalation Templates

Global Ticket Communication Templates

There are a set of Communication Templates supplied with Maximo which are used specifically with Global Issues.

For SR object

For Incident object

For Problem object

Global Ticket Roles

The following Roles are used with the Global Ticket Communication Templates that are used with tickets that have been marked as a Global Issue. 

In SR object

In Incident object

In Problem object

All 6 roles resolve to the email and not the person. 

In all 6 roles the relationship GLOBALTKUSER is used. This will be found in the TICKET object and has the definition of (ticketid = :ticketid and class=:class) or (globalticketid = :ticketid and globalticketclass=:class)

This means get this ticket and all tickets that are directly related to it through the Related To Global fields.

Global Ticket Communications

This section will show the results of applying the Global Ticket Communication Templates and Roles.

In the article Service Requests – Related Tickets we created Incident 1250 from Service Request 1273, declared it a Global Issue and attached Service Requests 1292 and 1293 to it so they had the relationship type of RELATEDTOGLOBAL. We also related another Service Request 1291 to Incident 1250, but it had the relationship type of RELATED. You can find the article here: http://maximosecrets.com/2021/10/26/service-request-related-tickets/.

The Communication Template we are going to use is IRTGTEMP – Template used to generate an e-mail regarding global issue. 

In the Incidents application when the Create Communication action is used and the Communication Template IRTGTEMP is selected:

For the three Service Requests referenced, 1273 is the originator, and 1292 and 1293 have a relationship type of RELATEDTOGLOBAL. The :relatedglobaltickets in the Communication Template message is a non-persistent attribute with a class file FldTkRelatedGlobalTickets that constructs the string that includes the class and the related record key from the related records to the Global Issue, Incident 1250.

The two recipients were Tony.Redding@maximodemo.com, Mike.Wilson@maximodemo.com – which are correct, REDDING was on SR 1273 and WILSON was on SRs 1292 and 1293. Notice, they only appear once in the bcc list, although REDDING would have been referenced twice and WILSON four times on the Service Requests.

I am going to change the three Service Requests and the reported by and affected by emails to a real email address so that we can continue through and send the emails.

When you run the Create Communication action a second time the recipients in the bcc are Tony.Redding@maximodemo.com, maximosecrets@gmail.com. Tony Redding is coming from the Incident record, and not the originating Service Request, 1273. The two roles are referencing the relationship GLOBALTKUSER which includes the current ticket and all tickets related to it through the Related To Global fields.

While the message references SR 1273 the recipients do not include the Reported By Email or the Affected Person Email that is on Service Request 1273. However, these two persons are copied onto the follow-up Incident 1250, the one that is made the Global Issue, hence they would still receive the email assuming that the email address on the incident has not changed.

When the Send button is used, on Incident 1250 we received a new log record in the Communication Log tab. We did not receive a communication log entry in any of the Service Requests 1273, 1292 or 1293. 

I at least expected the Communication Log entry to be visible on Service Requests 1292 and 1293 as the whole purpose of a Global Issue is to give over the running on an issue to the record where the global issue is declared, however the members of the Service Desk who are managing the Service Requests with the RELATEDTOGLOBAL relationship should still be able to see those communications without having to navigate to the Incidents application. I have raised a case with IBM Support on this point. With Work Log records you can see the Incident log notes from the Service Requests, so why not the Communication Log.

I’ve created a communication on the originating Service Request 1273 to see whether it is visible on the follow-up Incident 1250. The Work Log records raised on the service request are visible on the incident. The communication from SR 1273 was not visible on the Incident’s Communication Log. I included this as a comment on the case to IBM as in both cases the records you see from the communication log are determined by the COMMLOG relationship which is found on the TICKETS object.

In the next illustration I will look at a Global Issue being created on the Problem application for Problem 1248 which was a follow-up to Incident 1250. We will also add a Solution (1047) to Problem 1248 and use the Communication Template PRTGSOL. Before we do this, I am going to move Service Request 1293 to be related to Problem 1248 as the RELATEDTOGLOBAL relationship type, this will leave Service Request 1292 as being related to the Global Issue Incident 1250.

In the Problems application for Problem 1248 the Related Records tab shows that it was created from Incident 1250 and Service Request 1293 is related to it with a Relationship Type of RELATEDTOGLOBAL.

We are going to use the Communication Template PRTGSOL – Template used to generate an e-mail to distribute solution details.

The bind variable :relatedglobaltickets is a non-persistent attribute with a class file to derive related records.

On Problem 1248 when we use the action Create Communication and select the Template PRTGSOL the bcc is filled with the emails of the reported by and affected persons on the current problem record (Tony.Redding@maximodemo.com) or the tickets with RELATEDTOGLOBAL relationship type (maximosecrets@gmail.com) to Problem 1248.

The attribute :relatedglobaltickets is being resolved down to the Service Requests that originally created the problem via the incident, and other tickets that have a relationship type of RELATEDTOGLOBAL to the problem.

In a further test I changed Service Request 1292 to be related to Problem 1248 and did the same for Incident 1250. The resulting message contained the text “…SR 1273,INCIDENT 1250,SR 1292,SR 1293”.

The Communication Log for Problem 1248 shows the message that was sent to the recipients, note I removed Tony.Redding@maxdemo.com, as otherwise I would have only had my email system try and send the message for the next couple of days. There were no Communication Log records created for other Service Requests or Incidents.

Note. All the email that was sent during this last section were received in my maximosecrets@gmail.com inbox.

System Properties

The System Property mxe.webclient.attachimage – Enable the Attach Clipboard Image button when creating communications is disabled by default. It adds the Attach Clipboard Image button below the Attachments table window in the Create Communication dialog. When used it fails to load a Java applet, you therefore should not enable this System Property, you can use Attach Files just as well.

Java applet support was dropped by browsers and Oracle https://www.ibm.com/support/pages/java-applets-maximo-asset-management-75-and-76. Most of the places across Maximo where Java applets were previously used have been replaced in versions up to Maximo Functionality not replaced would be subject to a Request for Enhancement (RFE).

A System Property that does work is to make the Send From field read-only, it is mxe.commlog.SendFromEditable which is normally set to 1. The description is “Controls editability of Communication ‘Send From’”, therefore a value of 1 means editable, and 0 read-only.

2 responses to “Ticket Communications (3)”

  1. […] Recently I wrote a set of three articles on Ticket Communications and in the third one I had set the System Property of mxe.commlog.SendFromEditable to 0, its default value is 1. The System Property makes the Send From field read-only when set to 0, editable when set to 1. I have now reset it back to 1 and the next time the Escalation runs I get a status of SUCCESS. You can find the article here – http://maximosecrets.com/2021/12/02/ticket-communications-3/ […]

  2. […] Ticket Communications 3 […]

Leave a Reply

%d bloggers like this: