Last Updated on November 19, 2022 by maximosecrets

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

• 1014 – SR Acknowledgment For New Email SR
  • A simple acknowledgement of the Service Request, there are no recipients. This could be used as a default for the Template field with a little bit of configuration in Application Designer to add a defaultvalue property, https://www.ibm.com/support/pages/default-comm-template-each-application

Incident Communication Templates

• 1005 – SR Acknowledgment via Incident
  • A simple acknowledgement of the Service Request but raised from the Incidents application. The Subject and Message has relationship bind variables that are looking back to the originating record. There are no recipients.
• 1006 – Requestor Status Advisory
  • An advisory email sent from the Incident application when a solution has been applied. The Message has relationship bind variables from both the SR and Incident records. There are no recipients.

Incident SLA Communication Templates

• 1001 – Incident Resolution Expiration Advisory
  • Used by SLA 1001 and Escalation 1026 to provide a Resolution Expiry 1 hour before the Target Finish date is reached. The Escalation is the INCOWNER (Incident Owner) role. 
• 1003 – Incident Response Time Expiration Advisory
  • Used by SLA 1001 and Escalation 1026 to provide a Response Expiry 10 minutes before the Target Start date is reached. The Escalation is the INCOWNER (Incident Owner) role. 

Incident Escalation Templates

• 1002 – Incident Resolution Time Expired
  • An advisory to notify the Incident Owner (INCOWNER) that the Resolution Time (Target Finish) has expired. Could be easily added to an Escalation.
• 1004 – Incident Response Time Expired
  • An advisory to notify the Incident Owner (INCOWNER) that the Response Time (Target Start) has expired. Could be easily added to an Escalation.

Global Ticket Communication Templates

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

For SR object

• SRTGTEMP – Template used to generate an e-mail regarding global issue
  • This template would be modified before use. It is used to show how an email can be sent to the Service Requests which have a RELATEDTOGLOBAL relationship to another Service Request that is marked as a Global Issue. It uses the two roles SRTGAFCUSR, SRTGRBCUSR to send an email to the affected users and reported users respectively. The recipients are on blind copy (bcc).
• SRTGSOL – Template used to generate an e-mail to distribute solution details
  • This template would be modified before use. It is used to provide the solution applied to the Global Issue (a Service Request) and is sent to the Service Requests which have a RELATEDTOGLOBAL relationship to this Global Issue. It uses the two roles SRTGAFCUSR, SRTGRBCUSR to send an email to the affected users and reported users respectively. The recipients are on blind copy (bcc).

For Incident object

• IRTGTEMP – Template used to generate an e-mail regarding global issue
  • This template would be modified before use. It is used to show how an email can be sent to the Service Requests which have a RELATEDTOGLOBAL relationship to an Incident that is marked as a Global Issue. It uses the two roles IRTGAFCUSR, IRTGRBCUSR to send an email to the affected users and reported users respectively. The recipients are on blind copy (bcc).
• IRTGSOL – Template used to generate an e-mail to distribute solution details
  • This template would be modified before use. It is used to provide the solution applied to an Incident marked as a Global Issue and is sent to the Service Requests which have a RELATEDTOGLOBAL relationship to this Global Issue. It uses the two roles IRTGAFCUSR, IRTGRBCUSR to send an email to the affected users and reported users respectively. The recipients are on blind copy (bcc).

For Problem object

• PRTGTEMP – Template used to generate an e-mail regarding global issue
  • This template would be modified before use. It is used to show how an email can be sent to the Service Requests or Incidents which have a RELATEDTOGLOBAL relationship to a Problem that is marked as a Global Issue. It uses the two roles PRTGAFCUSR, PRTGRBCUSR to send an email to the affected users and reported users respectively. The recipients are on blind copy (bcc).
• PRTGSOL – Template used to generate an e-mail to distribute solution details
  • This template would be modified before use. It is used to provide the solution applied to a Problem marked as a Global Issue and is sent to the Service Requests or Incidents which have a RELATEDTOGLOBAL relationship to this Global Issue. It uses the two roles PRTGAFCUSR, PRTGRBCUSR to send an email to the affected users and reported users respectively. The recipients are on blind copy (bcc).

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

• SRTGAFCUSR – Related to Global Affected Users
  • A SR dataset role GLOBALTKUSER.affectedemail
• SRTGRBCUSR – Related to Global Reported By Users
  • A SR dataset role GLOBALTKUSER.reportedemail

In Incident object

• IRTGAFCUSR – Related to Global Affected Users
  • An INCIDENT dataset role GLOBALTKUSER.affectedemail
• IRTGRBCUSR – Related to Global Reported By Users
  • An INCIDENT dataset role GLOBALTKUSER.reportedemail

In Problem object

• PRTGAFCUSR – Related to Global Affected Users
  • A PROBLEM dataset role GLOBALTKUSER.affectedemail
• PRTGRBCUSR – Related to Global Reported By Users
  • A PROBLEM dataset role GLOBALTKUSER.reportedemail

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. 

• The Subject is – Global Incident :ticketid 
• The Message is – All related to this Global Incident :ticketid tickets :relatedglobaltickets

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

• The Subject becomes – Global Incident 1250 
• The Message becomes – All related to this Global Incident 1250 tickets SR 1273,SR 1292,SR 1293

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.

• Subject is – Global Problem :ticketid
• Message is – Solution :solution has applied to the Global Problem :ticketid and to the following tickets that were related to it :relatedglobaltickets

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.

• Subject becomes – Global Problem 1248
• Message becomes – Solution 1047 has applied to the Global Problem 1248 and to the following tickets that were related to it SR 1273,SR 1293

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