📝 OasisPro · Access Request Workflow · PermissionWorks
"Same access as Sarah." Sarah's access was already wrong.
IFS Cloud access requests are where most access problems actually begin, long before an access review or an audit ever finds them. "Give them the same access as Sarah" feels like a fast, reasonable shortcut, right up until you remember that nobody's actually confirmed Sarah's access was correct in the first place.
A flawed access request approval workflow doesn't just grant one wrong permission. It copies whatever wrongness already existed forward, onto a new person, and the cycle repeats every time someone else gets provisioned "the same way."
Here are the 6 IFS Cloud access requests workflow mistakes that turn a request process into a risk multiplier instead of a control, inside IFS Cloud.
Every bad access grant sitting in your environment started as a request that got approved. The workflow that approved it is either catching problems before they multiply, or quietly copying them forward onto the next person.
An access review finds problems after they exist. A well-designed request workflow is what actually prevents most of them from being created in the first place.
The 6 IFS Cloud access requests workflow mistakes
- 1. "Same access as" requests copy existing access instead of defining need. This shortcut assumes the person being copied has correct access in the first place, which is rarely actually verified. Any error in the original access gets carried forward onto the new request.
- 2. No named, accountable approver. A request routed to a generic queue or team inbox has no single person actually accountable for the decision, which makes both the approval and any later question about it much harder to trace.
- 3. Approval happens without visibility into what's actually being granted. An approver signing off on a request description, without seeing the actual Projection and Action grants behind it, is approving intent, not the real outcome.
- 4. No segregation of duties check at request time. Checking for SoD conflicts only during a periodic access review, rather than at the moment a request is approved, means a conflict can sit live in the environment for months before anyone catches it.
- 5. No expiration on requests meant to be time-limited. A request granted "for this project" or "for this quarter" needs an actual expiration date attached, or it quietly becomes permanent the same way contractor and emergency access does.
- 6. Informal or verbal requests bypass the workflow entirely. A quick verbal "just give them access" that skips the formal request process leaves no record at all, which makes it invisible to every other control on this list.
Why "same as" is the most common workflow mistake
It feels efficient and rarely gets questioned, which is exactly why it's such a reliable way to propagate an existing access error onto someone new.
Why approvers need to see actual grants, not descriptions
A written request description and the real Projection and Action grants behind it can differ. An approver who never sees the second one is only approving the first.
Why the SoD check belongs at request time, not just in reviews
Catching a conflict before it's granted costs nothing. Catching the same conflict six months later, in a periodic review, means it's been live and exploitable the whole time in between.
The single question that catches the most risk
Does this request define what the person actually needs, or does it just copy someone else's access? If it's the second one, the approver is signing off on whatever errors already existed in that other person's access, sight unseen.
How to build a request workflow that actually prevents risk
Require every request to state the specific task or function driving the need, rather than accepting "same as" another person as a sufficient justification on its own.
Route every request to a named, accountable approver who can see the actual grants involved, not just a written description of the request.
Run an automatic SoD check at the moment of approval, not only during a later periodic review.
"Same access as Sarah" is not a defined need. It's an assumption that Sarah's access was correct in the first place.
What a proper request workflow actually prevents
An access error that started with one person's incorrect grant, quietly copied forward onto every subsequent "same as" request that followed.
A segregation of duties conflict granted at request time and only discovered, already live for months, during the next periodic access review.
An informal, undocumented grant that's invisible to every other control, simply because it never went through the request workflow at all.
We'll check whether your request workflow is copying errors forward.
PermissionWorks traces "same as" requests back to their source access, checks for SoD conflicts at the point of approval, and flags requests with no named accountable approver.
See our role design guideStop copying access errors forward, request by request.
Send us your current access request process and we'll show you where "same as" requests, missing SoD checks, or missing approver accountability are creating risk before it ever reaches a review.
Why is a 'same access as' request risky?
Because it assumes the person being copied already has correct access, which is rarely actually verified. Any existing error in that person's access gets carried forward onto the new request, and can keep propagating to every subsequent request that copies it again.
Why does an approver need to see the actual permission grants, not just a description?
Because a written request description and the real Projection and Action grants behind it can differ. An approver who only reviews the description is approving intent, not the actual outcome of the request.
Should segregation of duties be checked during the request process itself?
Yes. Checking only during a periodic access review means a conflict introduced by a request can sit live and exploitable in the environment for months before anyone catches it.
What happens to informal or verbal access requests?
They bypass the entire workflow, which means they are invisible to every other control, no named approver, no SoD check, no expiration date, since they were never actually logged as a request in the first place.
Fix the request, not just the review
Most access problems don't start with a review that missed something. They start with a request that was approved too quickly, copying an existing error forward instead of defining what was actually needed.
Six mistakes, all of them preventable at the point of request, before they ever need to be caught later.