How to set up row security in JD Edwards Security Workbench
how to set up row security in JD Edwards Security Workbench
Also searched as
- JDE P00950 security workbench guide
- EnterpriseOne application security vs row security
- JDE security changes not taking effect
- how to restrict rows by business unit JDE
Short answer
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.
Applies to: JD Edwards EnterpriseOne 9.1, 9.2, all tools releases
Create a row security record
- 1Fast path to SECURITY to open Security Workbench (P00950).
- 2Select the security type Row Security and add a new record.
- 3Choose the table or business view the row security applies to, and the key field to restrict on (commonly business unit, company, or a UDC-coded field).
- 4Enter the role or user this record applies to, and define the allowed range or specific value(s) for that key field.
- 5Set whether this is an allow record (only these values are visible) or a disallow record (everything except these values is visible), since the two behave differently and mixing them without understanding the interaction is a common source of confusion.
- 6Save the record and test by signing on as a user with that role, confirming rows outside the allowed range no longer appear in relevant inquiries and reports.
- 7If the change does not appear to take effect, have the test user sign off and back on - EnterpriseOne caches security and does not always pick up a change on an already-active session.
- 8Document the row security record's intent (which business units, why) somewhere outside Security Workbench itself, since the workbench does not give much room for that context and it is easy to forget the reasoning months later.
Security Workbench and its security types
Security Workbench is the single application where every category of EnterpriseOne security is defined: Application security (can this role open this program at all), Action security (can they add, change, delete, or only inquire), Row security (which rows of data they can see), Column security (which fields are visible or protected), Processing Option security, Exit security, Tab security, Exclusive Application security, and Published Business Services security among others.
All of these are entered the same way - select the security type, add a record scoped to a role or user, and define the restriction - but each type governs a different layer of what a user can do once they are signed on, which is why understanding which type actually needs to change is most of the troubleshooting work.
How row security actually restricts data
Row security is defined against a specific table or business view and a key field within it - most commonly business unit or company, but it can be any field the security record targets. Once defined for a role, EnterpriseOne applies that restriction to inquiries, reports, and other data access against that table for anyone with that role, filtering out rows outside the allowed range before the user ever sees them.
This is different from simply hiding a column or blocking an application: row security operates at the data level, which is why it is the right tool when the requirement is 'this role should only ever see business units in their division' rather than 'this role should not be able to open this screen at all'.
Allow vs disallow, and why the distinction matters
A row security record can either allow specific values (everything else is blocked) or disallow specific values (everything else is visible). Mixing both approaches for the same role and table is a common source of unexpected results, because the two interact rather than simply stacking additively. The safer, more predictable pattern for most organizations is to standardize on one approach per table - typically allow lists for anything sensitive - rather than combining allow and disallow records for the same scope.
Why security changes seem to not take effect
EnterpriseOne caches security information for performance, both at the server and often on the client. A row security or application security change made in Security Workbench does not always apply instantly to a user who is already signed on - the most reliable way to confirm a change took effect is to have the test user sign off completely and sign back on, which forces a fresh security check, rather than assuming the change failed just because an active session does not immediately reflect it.
Common pitfalls
- !Confusing application security (can they open the program) with row security (what data they see inside it) and setting up the wrong type for the requirement.
- !Mixing allow and disallow row security records for the same role and table, producing unpredictable results.
- !Assuming a security change failed because an already-active session does not reflect it, instead of having the user sign off and back on.
- !Not testing a new row security record with an actual test user in that role before rolling it out broadly.
- !Leaving no documentation of why a specific row security record exists, making it risky to remove or modify later.
- !Forgetting that column security and row security are independent - restricting a field's visibility does not restrict which rows are returned, and vice versa.
How an ERP-grounded AI assistant handles this
ERPray can answer questions like which roles currently have row security restrictions on a given table, or list every security record tied to a specific role, pulling that directly from Security Workbench data instead of a security admin paging through P00950 record by record. Deciding what a new restriction should be, and confirming it matches an actual business requirement, remains a decision for someone who owns that access policy - ERPray surfaces the current state, it does not set the policy.
Frequently asked questions
What is the difference between application security and row security?
Application security controls whether a role can open a program at all. Row security controls which rows of data within that program the role can see once they are in it, filtered by a key field such as business unit or company. A role can have full application access but still be restricted to a subset of rows.
I added a row security record but the user still sees everything. Why?
Have the user sign off and sign back on - EnterpriseOne caches security and an already-active session often does not pick up a new record immediately. Also confirm the record was scoped to the correct role, table, and key field, and that it is not being overridden by a conflicting allow/disallow record.
Can row security be based on something other than business unit?
Yes. Row security is defined against any key field in the target table or business view, so it can restrict by company, a UDC-coded category field, or another field relevant to the business requirement, not just business unit.
Should I use allow records or disallow records for row security?
Most organizations standardize on allow records (only listed values are visible) for anything sensitive, since mixing allow and disallow records for the same role and table interacts unpredictably rather than simply combining. Pick one approach per table and stay consistent.
Related
JDE One View Report stuck pending: how to publish it to other users
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.
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.
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.
Error fixJDE package build failed: how to find the real cause
A package build (Full or Update) that ends in a failed or errored status on the deployment server does not explain itself in the Package Build Workbench screen. The real diagnostic detail is in the package's own log subdirectory on the deployment server, which holds a build log, a table conversion log, and per-object compile logs that pinpoint the actual failure.
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 business function (BSFN) errors: how to diagnose them
A BSFN error in EnterpriseOne means either the compiled function was not found for the current package build, or the function ran and threw an internal exception (often a null business view row, an unhandled C runtime error, or a failed table I/O). The fix path is different for each, so the first step is always determining which one you are facing from jde.log.
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.
AI for ERPAI for JD Edwards World on IBM i, without a EnterpriseOne migration
Add AI to JD Edwards World on IBM i without replatforming: read the physical files safely, ground an LLM on your data, and keep control on the box you already run.
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.