Last Updated on November 19, 2022 by maximosecrets

Solutions are used as a knowledge base and can be searched by end users from the Self-Service module. This article will cover all aspects associated with Solutions.

Solutions Application

In the article on Incidents and Problems we used the Create Solution action to create solution 1047 at DRAFT status. You cannot see which record created the solution but there are two hidden fields CHANGEBY, CHANGEDATE which should point you towards who created the solution. 

The Solution Statuses are DRAFT, ACTIVE or INACTIVE. It is only solutions at ACTIVE status that can be applied to a ticket. Notice there is no View History action, although there is a SOLUTIONSTATUS object. It would be useful to either configure a View History action, the status history is being recorded, I verified this, or to add CREATEBY/CREATEDATE attributes which you can easily default in Database Configuration.

The users who use the Create Solution action from the Incidents and Problems application are likely to be in the set of users who perform problem management, trying to get to the root cause of the issue. Therefore, it is likely that a Problem Manager reviews incidents, notices several incidents of a similar type, with the same Classification field, and uses the Create Solution action and immediately starts work on it. Therefore, at a minimum I think the CHANGEBY and CHANGEDATE fields should be added to the main tab, below the Self-Service Access checkbox.

Solutions are defined at the System level. There is a persistent ORGID field which could be used, but if so, you would need to adjust the relationships that allow for searching of solutions to include it. In a worldwide business, the same knowledge base records may be duplicated so that they can be retired independently of other organizations. Think of knowledge base records associated with an old version of software, it is unlikely that the new version will be rolled out instantaneously across the globe, so you would need a way of retiring older records, organization by organization.

The Classification field is copied from the Incident or Problem record. It is a good idea to use Classifications and to align them across the three types of tickets and Solutions.

The Type field is useful to add a category of Solution, but you would need to add your own ALN Domain. There is a saved query FAQ – Frequently Asked Questions, which is using this, except when I reviewed the where clause it was (status like ‘%FAQ%’) it should be (type like ‘%FAQ%’). A case has been raised with IBM Support.

There are three long description fields for Symptom, Cause and Resolution which once copied from the Incident or Problem can be enhanced by the Problem Manager, perhaps adding links in the text to external pages. Each of these fields has the Rich Text Formatting toolbar. The Solutions object has a language table defined as standard.

There are four hidden fields FAILURECODE, PROBLEMCODE (Symptom), FR1CODE (Cause), FR2CODE (Resolution) which might be used to link the Solution with the Failure Hierarchy.

The Specifications tab has the Classification and Class Description fields and the Specifications table window. There is a New Row button.

I think the most likely use of the Specification attributes will apply to many Classifications, and so you may want to think about adding the attributes higher in the classification hierarchy and use the Apply Down Hierarchy attribute.

The Advanced Search provides the fields for searching in the Symptom, Cause and Resolution long descriptions.

The List Tab search for ACTIVE solutions and those marked as Self-Service Access shows just four solutions 1007, 1024, 1043 and 1044. It is only these that will show to end users who might be using the Search Solutions application in the Self-Service module.

Search Solutions

In the Self-Service Module there is a Search Solutions action which shows the same four solutions, 1007, 1024, 1043 and 1044. Solutions need to be marked as ACTIVE (or a synonym) and be marked as Self-Service Access for them to be visible in the Self-Service applications. Solutions just need to be marked as ACTIVE (or a synonym) for them to be visible in the Incidents and Problems applications.

I have now marked Solution 1047 as Self-Service Access. Notice that I had also added the Changed By / Changed Date fields below the checkbox.

In the Search Solutions application, five solutions are now shown including Solution 1047. The records are displayed by the Solution ID descending, so that it is likely to pull-up later solutions, but not necessarily the latest to have been made active. You can see that for users to be able to find the right record in the knowledge base they are going to need to search first by Classification, Type, or the Solution Description, and then use the Find button. The Reset button clears all of the Search Solution fields and will then list all solutions that are Active and marked as Self-Service Access.

The Solution Description search performs a search across five fields, the Description and its Long Description, and the Long Descriptions of the Symptom, Cause and Resolution fields.

If you use the hyperlink on the Solution field, you can view the full text of the solution and navigate the list resulting from the query by using the Previous Record and Next Record buttons.

I’ve gone back to Solution 1047 and added a web page link to the CISCO web site. You can see it in the View Attachments dialog, Document ANYCONNECT49.

These web page and document attachments will be visible to end users in the Self-Service Search Solutions application. You can see the same linked document, ANYCONNECT49, and when this is launched the web page is launched in another browser session.

At the bottom of the Search Solutions application there are three buttons to the question “Did this solution help to resolve your issue?”:

• Yes – This creates a Service Request at RESOLVED status
• No – Create a Service Request – this launches the Self-Service Create Service Request application
• No – Return to Solution Search

When you use the Yes button you are returned to your Start Center. However, behind the scenes a service request has been created at RESOLVED status. 

Out of the box, you will have no idea where this has come from and being at RESOLVED status you will probably ignore it. You can see it has the same Classification 1 \ 105 \ 10501 – End User Issue \ Network \ Connection and scrolling further down you would see that the Reported Date would confirm that it had just been created if you had run this test.

I’ve added two fields to the Service Request application – Originating Record and Originating Record Class, and this indicates that this Service Request was created from SOLUTION 1047, i.e. it has been created from the Self Service Search Solutions application as this is the only way a Solution can create a Service Request. 

This gives the ability to see how effective your knowledge base has been at allowing end users to resolve their own issues. If you are performing analysis on how many times a solution was used to resolve an issue, then don’t forget to include a count of the SRs with an Originating Record Class of SOLUTION.

Self-Service Create Service Request

In this scenario we will use the Create Service Request application from the Self-Service module and submit a new service request. From the Service Requests application, we will create an Incident and apply the Solution to the Incident and see whether it appears to the requester.

In the Self-Service module and the Create Service Request application I have entered a test description – “Create SR with Incident and Solution” with details of “This is a test to see what happens if a SR creates an Incident and the Incident is resolved with a Solution.”.

I have submitted the service request.

From the Service Requests application, I took ownership and then used the Create Incident action, Incident 1284 was created. In the Log tab I have used the New Row button and created a log note of type CLIENTNOTE – Introduction – “Hi Mike, I’m Andrew Jeffery and I will see if I can help you with your issue. Just a courtesy call to see that your issue has been received. Regards – Andrew”. The Work Log record was made Viewable so that it should be visible to the requester.

In the Incidents application there is a Solution Details tab and an action to Search Solution. The top Solution 1047 shows a Linked Document that you can view to see whether it is likely to resolve the issue. The View Details button on the left will allow you to see the three long descriptions for Symptom, Cause and Resolution. By using the Use Solution button, the current highlighted Solution is copied to the Incident.

Solution 1047 now appears in the Solution Details tab. The fields from the solution have been copied to the Incident record, it uses the Crossover Domain called SOLUTION.

At the bottom of the Solution Details tab, if you want to allow the Self-Service User to be able to view the Solution you need to mark the field Self-Service Access.

I have followed up with a second work log record of type CLIENTNOTE that I have also made Viewable – Solution found – “Hi Mike, I think I found a solution to your issue from the knowledge base. It is Solution 1047 you should be able to see the details. Do let us know if it fixes your network issue. Regards – Andrew”.

Mike Wilson from the View Service Request application can see the two log notes, the Introduction, and the Solution Found. There is also a Solution 1047 on related Incident 1284. Notice the relationship type is FOLLOWUP, it is referencing that the incident is a follow up to the service request, and not that the solution is a follow up to the incident.

Further down the View Service Request application the user can see the full details of the Symptom, Cause and Resolution long descriptions and the solution attachment ANYCONNECT49, and if they followed the link the CISCO web page would open.

Mike Wilson on the View Service Request can create their own note using the Update Service Request button. The screenshot is the View Service Request Log dialog for viewing log note records. Mike Wilson created a Summary of “Solution 1047 was OK” and Details of “Thanks Mike Solution 1047 was perfect, you can close the incident now.” (He meant to thank Andrew).

Global Issues

In this scenario we will look at what effect declaring a global issue would have on Service Requests that have a relationship type of RELATEDTOGLOBAL to the global issue, when a Solution is applied to that global issue.

On Incident 1284 I have declared this a Global Issue.

I created a new Service Request 1332, submitted it, and in the Service Requests application in the Global Issues section I related SR1332 to Incident 1284, it now has the relationship type of RELATEDTOGLOBAL.

The screenshot is from the top of the View Service Request application in the Self-Service module and is showing SR 1332. 

If I scroll down, you can see the two log notes raised on the Global Incident, but not the log note raised by Wilson on SR 1331 saying that the Solution 1047 fixed the issue. You can also see the link to the Incident record and its solution details and the reference to solution 1047. If I scrolled down further, you would see the linked document on Solution 1047.

I have now removed the solution from Incident 1284 and made an update to the Symptom description. Removing a solution does not remove the text about the solution which is copied to the Incident when the solution is applied.

When I now go and look at SR 1332 in the View Service Requests application, you can see that the Symptom, Cause and Resolution are coming from the Incident record. I added and highlighted in red text in the Symptom field “This is a description that is on the Incident.”. 

In the table window there is no Solution reference and there are now no Attachments. As there is no link through to the Solution it is only the attachments that have been added directly to the Global Incident that would show.

A solution can be added onto an Incident, you do not need to use the Solutions application. The Solutions application may be used more to support the results of the underlying cause investigated in the Problems application, rather than with Incidents, but Maximo is flexible to support either application.

Organizations – Service Desk Options – Global Ticket Solution Options

This Organization option controls whether a Solution applied to a global ticket should also be applied to the tickets which have a Related to Global Ticket relationship. 

You have already seen that a service request that is related to a global incident can view the solution that is applied to that global incident or its Symptom, Cause and Resolution fields. Throughout this time the setting in the OrganizationsA structural element of a Maximo database which is used for data sharing and is often aligned to a legal entity of an organisation. More application has been unchecked and so has had no effect on whether the solution can be seen on the Self-Service View Service Request application.

I have now checked the field “Apply solution to related global tickets?”

To understand what this setting does you need to display the Solution field on the Service Requests application. It is currently blank, I added it in the second column on the right. You can see in the Global Issues section that the service request is related to global INCIDENT 1284.

I have reapplied Solution 1047 to the Global Incident 1284, and it has overwritten the previous text for Symptom, Cause and Resolution.

Service Request 1332 now shows that Solution 1047 has been applied to it.

The business function behind the checkbox “Apply solution to related global tickets?” is to allow analysis to be made on the number of tickets (Service Requests) that are resolved by a solution. Without it you would have to check whether it is related to a Global Ticket and whether a solution had been applied. Analysis of the effectiveness of specific solutions would also be more difficult without this setting. When the setting is checked a KPI could just count the number of Service Requests that referenced a particular solution.

Note. The original Service Request 1331 which created Incident 1284 does not receive the Solution reference, its relationship type to Incident 1284 is FOLLOWUP. A case has been raised with IBM Support because that would make creating an accurate count of the number of issues resolved more complex than it should be.

There is a field on a ticket called HASSOLUTION which is checked when either a solution is applied or when either of the long description fields Symptom, Cause or Resolution have a value. This is also checked on the Service Request with a RELATEDTOGLOBAL relationship to a Global Incident, that has values for either of the three long description fields or an applied Solution. It is not checked when the relationship is FOLLOWUP, i.e., it is unchecked on the originating Service Request from which the Incident was created.