JDE One View Report stuck pending: how to publish it to other users
how to approve and publish a One View Report in JD Edwards
Also searched as
- JDE UDO pending approval status
- One View Reporting not showing for other users
- EnterpriseOne UDO administration how to
- publish OVR to role EnterpriseOne
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.
Applies to: JD Edwards EnterpriseOne 9.2, Tools Release 9.2.x (UDO framework)
Approve and publish a One View Report
- 1Confirm 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.
- 2Sign on as a user with UDO administration security, and open the User Defined Objects administration application.
- 3Search for the report by name, object type One View Report, and status Pending Approval.
- 4Review the report definition - the underlying query, columns, and any filters - before approving, since approval makes it available to whatever audience you assign next.
- 5Change the status to Approved.
- 6Assign availability: to a specific role, to specific users, or to *PUBLIC if every user should see it.
- 7Have a target user sign off and back on, or refresh their available reports list, and confirm the report now appears for them.
- 8If 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.
Why One View Reports start out invisible to everyone else
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
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
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
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.
Common 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.
How an ERP-grounded AI assistant handles this
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.
Frequently asked questions
Why can only the person who built the One View Report see it?
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?
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?
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?
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.
Related
How to set up row security in JD Edwards Security Workbench
Security Workbench (fast path SECURITY, application P00950) is where every type of EnterpriseOne security record is defined, including row security, which restricts which rows of data a role or user is allowed to see or act on based on a key field like business unit or company, independent of whether they have access to the application itself. Application security controls whether a role can open a program at all; row security controls what data they see once they are in it.
How-toHow to set up BI Publisher output for a JD Edwards report
BI Publisher for JD Edwards EnterpriseOne lets a UBE render through an RTF or PDF template designed in BI Publisher instead of EnterpriseOne's own print engine, giving far more control over layout for things like invoices, checks, and financial statements. Setting it up means confirming the connection to a BI Publisher server, building or importing a template against the report's XML data structure, and associating that template with the specific report version through Report Design Aid.
How-toHow to set up JD Edwards Orchestrator (step by step)
An EnterpriseOne orchestration chains one or more requests (form requests that drive an interactive application, or service requests that call a BSFN, business service, or SQL) plus optional rules and notifications, then exposes the whole thing as a callable REST endpoint via the AIS (Application Interface Services) server. The setup work happens in Orchestrator Studio, not the Fat Client.
How-toHow to set data selection and processing options in JD Edwards
Data selection controls which rows a UBE's underlying business view reads (a filter, stored per version in F9210/F9211), while processing options control how the program behaves once it has that data (a settings template stored per version in F983051/F983052). They are configured from the same Version Detail screen but are separate, unrelated mechanisms that new users routinely confuse.
Error fixJDE UBE failed (status E): how to read jde.log and jdedebug.log
A UBE (batch report/program) that ends with status E in Work With Submitted Jobs tells you almost nothing on its own. The real error is in jde.log on the enterprise server, in the job's own PDF/log subdirectory (jdedebug.log if you turned on debug), and in the work directory for that job number under PrintQueue or the OS temp path.
Error fixJD Edwards: record is being used by another user (record reservation)
EnterpriseOne places a soft record reservation lock when a user opens a record for edit, tracked in the F00165 table, and releases it when the user saves, cancels, or the session ends cleanly. A stuck lock almost always means a session died abnormally (browser crash, network drop, kiosk timeout) without triggering the release, and it must be cleared by an admin, not by the original user retrying.
AI for ERPAI for JD Edwards EnterpriseOne, Built on Orchestrator and AIS
Add AI to JD Edwards E1 9.2 using Orchestrator, AIS, and BSSV rather than screen-scraping. Ground a private LLM on F4211, F4111, and F0411 data.
AI for ERPOracle ERP AI Consulting: What a Partner Should Deliver
What to demand from an Oracle ERP AI consulting partner across EBS, JD Edwards, NetSuite, and Fusion Cloud: interface tables, APIs, and buyer questions.
Stuck on JD Edwards EnterpriseOne?
Talk to engineers who work inside JD Edwards EnterpriseOne every week, and who build private AI that answers these questions from your own ERP data.