Hosted by Chandra Wobschall and Paul Houtkooper

Hey there, JDE Connection listeners! We’re back with a brand-new episode and this week we’re focusing on Security Workbench and configuring application, action, row, and column security. We might not be your go-to experts on TLS or HTML server security, but if you’ve ever had to troubleshoot a missing button, locked-down field, or overly generous user role—this one’s for you.

Why Security Workbench Matters

Security configuration in JD Edwards can be intimidating. It’s not just about locking down access—it’s about making sure the right people have access to the right data, in the right environments, for the right reasons. And all of that starts in the Security Workbench (P00950).

Inclusive vs. Exclusive Security

We kicked off by breaking down the difference between inclusive and exclusive security models:

• Exclusive: Deny by default. Grant access to specific functions.
• Inclusive: Allow by default. Restrict access to specific functions.

Choosing the right approach depends on your org’s size, complexity, and maintenance capacity. Either way—don’t switch models without careful planning!

Application Security

This is your front line of defense. Application security lets you grant or restrict access to:

• Applications
• Versions
• Forms
• Batch Jobs (UBEs)

We talked about how most organizations use role-based access—and why it’s smart to limit direct assignments to individual users. Paul shared how setting access at the right level can reduce record volume, improve performance, and simplify maintenance.

Action Security

Even if someone can access an application, that doesn’t mean they can run wild inside it. That’s where action security comes in. It lets you control access to:

• Add, Change, Delete Functions
• Hyperitems like OK, Copy, or Select

We laughed about “disappearing buttons” and how it often comes down to a change in security settings. Tip: learn to describe actions in terms users understand (like “the green plus sign”)—not just CRUD functions.

Row Security

Row security controls what data records users can see or modify. We covered examples like:

• MCU (cost center) restrictions
• Home cost center rules for HR/payroll visibility

Inclusive/exclusive settings matter here more than anywhere else. And if you’re handling a large or complex org structure (like multiple branches, regions, or business units), row security can get big fast. Third-party tools or accumulators can help optimize and flatten those records for better performance.

Column Security

Lastly, we covered column-level security, which lets you:

• Restrict visibility or edit access to specific fields
• Enforce privacy for sensitive data (like salary, SSN, tax areas, etc.)

This feature is powerful when used thoughtfully—especially in HR and Finance contexts.

Lessons Learned

• Plan for scale. Security models should grow with your business.
• Keep it role-based. Minimize user-level customizations.
• Audit early and often. Logs and security history are your friends.
• Communication matters. Users describe problems differently—translate tech speak when needed.

Midwesternism of the Week: Pole Barn

Chris Laping mentioned it, and we couldn’t resist. This week’s Midwest term is a low-cost structure that originated in the 1930s that farmers repurposed telephone poles to build. Fun fact: they’re now used for everything from storing tractors to hosting weddings and dance parties!

Join the Conversation

Have your own security tip or trick? We’d love to hear it! Reach out at [email protected].

Until next time, let’s keep learning, sharing, and—most importantly—laughing together.

Toodles!

Missed an episode? Check out the full episode list! Also, be sure to subscribe on your favorite podcast provider, or select a provider below!

Learn More

Quest Oracle Community is where you learn. Ask questions, find answers, swap stories and connect to other JD Edwards customers and product experts in the JD Edwards Community, where you can also check out what’s happening in the Business Analyst SIG.