Hiding Vendor Data Without Creating False Security
A procurement manager asks you to hide the Vendor field on the Purchasing tab of Work Order Tracking for 80 field technicians whenever the work order's Work Type is EMERGENCY. The technicians are in security group FIELD. The manager proposes a conditional expression on the field control in Application Designer. The same technicians also access work orders through Maximo Mobile and a custom REST API that uses the MXWO object structure. Vendor is included in a public saved query used by dispatch and in a BIRT report used by procurement. The manager says the goal is to prevent technicians from seeing vendor pricing on emergency jobs, not just to reduce screen clutter. The company's audit team has asked for evidence that the restriction cannot be bypassed.
1. What does a conditional UI property actually control, and why is it a poor fit for the stated goal?
Read the worked answer
A conditional property on an Application Designer control changes presentation in that application. It can hide or show a field based on an expression, but it does not grant or deny read access to the underlying WORKORDER attribute. A technician who uses Maximo Mobile, the REST API, another application, a saved query, or an export can still retrieve Vendor if those channels expose it. The audit team's requirement is an authorization and data-exposure question, so a UI-only hide would create a false sense of control.
It is reasonable as a usability change, but not as the sole control for vendor pricing. Before agreeing, clarify whether the business wants decluttering or confidentiality. If confidentiality, design controls at the object structure, application access, and reporting layers, and test each channel independently.
2. What are the impacts on the saved query, BIRT report, and mobile/REST channels if you hide the control?
Read the worked answer
Hiding the control should not break the saved query or the BIRT report because both depend on the WORKORDER attribute, not on the tab control. The field remains in the object and database. That is exactly why hiding the control does not meet the confidentiality goal.
Maximo Mobile and the REST API are more concerning. If they use MXWO and MXWO includes Vendor, hiding the desktop control has no effect. If you instead remove Vendor from MXWO to protect the API, you may break the mobile screen, the integration, or any report that relies on that object structure. The safe path is to create a separate, restricted object structure for the technician channels and keep MXWO intact for procurement reporting, then test the saved query and BIRT report against the unchanged data source.
3. Recommend a layered design that satisfies audit without breaking reporting.
Read the worked answer
First, split the requirement into presentation and authorization. For presentation, a conditional property on the Purchasing tab is acceptable, but label it as UX only. For authorization, deny the FIELD group access to the full Work Order Tracking application and give it a clone that omits Vendor, or restrict the technician channels to a dedicated object structure that excludes Vendor. Configure Maximo Mobile and the REST API to use that restricted structure. Keep MXWO and the full desktop application for procurement and dispatch so the saved query and BIRT report continue to work.
Add evidence: test as a FIELD user on desktop, mobile, and API; attempt to retrieve Vendor through Select Columns, Advanced Search, and export; record the results. Audit application access and object-structure membership quarterly. This layered approach protects the data where it is exposed while avoiding a change that only hides pixels.