Inside Maximo Manage 9.2: SMTP, Dashboards, and the End of Work Centers

Maximo Manage in MAS 9.2 is not just a version bump. The application received substantial functional improvements that change how administrators configure email handling, how users interact with their daily work environment, and how preventive maintenance schedules are generated. This deep dive covers the four most impactful changes: the new SMTP queuing and OAuth support, operational dashboards replacing traditional start centers, the complete replacement of Work Centers with role-based applications, and the new PM scheduling controls that fix long-standing frustrations.

Each of these changes affects daily operations for administrators, configurators, and end users. Understanding them before you configure 9.2 will save you time, reduce support tickets, and help your organization realize the benefits of the upgrade faster.

SMTP Email Handling: Queuing, OAuth, and Send-From Control

Email has been a perennial pain point in Maximo. Previous versions sent email synchronously through a simple SMTP connection. If the mail server was down, messages were lost. If your organization required OAuth authentication for SMTP (as many enterprise security teams now mandate), you had to implement custom workarounds because Maximo only supported basic username and password authentication. Scheduled reports always sent from the email address of the user who created the schedule, which meant report recipients could not reply to a shared mailbox or distribution list.

MAS 9.2 addresses all three of these issues.

Native SMTP Queuing: Maximo now includes a built-in email queue. When the mail server is temporarily unavailable, messages are stored in the queue and retried automatically. This means that work order notifications, escalation messages, and report distributions are no longer lost during mail server outages. The queue persists across restarts, so even a Maximo application restart will not lose pending messages.

The queue is configurable. You can set the maximum retry count, the retry interval, and the maximum queue size. Here is an example configuration:

# SMTP Queue Configuration in maximo.properties
mxe.email.queue.enabled=true
mxe.email.queue.max.retries=5
mxe.email.queue.retry.interval.seconds=300
mxe.email.queue.max.size=10000
mxe.email.queue.cleanup.days=30

# SMTP OAuth Configuration
mxe.smtp.auth.mechanism=OAUTH2
mxe.smtp.oauth.client.id=your-client-id
mxe.smtp.oauth.client.secret=your-client-secret
mxe.smtp.oauth.token.url=https://login.microsoftonline.com/tenant/oauth2/v2.0/token
mxe.smtp.oauth.scope=https://outlook.office.com/SMTP.send

The queue also includes a monitoring interface where administrators can view pending messages, check delivery status, manually retry failed messages, and purge messages that have exceeded their retry limit. This visibility into email flow was previously unavailable without database queries or log file analysis. Set up a scheduled task to review the queue daily during the first weeks after upgrade to catch any configuration issues with OAuth tokens or mail server connectivity.

SMTP OAuth Support: Full OAuth 2.0 authentication for SMTP is now supported natively. This aligns Maximo with modern security standards where basic authentication is being deprecated across enterprise email platforms. Microsoft 365, for example, has already removed basic authentication for SMTP in many tenants. With OAuth support, Maximo can authenticate using client credentials or authorization code flows depending on your email infrastructure.

The OAuth implementation supports token refresh automatically. When the initial token expires, Maximo retrieves a new token using the configured refresh flow without user intervention. This means email continues to flow even when tokens expire, which was a common failure point in organizations that tried to work around the lack of OAuth support with short-lived tokens.

Configurable Send-From Address: Scheduled reports can now use a configurable send-from address rather than the scheduling user's email. This is a small change with big operational impact. Report recipients see a consistent sender address (such as maximo-reports@company.com) instead of whatever administrator happened to schedule the report. Reply messages go to a monitored shared mailbox instead of disappearing into an individual's inbox.

For organizations that distribute hundreds of scheduled reports, this change simplifies email management, improves deliverability (consistent sender addresses are less likely to be flagged as spam), and ensures that replies reach the right team rather than an individual who may have left the organization.

Operational Dashboards: Replacing Start Centers

Start Centers have been the primary landing page for Maximo users since the Maximo 6.x era. They were flexible but accumulated technical debt over the years: slow rendering, inconsistent behavior across browsers, and a configuration model that required administrative knowledge to set up effectively for large user populations.

MAS 9.2 introduces Operational Dashboards as the replacement for Start Centers. These are built on the React-based application framework that IBM has been progressively adopting across MAS. The key differences are:

Performance: Operational Dashboards render faster than Start Centers because they use a modern frontend framework with efficient data loading. Where a Start Center might take 5 to 10 seconds to fully load with multiple result sets and KPI graphs, an Operational Dashboard with equivalent content typically loads in 2 to 3 seconds. This matters because the dashboard is the first thing users see when they log in, and slow load times create a negative impression of the entire system.

Configuration: Dashboards are configured through a drag-and-drop interface that allows administrators to place widgets, charts, result sets, and KPI indicators on a grid. The configuration is saved per role, meaning all users with the same role see the same dashboard layout unless personalized. Users can personalize their dashboard by adding, removing, or rearranging widgets without affecting other users.

Widget Library: The available widget types in Operational Dashboards include:

Migration Considerations: Existing Start Center configurations do not automatically convert to Operational Dashboards. You will need to recreate dashboard layouts in the new framework. Plan this as a configuration task during your upgrade project. Start by documenting what each role currently sees on their Start Center, then design the equivalent Operational Dashboard layout. This is an opportunity to clean up Start Center configurations that have grown unwieldy over the years.

IBM has stated that Start Centers remain functional in 9.2 for backward compatibility, but the strategic direction is clearly toward Operational Dashboards. New features and widget types will be developed for dashboards, not Start Centers. Plan your migration accordingly.

Migration Strategy: A phased approach works best. Start with a single role (such as maintenance supervisors) and migrate them to Operational Dashboards first. Use their feedback to refine the dashboard layout and identify any missing widgets or functionality. Then roll out to additional roles in waves. This approach limits risk and allows your configuration team to build expertise before tackling the most complex roles.

During migration, keep the old Start Centers available for a transition period. Users can access both the Start Center and the Operational Dashboard while they get comfortable with the new interface. After a defined transition period (30 to 60 days), remove the Start Center configuration and make the Operational Dashboard the default landing page.

Design your dashboards with role-specific focus. A maintenance supervisor dashboard might include a result set of assigned work orders, a KPI gauge showing weekly completion rate, a chart of work order backlog by priority, and a quick action button to create a new work order. A reliability engineer dashboard might instead focus on asset health indicators, failure mode trends, and KPIs for mean time between failures. The key is to surface the most relevant information for each role without cluttering the dashboard with data that is not actionable.

Role-Based Applications: Work Centers Are Gone

MAS 9.2 completes the transition from Work Centers to Role-Based Applications (RBAs). Work Centers were the original role-specific UI introduced in Maximo 7.6, providing simplified interfaces for technicians, supervisors, and planners. They served their purpose but were built on older technology that could not support the responsive design and offline capabilities that modern field operations require.

RBAs are built on the Mobile Application Framework (MAF), the same framework that powers Maximo Mobile. This means several important things for administrators:

Consistent UI Across Devices: An RBA looks and behaves the same whether accessed from a desktop browser, a tablet, or a mobile phone. The interface is responsive, adjusting layout and interaction patterns to the screen size. This eliminates the need to maintain separate configurations for desktop and mobile users performing the same role.

Offline Capability: Because RBAs use MAF, they inherit offline capabilities. A technician working in a remote location without network connectivity can continue to access assigned work orders, complete labor reporting, and capture inspection results. The data syncs back to Maximo when connectivity is restored. This was not possible with Work Centers and represents one of the most significant operational improvements in the transition.

Simplified Configuration: RBAs are configured through the Maximo administration interface without requiring Java development or deployment modifications. Administrators define which applications, fields, and actions are available for each role. The configuration is metadata-driven, meaning changes take effect immediately without redeployment.

The transition from Work Centers to RBAs has been gradual. IBM deprecated Work Centers in earlier 9.x releases and 9.2 completes the removal. If your organization has not yet transitioned, you must do so as part of your 9.2 upgrade. Here is a checklist:

1. Inventory existing Work Center usage: Identify which roles use which Work Centers and what functionality they access
2. Map to RBA equivalents: For each Work Center, identify the corresponding RBA that provides equivalent functionality
3. Configure RBAs: Set up role-based applications with the appropriate fields, actions, and security constraints
4. Test with users: Have representative users from each role test the RBA in a non-production environment
5. Train users: Provide brief training on the new UI, focusing on differences from the Work Center
6. Decommission Work Centers: Remove Work Center configurations after confirming RBAs meet all requirements

PM Scheduling: Last Day of Month and Organizational Control

Preventive Maintenance scheduling has long had a frustrating limitation: you could not reliably schedule a PM to generate on the last day of the month. The workaround was to set the PM to generate on the 28th and hope February did not cause issues, or to use custom automation scripts to handle month-end generation. This was particularly painful for financial reporting PMs, compliance inspections, and monthly meter readings.

MAS 9.2 fixes this with a new flag that allows PMs to generate on the last day of the month, regardless of how many days that month has. The flag is available at both the organizational level (as a default for all PMs) and at the individual PM level (for PMs that need different behavior).

<!-- Example: PM configuration for last-day-of-month generation -->
<PM>
  <PMNUM>PM-2026-001</PMNUM>
  <DESCRIPTION>Monthly Safety Inspection</DESCRIPTION>
  <FREQUENCY>1</FREQUENCY>
  <FREQUNIT>MONTH</FREQUNIT>
  <GENERATE_LAST_DAY>true</GENERATE_LAST_DAY>
  <ORG_ID>MYORG</ORG_ID>
  <SITE_ID>MYSITE</SITE_ID>
</PM>

<!-- Organization-level default -->
<!-- Set in Organization > PM Options -->
<!-- "Generate PMs on last day of month" = Checked -->

This change also affects PM frequency calculations. When the last-day-of-month flag is enabled, the system calculates the next due date as the last calendar day of the following month, maintaining the monthly cadence regardless of month length variation (28, 29, 30, or 31 days).

Beyond the last-day fix, MAS 9.2 also adds organizational-level control over PM generation timing. Previously, PM generation frequency was controlled globally. Now, individual organizations within a multi-tenant MAS deployment can set their own PM generation parameters, which is valuable for organizations with different operational calendars or regulatory requirements. For example, a utility company with separate electric and gas divisions can configure different PM generation defaults for each division without affecting the other.

Table Downloads and Logging Improvements

Two additional Manage improvements deserve attention:

Table Downloads: Users can now download table data directly from list views without requiring a separate report or export process. The download supports CSV and Excel formats and respects the current filter and sort criteria. This eliminates a common support request where users needed to export data for offline analysis but had to ask an administrator to create a report. The download is available through a toolbar button on any list view, and administrators can control which roles have download permissions through the standard security model.

Logging and Troubleshooting: MAS 9.2 improves the logging framework with structured logging, better search capabilities within log files, and the ability to enable verbose logging for specific components without restarting the application. Administrators can now set log levels through the administrative interface, and the changes take effect immediately. This dramatically reduces the time needed to diagnose integration failures, workflow errors, and performance issues.

The structured logging format outputs JSON entries that can be ingested by log aggregation tools such as Splunk, ELK, or Datadog. Each log entry includes a timestamp, component name, log level, correlation ID, and message. The correlation ID is particularly useful for tracing a single user action through multiple components. For example, when a technician saves a work order, the correlation ID links the UI action, the MBO processing, the integration callout, and the database update in a single traceable chain.

{
  "timestamp": "2026-07-20T10:15:32.456Z",
  "level": "INFO",
  "component": "MXAPIWODetail",
  "correlationId": "wo-save-78342-ab123",
  "message": "Work order WO-12345 saved successfully",
  "userId": "JOHN.SMITH",
  "duration_ms": 245
}

Administrators can configure log retention policies to control how long log files are kept, preventing disk fill issues on long-running production environments. Set retention based on your organization's compliance requirements and operational needs. A 30-day retention is typical, but regulated industries may require 90 days or longer.

Practical Implications

The Manage improvements in 9.2 collectively reduce the administrative burden of running Maximo. SMTP queuing eliminates a class of support tickets (lost emails during outages). Operational Dashboards provide a modern, performant replacement for aging Start Centers. Role-Based Applications complete the transition away from legacy Work Centers, bringing offline capability and consistent cross-device UX. PM scheduling fixes resolve a long-standing frustration for maintenance planners.

Each of these changes requires configuration work during the upgrade. Budget time for recreating dashboards, configuring RBAs, testing SMTP OAuth settings, and validating PM generation with the new last-day flag. The configuration effort is front-loaded but pays dividends in reduced support tickets and improved user satisfaction within the first month of go-live.

Bottom Line

Maximo Manage 9.2 delivers the kind of functional improvements that users notice and appreciate. Email works reliably, dashboards load fast, the UI is consistent across devices, and PM scheduling finally handles month-end correctly. The upgrade requires configuration effort to realize these benefits, but the work is well-defined and does not require custom development. Focus your upgrade project on the configuration tasks that unlock these improvements, and your users will see tangible value from 9.2 on day one.