Some people consider signature options and conditional UI as equivalent things. But the two are not the same from a performance impact. Conditional UI you tie a signature option and some condition (such as :worktype='EM') and an action if true/false such as displaying/hiding the section, changing the colors, CSS class, etc. Conditional UI is continuously evaluating and the impact will depend on the condition performance and the actions being taken. And the underlying data might be fetched even if not displayed which adds overhead as well. Conditional UI can have an extreme impact in customer environments.
Signature options are part of the cached user's security profile and can be evaluated pretty quickly. This occurs throughout applications today to hide various menu options, tabs, tables, etc. I wouldn't be concerned using a that isn't tied into conditional UI.
------------------------------
Steven Shull
Naviam
------------------------------
Original Message:
Sent: 08-13-2025 15:24
From: Scott Schaurer
Subject: Strategy for preserving screen layout prior to customizations
Thanks Steven. I'm sure those variables come into play and I don't think we've defined our cutoff points yet. Someone had mentioned at Maximoworld that using signature options (the NVMHIDE approach), if used to a significant amount *[insert your definition of significant here] , can affect performance as screens load. Thoughts on if we might be dealing with seconds or milliseconds?
Ultimately we are weighing our choices to aid in future use of the product vs effort to remove and then later replace. We wouldn't want to hurt the user experience.
------------------------------
Scott Schaurer
SunCoke Energy
Original Message:
Sent: 08-13-2025 14:31
From: Steven Shull
Subject: Strategy for preserving screen layout prior to customizations
I think the answer varies based on the complexity of the changes. We generally modify the out of the box application and tie a custom signature option (something like NVMHIDE with a description of Hide for all users) to the sections/tabs/inputs we want to globally hide. That signature option we flag to not be visible which means when someone goes into application designer and tries to grant all permissions they won't accidentally grant this permission.
When we are making more drastic changes to the application, we tend to duplicate the application in those scenarios. These are typically going to be designed around a specific process flow we have so we want to be able to tailor it end to end for that flow. We generally don't want new fields to show up here and are OK having to migrate when we want to take advantage of them.
------------------------------
Steven Shull
Naviam
Original Message:
Sent: 08-13-2025 09:33
From: Scott Schaurer
Subject: Strategy for preserving screen layout prior to customizations
What are some of the recommendations & successful strategies being employed for retaining all of the content/information contained in the OOTB Maximo/MAS screens prior to making modifications to address a business need or simplify the end user experience by hiding/removing content? I've received some suggestions about duplicating OOTB applications, Saving a copy of the XML, Using signature options...
Wondering what the community has had the most success with and possible downsides of each. My concern is if a field is new/added in MAS and is not being used by the business 'today', that doesn't mean it might not be adopted in the future. Hiding them might let them be forgotten or simply generate more work to add them back later. The OOTB appearance and layout would really only be needed for the Administrative team, not for the user base.
Also worth clarifying is that our 7.6.1.3 production environment has already been modded to some degree without a clean copy retained. This strategy would only be employed going forward to help visualize the MAS 'additions'.
#Customizations
#EndUser
#MaximoApplicationSuite
------------------------------
Scott Schaurer
Maximo Administrator
SunCoke Energy
------------------------------