All topics
9 / 60
EBSbeginner

System Administrator Responsibility and Setup Hierarchy

Understand the standard setup sequence a System Administrator follows when configuring a new EBS instance

The System Administrator responsibility configures everything technical: users, responsibilities, menus, profile options, printers, concurrent programs.

Setting up System Administrator hierarchy is like designing an org chart with keycards: you first design which doors exist (menus/functions), then create keycard profiles bundling specific doors (responsibilities), and finally issue keycards to individual employees (users) matching their job needs.

Key Concepts

1
Every implementation starts here, before any functional setup.
2
The order the foundation is built in.
    1. Application and Data Group     which schema, which product
    2. Menus                          group the functions to expose
    3. Request Groups                 which concurrent programs
    4. Responsibilities               menu + request group + data group
    5. Users                          and their responsibilities
3
Each step depends on the one before. You cannot assign a responsibility that does not exist, and a responsibility with no menu exposes nothing.
4
What else sits here.
    Request Sets   several concurrent programs run together, in
                   sequence or in parallel, as one submission
    Printers       and their styles and drivers
    Value Sets     shared by flexfields and program parameters
    Alerts         periodic or event-driven notifications
5
Request sets are worth knowing. A month-end close is a dozen programs in a specific order with dependencies. A request set submits them as one thing, with stages that run in sequence and steps within a stage that run in parallel.
6
Menu exclusions are where segregation of duties actually happens. Rather than building a menu per role, the usual pattern is one broad menu with functions excluded per responsibility.
7
    Menu: PO Superuser
      Create Purchase Order
      Approve Purchase Order
      Receive
8
    Responsibility: PO Clerk -- exclude "Approve Purchase Order"
    Responsibility: PO Manager -- exclude "Create Purchase Order"
9
And that is where the audit finding comes from. A single responsibility permitting both creation and approval of a purchase order lets one person commit the company to a supplier unchecked.
10
The same applies to creating a supplier and paying one, and to entering a payment and approving it. Those combinations are what an auditor looks for, and they are produced by a menu nobody pruned rather than by a deliberate decision.
11
So the practical skill is being able to look at a responsibility and say what it permits — by walking its menu and its exclusions — rather than trusting the name it was given.
12
What the interviewer is probing.1. "How does a user get to a function?" Probing: the chain. Stalls: "A permission." *Moves up:* user to responsibility, responsibility to menu, menu to submenus and functions — with exclusions removing specific items.
13
2. "What is a request group?" Probing: the vocabulary. Stalls: "A folder." Moves up: the set of concurrent programs a responsibility can submit, attached through the responsibility definition.
14
3. "How would you give someone read-only access to a form?" Probing: the practical question. Stalls: "You cannot." Moves up: a function with a query-only parameter, or form personalisation disabling entry — not by editing the form.
15
4. "What is the data group for?" Probing: the detail. Stalls: "Nothing." Moves up: mapping applications to the schema the responsibility connects as, which almost always resolves to APPS.
Use cases:system-administratorsetupsodresponsibilitiessecurity