🔑 OasisPro · Projections and Actions · IFS Cloud Security Mechanics
IFS Cloud projections and actions,
6 essential facts to get right.
IFS Cloud projections and actions come up constantly, because IFS Cloud projections and actions sit at the centre of every serious conversation about IFS Cloud security, and they are rarely explained beyond the phrase itself. This is the plain language version: what a projection actually is, what an action actually is, and why permission sets built from the two behave so differently to the presentation object model IFS Applications 10 used.
Understanding IFS Cloud projections and actions properly does not require a development background. It requires seeing the shape of the mechanism once, clearly.
Here are the 6 facts that make the rest of IFS Cloud security make sense.
A projection is what data a permission set can touch. An action is what it can do to that data. Almost every confusing IFS Cloud projections and actions problem traces back to conflating these two, separate, questions.
A user seeing a record but unable to edit it, or able to run a process but not view its underlying data, is not a bug. It is two different access decisions, at two different levels of the same mechanism, working exactly as designed. Once the projection and action distinction is genuinely clear, most permission puzzles stop being puzzles.
The 6 essential facts about IFS Cloud projections and actions
- 1. A projection is a defined slice of the data model. It groups related entities and fields for a specific purpose, exposed through OData, and it is the layer almost everything in IFS Cloud reads and writes through.
- 2. An action is an operation available within that projection. Create, update, delete, or trigger a specific business process. Permission sets grant or deny at this level, which is where the real granularity lives.
- 3. Read access and write access are genuinely separate decisions. A permission set can expose a projection for viewing without granting any of its actions, which is why users can legitimately see data they cannot change.
- 4. This is decoupled from any specific screen. Unlike a presentation object tied to one window, a projection can be consumed by multiple screens, reports and Lobbies at once, which is powerful and also why a single permission change can have wider effects than expected.
- 5. There is no direct migration path from Applications 10 permissions. The presentation object model and the projection and action model are different enough that access genuinely needs redesigning during an upgrade, not translating.
- 6. Lobbies, reports and integrations all sit on top of the same mechanism. A permission change to a projection can affect Lobby visibility, Report Studio output and API access simultaneously, since all three ultimately read through the same layer.
Projection, in one sentence
The defined window through which a piece of software looks at IFS Cloud's data. No projection, no access, regardless of what else a permission set grants.
Action, in one sentence
What you are allowed to do once you can see through that window. Read is one action among several, not the whole answer to what access means.
Permission set, in one sentence
A named bundle of projection and action grants, assigned to a role, that together define exactly what someone can see and do across the system.
Why this explains the Lobbies dependency
A Lobby element pulling data through a query builder or information source is ultimately reading through a projection like everything else. Change the projection's access grant, and every consumer of it, screens, reports and Lobbies alike, can be affected at once. That is the actual mechanism behind the permission dependency Lobbies carry, not a special case but the same rule applying consistently.
Using IFS Cloud projections and actions to diagnose access problems
When a user reports they can see something but not act on it, check the action grant first. The projection is clearly working; the specific action is not.
When a permission change breaks something unexpected, check what else consumes the same projection. Reports, Lobbies and integrations built on it are all affected together, not in isolation.
When designing a new role from scratch, think in terms of which specific projections it genuinely needs and which actions within them, rather than which screens the person happens to open day to day.
The IFS documentation site covers projection and action configuration in genuine technical depth, and the IFS Community has active, ongoing discussion on diagnosing specific permission issues through exactly this lens.
Our role design guide covers turning this mechanism into a maintainable set of roles in practice.
What you can see and what you can do are two different questions in IFS Cloud. Design and diagnose accordingly, and most permission confusion disappears.
A short worked example of projections and actions
A purchasing clerk needs to see supplier records, which requires read access to a supplier projection.
They also need to raise purchase orders, which requires the create action within a separate purchase order projection.
Grant the first without the second, and they can find a supplier but never order from them.
Grant both projections and actions correctly, and the role finally matches what the job actually requires. Neither grant alone tells the whole story, which is exactly the point.
PermissionWorks builds sets that respect this mechanism properly.
Rather than guessing at screen-level access the way an Applications 10 mindset encourages, PermissionWorks generates permission sets grounded in the actual projection and action model, validated against real navigation, so what gets built matches how IFS Cloud genuinely works underneath.
Why the Apps 10 security model does not transferGet a permission problem diagnosed properly.
Send us a specific access issue you cannot explain, a user who can see something but not act on it, or the reverse. We will trace it through the actual projection and action grants and show you exactly where the gap sits.
What is a projection in IFS Cloud?
A projection is a defined slice of IFS Cloud's data model, exposed through OData, that a client application or report can read from or write to. It groups related entities and fields together for a specific purpose, and it is the layer through which almost everything in IFS Cloud, including permission sets, actually touches data.
What is an action in IFS Cloud, in the security context?
An action is a specific operation available within a projection, such as creating a record, updating a field, or triggering a business process. Permission sets grant or deny access at the level of these actions, which is what gives IFS Cloud its granularity: two users can read the same data but have very different ability to change it.
How is this different from IFS Applications 10 security?
Applications 10 controlled access largely through presentation objects, tied to the specific screens and windows a user could open. IFS Cloud's projection and action model is decoupled from any particular screen, which is more flexible and more powerful, but does not map one-to-one onto an Applications 10 permission set, which is why access needs redesigning rather than migrating during an upgrade.
Do I need to understand projections and actions to design permission sets?
Not in full technical depth for most day-to-day work, since standard permission sets and role-based tooling abstract much of this away. Understanding the concept, however, particularly why access is granted at the level of a specific action within a projection rather than a whole screen, makes it far easier to diagnose why a user can see something but not act on it, or the reverse.
IFS Cloud projections and actions are worth understanding, not just naming
IFS Cloud projections and actions form a genuinely short mental model together, and understanding IFS Cloud projections and actions pays for itself the very first time you diagnose something real.
The terms get used constantly around IFS Cloud security, and the mechanism behind them is simpler than the vocabulary suggests once you see it clearly.
Data access flows through a projection, and operations flow through an action, with both genuinely decoupled from any single specific screen a user happens to open.
Understand that shape, and permission set design, Lobby dependencies and access diagnosis all get considerably easier at once, because they all trace back to the same two underlying questions.