EBSintermediate
Multi-Org Access Control (MOAC)
Explain how EBS R12 enables users to access multiple operating units without switching responsibilities
Before R12, seeing three operating units meant three responsibilities and switching between them. MOAC lets one responsibility see several.
MOAC is like a hotel master keycard that opens multiple rooms (operating units) without needing a separate key for each — but the hotel's security system (VPD) still checks silently behind the scenes that the card is authorized for each room before letting you in.
Key Concepts
1
The setup.
security profile lists the operating units
MO: Security Profile points the responsibility at it
MO: Default Operating Unit which one is selected on entry2
How the filtering works, and this is the part worth knowing. EBS uses Virtual Private Database policies
on the transactional tables.
3
AP_INVOICES_ALL every invoice, in every operating unit
AP_INVOICES a view with a VPD policy applied4
Query the view and Oracle appends a predicate based on the operating units in your session context. The
same SQL returns different rows for different users, with nothing in the query saying so.
5
MO_GLOBAL.INIT is what establishes that context at login.
MO_GLOBAL.INIT
6
Which produces the classic support call: "the invoice is not there". It is there. The session's security
profile does not include its operating unit, so the policy filters it out.
7
the user sees nothing wrong -- no error, just no rows
SELECT ... FROM ap_invoices_all WHERE invoice_num = 'X' -- finds it8
Checking against the _ALL table is the diagnostic: if the row exists there and not through the view, it is
MOAC, not missing data.
_ALL
9
Debugging it, in order.
1. Which operating unit is the transaction in? `SELECT org_id FROM ..._ALL`
2. What is the user's `MO: Security Profile`?
3. Does that security profile include that operating unit?
4. Has the profile changed since the user logged in? The context is set at login.SELECT org_id FROM ..._ALLMO: Security Profile
10
Step 4 catches people. Adding an operating unit to a security profile does not reach a user who is already
logged in.
11
Include org_id in your WHERE clauses anyway. The policy will filter correctly without it, but the
optimiser plans better when the predicate is explicit — on a large table that is a real difference, and it
is the recommendation in Oracle's own guidance.
org_idWHERE
12
The _ALL convention. A table ending _ALL holds every operating unit's rows; the view without the
suffix is the secured one. Custom code querying _ALL directly bypasses the security entirely, which is
occasionally necessary and usually a mistake.
_ALL
13
What the interviewer is probing.1. "What problem does MOAC solve?" Probing: the purpose. Stalls: "Security." Moves up: one
responsibility accessing several operating units, instead of a separate responsibility per unit as
in 11i.
14
2. "How is access granted?" Probing: the mechanism. Stalls: "A profile option." Moves up:
a security profile listing the operating units, assigned through the MO: Security Profile profile
option, with MO: Default Operating Unit setting the default.
15
3. "What must custom code do to work under MOAC?" Probing: the development angle. Stalls:
"Nothing." Moves up: initialise the org context with MO_GLOBAL.INIT and set the operating unit, or
it reads either nothing or the wrong data.
16
4. "What are the _ALL tables?" Probing: the data model. Stalls: "Backups." Moves up: the
base tables holding every operating unit's rows; the synonyms without the suffix are views filtered
by the current org context.