Inside the RMC Module: The Role Request and Approval Workflow
A closer look at how access requests move from submission to review, approval, and expiry in RMC.
Introduction
This blog builds on the earlier overview of the Oracle Fusion Risk Management Cloud (RMC)
module and takes a closer look at one specific, practical piece of it: the end-to-end
role request and approval workflow, and how it governs the way access actually gets granted.
Role Request and Approval Workflow
One of the more practical aspects of the RMC module is how it governs the actual process
of requesting and granting access, not just monitoring access after the fact.
When a user needs a role, they raise a request through the module, and this request
isn’t restricted to self-service. A user can also raise a role request on behalf of
another person, which is common when a manager or admin is provisioning access for a
new team member or covering a gap during someone’s absence.
A distinct capability worth calling out is Procurement Agent Access,
which appears as a separate data-access option during the request process.
Unlike a standard role grant, this is a specific data-level access setting tied to
procurement transactions, meaning it controls what transactional data a procurement
agent can see or act on, independent of the broader role assignment.
This matters because in procurement-heavy environments, data access is often more
sensitive than the role label itself.
Every role request line carries two key identifying details:
- Display Name of the role being requested
- Security Context
These details allow whoever reviews the request to see exactly what is being asked for
and in what functional area it applies, rather than seeing a generic role name with
no context.
Two Distinct Decision Points: Reviewer and Approver
The workflow deliberately separates the process into two roles with different weight:
-
Reviewer:
The Reviewer provides an advisory opinion, flagging concerns, adding context,
or recommending a course of action, but without final authority. -
Approver:
The Approver makes the binding decision on the access request.
At both stages, the person can act on each conflicting role individually using:
- Accept Risk
- Decline Risk
When a request contains multiple conflicting roles, the reviewer or approver can also
take bulk actions using:
- Accept All
- Decline All
This is important in practice because a single request can surface several
Segregation of Duties (SoD) conflicts simultaneously.
What the Requester Must Justify
Before a request can move forward, the requester has to provide real risk-management
documentation, not just a reason for wanting access.
The request includes the following information:
- Business Justification — the operational reason the access is needed.
-
Risk Justification — why the resulting risk is acceptable given
that reason. -
Risk Acceptance — an explicit acknowledgment that the risk is
understood and being taken on. -
Mitigation Plan / Strategy — what controls will offset the risk
while the access is active. -
Expiry Date — the access is granted for a bounded period,
not indefinitely.
This is significant because it turns every risky access grant into an auditable,
time-boxed decision with a documented rationale, rather than a standing exception
nobody remembers the reason for.
Risk Impact Section Shown to the Reviewer / Approver
To support their decision, the reviewer and approver see a structured
risk-impact breakdown.
The information presented includes:
- Risk Level — High, Medium, or Low.
-
Conflicting Roles — the specific roles in conflict,
for example AP Invoice Entry vs. Payment Processing. -
Potential Fraud or Risk — a description of what could
actually go wrong operationally if the access is approved.
This information provides the reviewer and approver with the context required
to understand the impact of granting the requested access.
Segregation of Duties Enforced on the Approval Process Itself
Notably, the tool applies SoD logic to itself: a requester cannot approve
their own request.
This restriction extends to requests they raised on behalf of someone else.
This closes an obvious loophole, since someone provisioning access for a
colleague can’t also be the one who signs off on it.
Line Manager Involvement
The requester’s line manager is automatically pulled into the approval chain,
adding organizational accountability beyond the security or access team alone.
Decision Analytics for the Approver
When a ticket reaches the approver, they’re shown a decision-support summary
rather than having to dig through the conflict list manually.
The summary includes:
- Total violations
- High-risk count
- Medium-risk count
- Low-risk count
- Approval probability
- Option to withdraw the ticket
This gives the approver an at-a-glance risk profile before they commit
to a decision.
How This Fits Into the Broader RMC Module
This request-and-approval workflow sits on top of the same risk logic that
powers the rest of RMC.
The SoD conflicts flagged during a request are generated by the same models
and controls used for ongoing monitoring, and any exceptions granted here
feed back into the audit and certification processes covered elsewhere in RMC.
In short, this workflow is where RMC’s risk detection becomes an actual,
auditable decision, rather than just a report.
Conclusion
The role request and approval workflow is one of the more practical parts
of the RMC module because it turns risk detection into a real decision point.
Every request carries its justification, its risk impact, and an expiry date;
every approval path separates advisory review from final sign-off; and the
tool enforces its own segregation of duties by blocking self-approval and
pulling in the line manager automatically.
The decision analytics shown to the approver make it possible to act on all
of this quickly, without digging through the conflict list manually.
