🏢 OasisPro · Multi-Company Access · PermissionWorks
One entity's access. Another entity's data, visible.
IFS Cloud multi-company access design mistakes don't stay contained the way a single-entity mistake does. A Role built without company scoping in mind doesn't just create risk for one business unit, it multiplies that same risk across every company sharing the same IFS Cloud environment.
Multi-entity organizations often get access design right for a single company and then simply reuse it everywhere, assuming what worked once will work the same way across boundaries that were never actually checked.
Here are the 6 mistakes that let access leak across company boundaries in IFS Cloud nobody meant to cross.
A Role that's correctly scoped for one company and copied to the next without re-validation isn't a shortcut. It's the same design decision, made once, now multiplied by however many entities share the environment.
Multi-company IFS Cloud environments don't just add complexity linearly. Every access design decision made without company scoping in mind gets replicated across every entity using the same setup.
The 6 IFS Cloud multi-company access design mistakes
- 1. Roles designed without company or site scoping from the start. A Role built for a single-entity mindset and then applied across a multi-company environment can grant broader visibility than anyone intended, simply because scoping was never part of the original design.
- 2. Assuming read-only access is automatically safe across company boundaries. Visibility into another entity's data is still exposure, even without the ability to change anything. Financial and operational data crossing company lines is a real risk, read-only or not.
- 3. Shared service center roles granted broad access without cross-entity checks. A shared services team legitimately needs access across multiple companies, but that access still needs the same scrutiny any broad grant deserves, not an automatic pass because the team's function justifies it.
- 4. Segregation of duties conflicts checked within one entity but not across them. A conflict pair split across two companies, create in one, approve in another, can be just as real a risk as the same conflict sitting inside a single entity, and it's easy to miss if SoD checks stop at company boundaries.
- 5. No defined process for access when someone moves between companies. An internal transfer between entities is a joiner mover leaver event too, and without a specific process for it, old-entity access has no natural trigger to be removed.
- 6. Permission Sets copied across companies without re-validating scope. Reusing a Permission Set that worked for one entity as a starting point for another, without checking whether its scope is actually appropriate for the new context, is how a single design decision becomes a systemic one.
Why "read-only" gets a pass it shouldn't
Read-only access across a company boundary still exposes financial or operational data one entity was never meant to see, regardless of whether anything can be changed.
Why shared service roles need extra scrutiny, not less
Broad access is often genuinely necessary for a shared services function, which is exactly why it deserves more specific review, not an automatic exemption because the need seems obvious.
Why cross-entity movers are the joiner mover leaver gap nobody planned for
An internal transfer between companies is still a mover event, and without a specific process for it, the old entity's access has no trigger to be removed.
The default that causes the most damage
Copying a Permission Set from one company to another as a starting point, without re-validating its scope for the new context. It feels efficient. It's actually how a single unscoped design decision becomes a pattern repeated across every entity in the environment.
How to design multi-company access properly
Build company or site scoping into Role design from the start, rather than retrofitting it after a single-entity Role has already been copied elsewhere.
Run segregation of duties checks across company boundaries specifically, not just within each entity independently.
Treat a company transfer as its own joiner mover leaver event, with old-entity access explicitly removed, not assumed to fall away on its own.
A Role copied across companies without re-validation isn't reuse. It's the same gap, now open in three places instead of one.
What getting multi-company access right actually prevents
A finance team member in one entity able to see, or worse approve transactions in, another entity's data, discovered by an audit instead of by design.
A segregation of duties conflict spread across two companies that never gets caught because SoD checks stopped at each entity's own boundary.
An access review that has to untangle years of copied Permission Sets, none of which were ever individually validated for the entity they ended up in.
We'll check whether your access design actually respects company boundaries.
PermissionWorks checks Roles and Permission Sets across your IFS Cloud entities for unscoped access, cross-entity SoD conflicts, and copied Permission Sets that were never re-validated.
See our segregation of duties guideFind out where access is crossing company boundaries.
Send us your current Roles and Permission Sets across your IFS Cloud entities, and we'll flag unscoped access, cross-entity SoD conflicts, and copied Permission Sets that were never re-validated.
Why is multi-company access design riskier than single-entity design?
Because a design mistake made once does not stay contained. A Role built without company scoping and then reused across entities multiplies the same gap across every company sharing the environment, rather than creating one isolated issue.
Is read-only access across company boundaries actually a risk?
Yes. Visibility into another entity's financial or operational data is still exposure, even without the ability to change anything, and it deserves the same scrutiny as any other cross-boundary access.
Do segregation of duties checks need to cover multiple companies?
Yes, specifically. A conflict pair split across two entities, creating a transaction in one and approving it in another, can be just as real a risk as the same conflict inside a single company, and SoD checks that stop at entity boundaries will miss it.
What happens when someone moves between companies internally?
It should be treated as its own mover event, with the previous entity's access explicitly removed. Without a specific process for cross-entity transfers, old access has no natural trigger to be revoked.
Scope access to the entity, not just the role
A single access design decision made without company boundaries in mind doesn't stay small in a multi-entity environment. It gets copied, and copied again.
Six mistakes, all of them multiplying risk instead of just creating it once. Check for them across every entity, not just the first one.