⚙️ OasisPro · Projections and Actions · Security Model · PermissionWorks
Everyone says "Projections and Actions."
Almost nobody can explain them.
IFS Cloud projections and actions are the terms every permission review, every access audit, and every security discussion in your IFS Cloud environment uses constantly, and almost nobody actually explains what they do. Not vaguely, not "it's like the old permission sets." Precisely: what determines whether a specific user can see a specific field or run a specific button.
Every permission set you design without understanding this mechanism is a guess dressed up as a decision. Too permissive, and you've created risk. Too restrictive, and you've created a support queue full of "why can't I click this" tickets.
Here are the 6 facts that make it concrete.
Applications 10 mapped permissions to windows. IFS Cloud maps them to Projections and Actions, and that single change is why re-mapping your old permission sets one-for-one is guaranteed to get you the wrong result.
This isn't a rename. It's a structurally different model, cutting access at the level of data exposure and specific operations instead of screens. Every access review, every SoD conflict, every permission project cost estimate traces back to this layer.
The 6 facts about IFS Cloud projections and actions
- 1. A Projection is a data access surface, not a permission. It defines which entities and fields a piece of functionality can see and touch. Access is granted at the level of Projection plus Action, never at the Projection alone.
- 2. There's no clean equivalent of the old Applications 10 window mapping. Projections cut across what used to be separate screens. One Projection decision can touch far more functional territory than any single old-model permission did.
- 3. Every button, field-level action and OData verb maps to a specific Action. Granularity is finer than the old model, which means more precision and, unavoidably, more permission sets to review.
- 4. Permission Sets bundle Projection and Action pairs, and Roles bundle Permission Sets. A broad Role can quietly re-introduce an Action you thought you'd restricted lower down the stack.
- 5. Restricting a Projection does not automatically restrict every Action inside it. You have to check Action-level grants specifically. Assuming Projection-level restriction cascades down is the single most common security review mistake.
- 6. Every downstream security decision traces back here. Access review findings, segregation of duties conflicts, permission project cost estimates: all of it sits on top of this Projection and Action layer.
What a Projection actually controls
Data visibility. Which entities, which fields, which records a piece of functionality can reach. Nothing about whether a user can act on that data yet, that's a different layer entirely.
What an Action actually controls
Operations. A specific button, a status transition, a create, update or delete. Two users can see identical data through the same Projection and have completely different Actions available.
Where reviews miss the risk
Checking whether a Role exists, without tracing it down through Permission Sets to the actual Projection and Action pairs it grants. That's checking the label, not the access.
The mistake every migration project makes at least once
Re-mapping Applications 10 permission sets one-for-one onto IFS Cloud Roles. It doesn't work, because there's no clean equivalence between the old window-based model and the new Projection-and-Action model. Permission sets need to be redesigned against the new mechanism, not translated from the old one.
Why this matters for every other PermissionWorks post you'll read
An access review that flags "this Role looks wrong" without understanding which Projection and Action pairs that Role actually grants is guessing at the fix.
A segregation of duties conflict is, underneath, always a conflict between specific Actions across specific Projections, not an abstract clash between job titles.
A permission project's cost is driven almost entirely by how many Projection and Action combinations need designing and testing, which is exactly why estimates that skip this layer are consistently wrong.
"Projections and Actions" isn't jargon to nod along with. It's the actual mechanism deciding what every user in your system can do.
What understanding this mechanism actually buys you
Permission sets you can design with intent, instead of trial and error against support tickets.
Access reviews that trace findings to the actual Projection and Action pair, instead of a vague "this Role seems too broad."
A permission project estimate built on the real driver of cost, not a flat per-user or per-role rate that ignores how the system actually works.
We'll map this against your actual system.
PermissionWorks traces every Role down through Permission Sets to the specific Projection and Action pairs it grants, so your team can see exactly what "access" means for every user, not just what the Role name implies.
See how this feeds into an access reviewStop designing permission sets against a model you can't see.
Send us a sample of your current Roles and Permission Sets, and we'll map them down to the actual Projection and Action pairs they grant, flagging anything broader than intended.
What is the actual difference between a Projection and an Action?
A Projection defines what data is exposed: which entities and fields a piece of functionality can see and touch. An Action is a specific operation within that Projection: a button, a status change, a create or delete. Access control happens at the combination of both, not at either alone.
Is restricting a Projection enough to lock down a feature?
No, and this is the mistake teams make most. Restricting the Projection limits data visibility, but individual Actions inside it can still be granted separately. You have to check both layers, not assume one controls the other.
How does this compare to the old Applications 10 permission model?
Applications 10 mapped permissions to specific windows and screens. IFS Cloud's Projections cut across what used to be separate screens entirely, so a single Projection can span more functional territory than any one old-model permission ever did, which is why permission sets need re-designing, not just re-mapping, during a migration.
Where does this actually matter for an access review?
Everywhere. A permission review that only checks which Roles a user has, without understanding which Projection and Action pairs those Roles ultimately grant, is checking the label, not the actual access. This mechanism is the ground truth every review should trace back to.
Understand the mechanism before you design against it
Every permission decision in IFS Cloud comes down to Projections and Actions, layered under Permission Sets and Roles. Skip understanding it, and every review, every design choice, every cost estimate downstream is built on a guess.
Learn it once, properly, and everything else built on top of it gets faster and more defensible.