Oracle EBS Responsibility Design Worksheet
Good responsibility design in Oracle E-Business Suite keeps screens, reports and data access tied to a job, not to a person. This worksheet gives you one row per responsibility so a design review, an audit and a clean-up all work from the same list.
| Responsibility name | Application | Menu | Request group | Data group | MO security profile | Business role | Expected users | SoD review | |
|---|---|---|---|---|---|---|---|---|---|
A responsibility in EBS is a combination of an application, a menu, a request group and a data group, plus profile options such as the MO: Security Profile. Keep the names and values here aligned with your naming standard. SoD means segregation of duties.
Review your EBS access design
An optional conversation on reporting user and responsibility overlap from your own EBS data.
Optional. The tool and every export work without this. No spam.
What each column controls
The menu decides which forms and functions a user can open. The request group decides which concurrent programs and request sets the user can submit from the Submit Request window. The data group maps each application to the database user it runs as. The MO security profile, set through the profile option MO: Security Profile, decides which operating units the user can see. Record all four per responsibility so nobody inherits access by accident.
- Menu: forms and functions
- Request group: what the user can submit
- Data group: application to database user mapping
- MO security profile: operating unit access
How to design the list
Start from business roles, not from the standard responsibilities Oracle ships. Create one custom responsibility per distinct job and clone menus with function exclusions only when a role needs fewer functions. Keep request groups small and role specific, because a broad request group is the usual way a clerk ends up able to run a payment program. Give each row an owner and a SoD review result so the sheet doubles as audit evidence.
Common mistakes
Teams often copy the standard responsibility and then add functions until it works, which hides who can do what. Another habit is leaving the MO security profile blank, which on multi-org setups can give access to all or to none depending on profile settings. A third is combining entry and payment in one responsibility to save on user setup. Use the SoD column to flag these before go-live, not after the first audit.
- Do not edit seeded responsibilities, clone them
- Review request groups as carefully as menus
- Record who owns each responsibility
- Re-run the review after every patch that adds functions
Frequently Asked Questions
What is a responsibility in Oracle EBS?
A responsibility is the set of access a user gets when they log in: an application, a menu of forms and functions, a request group of reports and programs, and a data group. Profile options such as MO: Security Profile further control which operating units the user can see.
Should I use the seeded responsibilities?
Use them as a template only. Seeded responsibilities can change with patches and they bundle more access than most roles need. Create custom responsibilities with your own prefix so your design survives upgrades and is easy to find in reports.
How many responsibilities per user is reasonable?
There is no fixed number. Most users need a handful tied to their actual jobs. Long lists usually mean responsibilities were added for convenience. Count them per user and review anyone who combines entry, approval and payment functions.
Does this worksheet change anything in my system?
No. It is a planning and review document that runs in your browser. You still create or change responsibilities in the System Administration screens. Export it to Excel to share with your auditors or security team.
If you want to see which users hold which responsibilities and where roles overlap, we can build a read-only report assistant over your EBS security tables, hosted on your own servers.
Related Tools
Oracle EBS Concurrent Request Phase and Status Reference
Look up every common phase and status combination for a concurrent request, with what it means and the first thing to check.
OracleOracle EBS GL Period Close Checklist
A month-end close sequence for Oracle General Ledger and the subledgers that feed it, with critical steps marked.
OracleOracle EBS SQL for Concurrent Requests Generator
Build ready-to-run SQL for recent, running, pending and long-running concurrent requests from a few filter fields.
More Oracle tools
See all- Oracle EBS Inventory Tables Reference
- Oracle EBS WIP Tables Reference
- Oracle EBS Cycle Count Workload Calculator
- Oracle EBS Discrete Manufacturing Go-Live Checklist
- Oracle EBS Inventory Accuracy Readiness Assessment
- Oracle EBS AP Invoice Interface Template
- Oracle EBS 12.2 Upgrade Readiness Checklist
- Oracle EBS Patching Checklist for adop
- Oracle EBS Support End-Date Planning Calculator