# JDE One View Report stuck pending: how to publish it to other users > Source: https://netray.co/erp-help/jde-udo-one-view-report-approval-how-to > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer One View Reports are a type of User Defined Object (UDO), and like other UDOs, a report a business user designs is saved as Pending by default and only visible to its creator until an administrator with UDO administration security approves it and assigns it to a role or *PUBLIC. This approval and availability step, not the report design itself, is the most common reason a finished One View Report is not showing up for anyone else. ## Kind how-to ## System jd-edwards ## Erp JD Edwards EnterpriseOne ## Module UDO / One View Reporting ## Query how to approve and publish a One View Report in JD Edwards ## Alternate Queries - JDE UDO pending approval status - One View Reporting not showing for other users - EnterpriseOne UDO administration how to - publish OVR to role EnterpriseOne ## Applies To JD Edwards EnterpriseOne 9.2, Tools Release 9.2.x (UDO framework) ## Steps ### Approve and publish a One View Report **Items:** - Confirm the report was actually saved (not just left open) from the One View Report Designer, and note its exact name and the user who created it. - Sign on as a user with UDO administration security, and open the User Defined Objects administration application. - Search for the report by name, object type One View Report, and status Pending Approval. - Review the report definition - the underlying query, columns, and any filters - before approving, since approval makes it available to whatever audience you assign next. - Change the status to Approved. - Assign availability: to a specific role, to specific users, or to *PUBLIC if every user should see it. - Have a target user sign off and back on, or refresh their available reports list, and confirm the report now appears for them. - If it still does not appear, check that the user's role has security to the underlying UDO type itself, separate from the specific report's availability assignment. ## Sections ### Why One View Reports start out invisible to everyone else **Body:** One View Reporting is built on the same User Defined Object framework as personal forms, watchlists, and grid formats. Every UDO a user creates is private by default - it exists only for that user until someone with UDO administration rights reviews and approves it. This is a deliberate governance control: it stops every user-built report, form customization, or watchlist from silently becoming organization-wide the moment someone saves it. So a One View Report that a power user built, tested, and is happy with is still, from the system's point of view, just a pending personal object until an administrator explicitly approves it and decides who else should see it. ### The UDO administration workflow **Body:** UDO administration is a separate application from the report designer itself, used to search across all pending, approved, and rejected UDOs by type, owner, and status. An administrator reviewing a pending One View Report can see its definition - what data it queries and how it is filtered - before deciding to approve it, which matters because approval is effectively a publishing decision, not just a technical formality. Once approved, availability is assigned separately: to individual users, to a role (so everyone with that role sees it), or to *PUBLIC for organization-wide visibility. A report can also be approved but deliberately scoped to a narrow role if it is only relevant to one department. ### Two layers of security to check **Body:** There are two independent things that control whether a user can see a specific One View Report: whether their role has general security to use One View Reports and UDOs at all (a Security Workbench setting), and whether that specific report was assigned to their role or to *PUBLIC during UDO administration approval. A user missing either one will not see the report, and troubleshooting often means checking both rather than assuming the report itself is broken. ### Governance considerations **Body:** Because approval effectively publishes a report to whatever audience is assigned, most organizations restrict UDO administration security to a small number of people - often a mix of IT and a business power user per module area - rather than opening it broadly. It is also worth periodically reviewing pending UDOs, since reports and personalizations pile up in that queue and get forgotten if no one owns the approval step. ## Pitfalls - Assuming a saved One View Report is automatically visible to a role or the whole organization. - Approving a report without reviewing its underlying query and filters first, since approval is effectively a publish decision. - Forgetting that general UDO security at the role level and the specific report's assigned availability are two separate checks. - Leaving UDO administration security open to too many users, which undermines the governance point of the approval step. - Not telling users to sign off and back on (or refresh) after a report is approved, leading to false reports that it is still not showing. ## Ai Angle ERPray can look up which One View Reports are sitting in Pending status, who created them, and what they query, so a UDO administrator can triage a backlog quickly instead of paging through UDO administration by hand. The approval decision itself - whether a given report's logic is correct and who should see it - still needs a person, since that is a judgment call about data exposure, not a lookup. ## Faq ### Why can only the person who built the One View Report see it? **Answer:** One View Reports are User Defined Objects and are private to the creator by default. They stay that way until an administrator with UDO administration security reviews the pending object, approves it, and assigns availability to a role, specific users, or *PUBLIC. ### I approved the report but the user still cannot see it. Why? **Answer:** Check whether their role has general security to use One View Reports and UDOs at all, separate from whether this specific report was assigned to their role or *PUBLIC. Both need to be in place, and the user may also need to sign off and back on after approval. ### Who should have UDO administration security? **Answer:** Most organizations keep this narrow - typically IT plus a small number of trusted business power users per module - since approving a UDO effectively decides what data and logic becomes visible to a wider audience. Broad UDO administration access undermines that governance control. ### Can I approve a report for one department but not the whole company? **Answer:** Yes. Availability is assigned separately from approval, and a report can be approved but scoped to a specific role rather than *PUBLIC, which is the normal pattern for reports relevant to only one department or function. ## Search terms JDE One View Report pending, JD Edwards UDO administration, EnterpriseOne UDO approval workflow, One View Reporting not visible, JDE publish report to role, UDO security Security Workbench, EnterpriseOne UDO pending approval status, JD Edwards user defined objects --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json