The Log tabs on all ticket and work order based applications have two tabs, Work Log and Communication Log. We will discuss the functionality for the Service Requests application, but it is similar for all these applications.
The Work Log has two description fields the Summary and the Details. The Details field is the long description with a rich text formatting toolbar. There is a Type field with four default values WORK, UPDATE, CLIENTNOTE, APPTNOTE (Appointment Note). This is defined in the Synonym Domain called LOGTYPE, and it is frequently configured with more values.
The Viewable checkbox allows the log note record to become visible in the View Service Requests application, in the Self-Service module, i.e. it is what you need to set if you wish the Affected Person to be able to see the log note record that you have created. Normally when you set this you would use the UPDATE type. The Viewable field can only be updated from the record that created it.
The Affected Person can raise their own log notes from the View Service Requests application and in this case the type is CLIENTNOTE, and it will be marked as Viewable. Therefore, CLIENTNOTE should be reserved for seeing the log notes raised by the Affected Person, the client.
The action Modify/Delete Work Log lets you modify or delete the work log records created by the current record, but this action may be reserved for supervisors rather than all users who have access to the application. If that is the case, then for users without the security option the Work Log record will become read-only after save.
The records that you can view in the Work Log are the records created for the current ticket, or those created on the originating record, plus any follow-up tickets or work orders. For example, you created an Incident from the Service Request and a Problem from the Incident to diagnose the root cause, and from the Incident record you also created a Work Order. From the Incident record you can see the work log records created on the follow-up Problem, and Work Order records, as well as those created by the originating Service Request and any work log records created on the Incident record itself.
Further, visibility of the work log records should include those up and down the line of follow-up records. Using our example, the Work Log records created on the Problem and Work Order applications should also be visible on the originating Service Requests and if these were marked as Viewable, then also by the Affected Person from the Self-Service View Service Requests application. Note. This original functionality had been broken for several years and it was fixed in 188.8.131.52 IFIX019.
If the current ticket record is marked as a Global Issue, then the Work Log table will show the ‘Is Global Issue?’ checkbox. It does not appear if the record is related to the Global Issue ticket, i.e. it would not appear on the Service Request that originated the Incident that became a Global Issue.
Work Log records created on a ticket marked as a Global Issue will be visible on other tickets with the relationship type of RELATEDTOGLOBAL to the Global Issue ticket. For example, there could be tens of Service Requests related to an Incident record marked as a Global Issue, all those Service Requests would have visibility to updates made on the Incident record if they had a relationship type of RELATEDTOGLOBAL to it. Service Requests with the RELATED relationship type would not have visibility of the Incident’s work log records.
The Work Log Type of APPTNOTE (Appointment Note) should not be used unless it is a log note specifically about an appointment. Appointments are made on assignments in the Graphical Assignment application, a part of the Maximo Scheduler. It is why there is an ASSIGNMENTID field in the WORKLOG object.
There are two System Properties, psdi.worklog.ticket.useTKrelationship and psdi.worklog.workorder.useWOrelationship which when set to one allows you to create your own rules as to what Work Log records are displayed. There are two Relationships, CUSTOMTKWORKLOG found in the TICKET object and CUSTOMWOWORKLOG found in the WORKORDER object. These are used when the corresponding System Properties is set to one and allows you to configure your own SQL Where Clause to define what records are displayed and override the default behaviour. Note. If you have a large database with millions of Work Log records, if you experience performance issues then these custom relationships are designed to allow you to control the displayed Work Log content to reduce any speed issues that you may be facing. The visibility of Work Log records up and down the line of tickets and work orders has a lot of work to do to fetch the required records.
The Communication Log is a read-only table window of emails attached to the ticket or work order record. There is no New Row button, entries are made in the Communication Log through various actions either manually via the Create Communication action or via background tasks, most often by an Escalation. The Email Listener can also add inbound emails from external sources to the Communication Log.
The action Create Communication is used to send an email to one or more recipients from within the ticket or work order based applications. The dialog that opens allows you to define the To, Cc and Bcc recipients by selecting People, Person Groups or a Role that can resolve to a person or email address. The Send From field defaults to the logged in user’s Primary Email address. The Message field, the body text of the email, has a rich text formatting toolbar.
The email Subject and Message fields can contain bind variables that resolve to single data values taken from the ticket or work order records or their related objects. For example, a Service Request has a location or asset field, and the subject or message text can contain the location or asset identifier, and the description of the location or asset when resolved by looking up a relationship to the LOCATIONS or ASSETS objects. A bind variable starts with a colon (:).
The email may contain one or more document attachments by using the Attached Files button, or web links defined by a URL when using the Attach Web Page button. When the Send button is used if the SMTP host is configured the email will be sent to the recipients and a record of the communication will be visible from the Communication Log tab, otherwise known as the COMMLOG after the object name. Attachments and web links will be visible, they are saved as Maximo Documents and are also visible from the Attached Documents paperclip and View Attachments action saved against the COMMLOG object. A history of communications is therefore retained within the Maximo system against the ticket or work order record.
When a communication record is being created a predefined Communication Template can be selected and applied to the communication to be sent. The recipient list is a little more flexible when going via a Communication Template, particularly when using Person Group Roles where you can broadcast to all members of a person group, or a single person based on their availability.
For Global Issues there are a series of Roles and Ticket Templates that send communications to the set of recipients associated with the Global Issue. The Roles uses the relationship GLOBALTKUSER which effectively says send an email to the person on this Global Issue ticket and all tickets that are directly related to it through the Related To Global fields.
- For a Global Issue Service Request, use Ticket Template SRTGTEMP, that uses Roles:
- SRTGAFCUSR – To send an email to the Affected People
- SRTGRBCUSR – To send an email to the Reported By People
- For a Global Issue Incident, use Ticket Template IRTGTEMP, that uses Roles:
- IRTGAFCUSR – To send an email to the Affected People
- IRTGRBCUSR – To send an email to the Reported By People
- For a Global Issue Problem, use Ticket Template PRTGTEMP, that uses Roles:
- PRTGAFCUSR – To send an email to the Affected People
- PRTGRBCUSR – To send an email to the Reported By People