# How to set up row security in JD Edwards Security Workbench > Source: https://netray.co/erp-help/jde-security-workbench-row-security-how-to > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## 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. ## Kind advanced ## System jd-edwards ## Erp JD Edwards EnterpriseOne ## Module Security / Security Workbench ## Query how to set up row security in JD Edwards Security Workbench ## Alternate Queries - 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 ## Applies To JD Edwards EnterpriseOne 9.1, 9.2, all tools releases ## Steps ### Create a row security record **Items:** - Fast path to SECURITY to open Security Workbench (P00950). - Select the security type Row Security and add a new record. - Choose 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). - Enter the role or user this record applies to, and define the allowed range or specific value(s) for that key field. - Set 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. - Save 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. - If 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. - Document 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. ## Sections ### Security Workbench and its security types **Body:** 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 **Body:** 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 **Body:** 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 **Body:** 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. ## 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. ## Ai Angle 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. ## Faq ### What is the difference between application security and row security? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms JDE Security Workbench, P00950 row security, JD Edwards row security setup, EnterpriseOne application vs row security, JDE security changes not taking effect, restrict rows by business unit JDE, EnterpriseOne security types P00950, JD Edwards role security fast path SECURITY --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json