IBM Maximo Manage v8 Admin common mistakes
IBM Maximo Manage v8 Admin · Understand the traps and how to avoid them.
Treating application-level security as if it alone controls what a user can see, and never checking the object-level and data-level layers when a user reports missing records or disabled fields.
Maximo security is layered: application security grants access to the app and its options, object-level security controls actions (insert, save, delete, read) on a specific object, and data restrictions (conditional expressions) filter which records within that object a user may see. Candidates often stop at the application layer because that is the screen they know best, so they misdiagnose read/action problems as app-level permission problems.
What to do instead
For any access question, walk the layers in order: is the application authorized in the Security Groups application; does the relevant object entry grant the needed action; is a data restriction on that object hiding the rows; and does the user's default insert site or organization limit visibility. Practice reading a security group's object entries and conditional expressions rather than guessing.
Assuming a signature option is active simply because it appears in the Security Groups application, instead of verifying it is registered and enabled on the application's menu or toolbar definition.
Signature options only become assignable when the corresponding action is defined on the application (for example as a menu or toolbar action) and registered. If an action is removed or the application definition changes, the option disappears or is greyed out. Candidates who memorize checkboxes rather than the mechanism pick the wrong answer about why an option is unavailable.
What to do instead
Remember the chain: an action exists on the application definition, it is registered as a signature option, and then it can be granted in a security group. When an option is missing, inspect the application definition first, then the group.
Confusing the roles of the Maximo Integration Framework components, for example choosing an enterprise service when the scenario requires an object structure publish channel, or assuming the external system is triggered by the object structure itself.
The framework separates the data contract (object structure), the transport (endpoint and handler), and the direction of flow (outbound publish channel versus inbound enterprise service). Candidates who learn the terms as a list rather than as a pipeline mis-map scenario wording such as 'Maximo must notify the external system' to the wrong component.
What to do instead
Build the mental pipeline: object structure defines the payload; an outbound publish channel with an endpoint and handler pushes changes outward; an inbound enterprise service with an external system and listener receives data. Read the scenario for direction of data flow and who initiates before selecting a component.
Editing a live record directly to fix a workflow problem, or restarting a workflow without first checking whether the underlying record is locked, the process is enabled, or the role assignment allows the user to act on the task.
Workflow problems usually have administrative causes: a disabled process definition, a role that no longer maps to a security group, or a record lock held by a stuck transaction. Direct data edits can leave the process instance inconsistent. Candidates who reach for the record first rather than the process configuration misdiagnose the failure.
What to do instead
Diagnose in order: is the process definition enabled and active; does the role in the process match a security group the user holds; is the record locked or is there an open transaction; can the user be reassigned a role. Use the workflow administration tools to inspect and, if needed, stop or restart the instance rather than editing business data.
Reporting that a scheduled job or escalation 'did not run' without checking whether the cron task or escalation is active, whether its instance is enabled, and whether the server running the task is the one expected in a clustered environment.
Background work in Maximo is driven by cron task instances and escalations that each have an enabled flag and a schedule, and in a multi-server deployment a task may be assigned to a specific server. Candidates assume scheduling is global and automatic, so they cannot explain silent non-execution.
What to do instead
Check the cron task definition, then the specific instance's active flag and schedule, then the server assignment. For escalations, verify the escalation is active, its schedule and point of application are correct, and the condition actually evaluates true for the target records.
Changing a field on an application tab and expecting it to persist, when the change was made in the running application rather than through Application Designer, or when the change was saved to the wrong presentation or a cached copy.
The runtime application and the Application Designer definition are different contexts, and browser or server caching can make an unsaved or misdirected change look applied. Candidates who do not distinguish configuration-time editing from runtime behaviour choose answers that assume direct on-screen edits persist.
What to do instead
Always make persistent UI changes through Application Designer, select the correct presentation for the target application, and remember that sign-out or cache refresh may be needed to see the change. Confirm by reopening the application definition, not just the running app.
Answering database configuration questions by describing a change to the Maximo application when the correct action is at the database level, such as adding an index, altering a column, or configuring the database connection, and vice versa.
Maximo configuration spans several layers: database objects, the Maximo data dictionary (objects and attributes), and application presentation. Candidates blur these layers and propose application-level fixes for performance or schema problems, or database changes for what is really a dictionary setting.
What to do instead
Classify each question by layer before answering: is the change to physical schema and indexes, to the object and attribute definitions in Database Configuration, or to the application layout. Apply changes in the correct tool and remember that dictionary changes may require a database configuration and admin-mode restart to take effect.
Assuming a new or copied user inherits the expected access automatically, without verifying default insert site, organization, labor or person linkage, and security group assignment.
A user's effective access depends on the security groups assigned, the default insert site and organization that scope record creation, and links to person or labor records that drive self-service and work management. Candidates focus on the password and group and overlook the scoping defaults, so they cannot explain why a user cannot create records in the right site.
What to do instead
When validating a user, check group membership, default insert site and organization, and the person/labor linkage together. Test with a record-creation scenario in the intended site rather than only confirming sign-in succeeds.
Misreading the effect of a conditional expression in a data restriction or escalation, for example treating a restriction as granting access or an escalation condition as a filter that excludes records from the escalation.
Conditional expressions in Maximo are evaluated in different senses depending on context: a data restriction shows records when the expression is true, while an escalation acts on records when its condition is true. Candidates apply a single mental model of 'condition equals permission' across contexts and invert the logic.
What to do instead
State the context explicitly before reasoning: for data restrictions, true means visible; for escalations, true means acted upon. Write a small test expression and predict which records match, then verify against the actual behaviour rather than relying on intuition.
Skipping the verification step after a configuration change, such as not running the appropriate admin-mode restart, not validating the change with a test user, or not checking logs, and then answering as though the change is immediately live.
Many Maximo configuration changes require administrative mode, a restart of the application server, cache refresh, or a database configuration step before they take effect, and some changes only apply to new sessions. Candidates who treat configuration as instant miss questions about why a change appears not to work.
What to do instead
For every configuration change, know its activation path: admin mode and restart for many dictionary and application changes, cache refresh for some settings, and new sign-in for session-scoped behaviour. Confirm with a test user in a fresh session and check the relevant log before concluding the change failed.