Managing Notifications from Incidents, Work Orders, Purchase Orders, etc. can be challenging. The two most popular ways to generate Notifications are through Workflow (they can be sent out on any action node) or through Escalations. Often, we don’t want to send the email to just one person, it will have to go to a specific Role that might be recorded on the transaction, e.g. Approver on a Purchase Requisition or Lead on a Work Order, but this could also be related to the User logged in e.g. their Supervisor. If a group of People need to be informed then Person Groups provide this functionality and also defaulting based on Organization, Site and Shift.
Notifications Using Workflow and Escalations
The Workflow or Escalation triggers the Notification, the format of the email is determined from the Communication Template as is the Role, which determines who the email is sent to and this is based on the Transaction, the User or a Person Group.
However, this can still be limiting. Also this requires that the details be maintained by either Maximo Support or Business Administrators as we generally don’t give general users access to do this.
The Use Case
The example situation that we were faced with was related to emails being sent out for Incidents & Investigations when they got to a particular Status. Half of the recipients were not users of Maximo but we did have an email address for them. Also different people got emails based on the Unit and the Priority. For example, one person got all Incidents and Investigations for All Units regardless of Priority, yet another might get an email for a specific Unit and only when Priority was greater than 4. There was one format of email for Incidents and one for Investigations.
This was originally set up when there were only a few Units but as time expanded the list of possible Units grew to over 40. Units are set up in the Location Hierarchy and a record at any of the child Locations needed to also generate the email. Given all the possible combinations there where over 180 Escalations and Communications Templates involved.
This was clearly unsustainable and if a change was required then it needed to be done by Maximo Support. What was required was a much simpler solution and also to allow Users to decide on their own Notifications, we called these Subscriptions as user could pick and choose. Also, Business Admins were allowed to change Subscriptions on behalf of other Users and People (i.e. those without their own Maximo login).
The Solution
Firstly we need somewhere to store the email addresses and the obvious choice is the Person record, where there was no User Id (these were synced with LDAP) we created a Person record.
Now we had to decide where to store the Subscriptions, we had to be able to specify a top level location, a minimum priority and a type (Incident or Investigation). Initially we looked as Users & Custodians on the Locations object. This only partially fulfilled the requirement and also these are not accessible to all Users. We decided on creating a new object called Subscriptions that was a sub-object off Person. We could have multiple lines for each Person and we would specify Top Level Location, Type of Notification and Minimum Priority. Type was set up in an ALN domain to make Users could only enter a valid value.
Default Information Dialog
The Default Information Dialog could be used by each User to set their own Subscriptions, they can choose ant Location in the Hierarchy, whether they want to see Incidents or Investigations and the minimum priority they wanted to see (there where 5 priorities in use)
In order to add and remove from this Subscriptions object, we added a table to both the People application (for the Business Admins) and the Default Information Dialog (for individual users).
We only needed two Escalations; one each for Incidents & Investigations. These would determine how often they ran (every five minutes) and which status where applicable using the Escalation Points.
We also only needed two Communication Templates, the wording for each was different and the object from where they pulled data was too. Who the emails were sent to was determined by a Role that had been set up.
The Role was the smart bit. Again there were two Roles – one for Incidents and one for Investigations. We used a type “A set of data related to the record” in the Value field we put a Relationship and then Person Id.
Example Role Set Up
The role doesn’t have to be an individual Person, Data can be related to the current record or to the User, adding a relationship allows the current record to be linked to an email address, for example the Person record. This doesn’t have to be one email, it can be multiple.
The Relationship was added to the Incident and Problem (Investigations) Objects. The Child Object being PERSON. This would provide a list of appropriate emails to which the Users or person had subscribed to see the record.
The relationship combined Location Ancestor (for the Hierarchy) with the Subscriptions data and the Person record to determine who to send the Notifications too.
Once all this was set up we migrated the list of email addresses and subscriptions into Maximo and went live. Now users and admins can make changes to the subscriptions list without having to log a Change Request.
The Follow Up
The follow up to this solution was that it was relatively straight forward to add other Subscription Types. To add Work Orders, for example, we would only need to add a value to the Subscriptions Type Domain, an Escalation, a Communications Template, a Relationship and a Role, then the Subscriptions Data.
What we also did was to add a sub tab to the Logs, called Notifications, in Incidents and Investigations Apps that list the Persons, who would get the Notification, based on the Location, Priority and Type. This is a simple Table list with a Relationship that joins the record to Person using the same relationship clause.
0 Comments