Maximo Security – An Overview

Maximo Security – An Overview

On February 18, 2016, Posted by , In Maven,Maximo,Security, With Comments Off on Maximo Security – An Overview

Maximo security follows a role-based, modular approach to managing access to applications and data. Group-level restrictions are configurable for:

  • Application access
  • Sites
  • Storerooms
  • Limits and Tolerances
  • Labor
  • GL Account Components
  • Data

In addition to the security options provided in the Security Groups application, Maximo configuration utilities such as workflow and data restrictions are often used to enforce record-level security.

Application Access

Application access is typically granted to a business role, such as Maintenance Supervisor, Stockkeeper, or Purchasing Technician. If a user performs multiple roles, they may be granted access to each of these groups. Assuming that the Independent of Other Groups option is not selected, permissions will be combined, giving the user access to the applications and options of each group.

In the following diagram, John Doe is part of the Requestor user profile, but is also a Maintenance Supervisor and a Stockkeeper. He can access most Work Order, PM, and Asset actions as a maintenance supervisor. He can manage inventory levels and view Purchase Orders as a stockkeeper. He can create Purchase Requisitions and Work Orders as a requestor and view status as requests are fulfilled.

Record Editability

For most applications, the following editability settings are available:

  • Read
  • Save (edit existing records, but cannot create new)
  • Insert
  • Delete

If a user is a member of one group that has read-only access, and another group that has Insert access, the higher access level will take precedence, and the user will be able to view and create new records.

Application Options

Menu and toolbar options, as well as search options, are configured individually for each application within each group. For example, the Purchase Requisitions application contains nearly 40 options, but only a few, such as Route Workflow and Advanced Search are accessible to this Requestor profile. Purchasing supervisors, on the other hand, have been granted additional options, such as Create PO and Change Status.

Maximo Security by Group

Figure 1: Application access by Security Group


Maximo Security - Merged Profile

Figure 2: Merged security profile for John Doe

Site-Level Security

Maximo supports multi-site configuration. While this is typically recommended for physically-separated sites, at times, this is used to control data access within applications. Records such as assets, locations, work orders, PRs, and POs, all managed at the site level, are only visible to users who have access to a particular site.

Storeroom Security

Inventory access is granted at the storeroom level. A group who has access to a storeroom can perform transactions that impact inventory levels, such as issues, transfers, and adjustments. A user without storeroom access may still be able to view inventory balances, depending on their application profile, but cannot modify its data.

Limits & Tolerances

Purchasing limits and tolerances are set at the group level. Limits may be configured for the following financial records:

  • Purchase Requisitions
  • Purchase Orders
  • Materials Requisitions (Desktop Requisitions)
  • Invoices
  • Contracts

Additionally, tolerance levels for invoice variance are established at the group level. Tolerance may be expressed as either a percentage or a dollar amount.

Labor Restrictions

Groups may be permitted to use any Maximo labor record, or they may be restricted to a certain group, such as labor that the user supervises, labor within the user’s crew, or one’s own labor. This is particularly relevant when adding planned and actual labor to a work order.

GL Component Restrictions

A group may be permitted to modify any GL component, or may be restricted from entering or changing certain components. For example, the project GL component may be limited to users who are responsible for project work, whereas the cost center component is editable by any user who can edit the PR, work order, or other associated record.

Data Restrictions

Data within an application may be restricted to a particular group of users. For example, a data restriction may be used to allow a shop to edit their own work orders, but not those of other groups. Likewise, a data restriction could be configured to allow a user to view their own PRs, while not having visibility into any other PRs.

Such restrictions are configured by attaching a SQL query to an object, attribute, or application option (such as PO Change Status). Based on query evaluation, the field or record may be marked read-only or hidden altogether.

Configuration-Based Security

Maximo supports additional security enhancements using its standard configuration tools. It is common for Maximo security to be combined with utilities such as workflow to provide additional control over the organization’s data and processes.

For example, the Requestor we described earlier should be able to create a PR. Further, they should be able to edit it once they’ve saved changes – but not once the approval process has begun. The requestor has been granted access to workflow options, so they can initiate an approval workflow. However, they do not have the Change Status option, so they cannot bypass this process by manually approving their own PR. Further, conditional security may be configured to lock the record so that only the current approver may edit it. Additionally, the workflow process may be configured to determine approval assignments based on the requestor’s department as well as the request amount.

In the Details

This article was intended to provide a practical overview of Maximo security in the context of role-based groups. By no means is it all-encompassing. Multi-site and multi-organization users have additional security considerations. Less-frequently used, but sometimes desirable options, such as the Independent of other Groups flag, have intentionally been omitted from this discussion for the sake of simplicity.

Regardless, implementing your organization’s security model will require a deeper dive into the options described above. Which would you like to see demonstrated in greater detail? Let us know, and we’ll provide a follow-up article in our next issue.


Comments are closed.