Make access decisions
with the facts beside you.

Someone needs access to a project. Their manager needs to decide whether it is appropriate. An identity specialist needs the approved change to reach the right application. These people are working on the same request, but they need different information to do their part well.

Our team's experience implementing midPoint shaped easyIGA. midPoint can represent complicated roles and relationships. The everyday user still needs an understandable answer to a practical question: what am I requesting, why is it needed, and what happened after the decision?

easyIGA brings that work into a business-facing workspace. Employees use business names for access. Managers see the context available for their decision. Specialists retain midPoint's technical controls and its responsibility for applying configured policy. Each person can concentrate on the part they are responsible for.

In the walkthrough, you see the same request from the employee’s and approver’s perspectives. The employee chooses understandable access and explains the need. The approver sees the request in context and makes the decision. Both work with the same request, without needing the same technical knowledge.

easyIGA keeps the result understandable as the request moves forward. A person waiting for access can distinguish approval from a completed change. If the connected system has not confirmed the outcome, that remains visible. Your team knows which work is complete and which needs follow-up.

Separation of duties, often shortened to SoD, addresses access combinations that should not be held together. For example, an organisation might separate the ability to prepare a payment from the authority to approve it. The exact rule belongs to your business process and must be configured accordingly.

easyIGA presents conflicts reported by midPoint's configured policies at decision time. An approver can see the reported issue while considering the request. This puts the concern beside the action that needs judgement, where it is more useful than an unexplained warning discovered later.

The coverage depends on the policies and systems in scope. A screen with no reported conflict does not establish that every possible combination has been checked. In your evaluation, ask us to identify the rule behind a warning and explain what happens when a relevant policy has not been configured.

Approval authority also matters. A manager should see and act on the work they are authorised to handle. The demo is an opportunity to examine that experience using the relevant persona, including cases where information is unavailable because of permissions. An administrator's broad view is not a substitute for testing the manager's actual working view.

A list of checkboxes can tell you that a review was completed. It says less about whether the reviewer understood the access. The business meaning of a role, the person's current work and the available grant history all affect the quality of the answer.

In easyIGA, reviewers see the person’s access alongside the available context and record what should stay or be removed. They can concentrate on whether the access still fits the person’s work, rather than collecting information from separate records. Missing source information is marked so it can be followed up.

For example, a colleague has left a project but still holds its access. The reviewer can consider the person’s current responsibility, available history and reason for retaining the permission. A removal decision remains connected to the resulting change, so closing the review does not hide work still outstanding in an application.

Your deployment defines the review population, responsible reviewers and supported campaign tasks. Specialists retain the midPoint administration needed to configure the process. Employees and managers use the easyIGA workflows agreed for the deployment.

The same distinction applies to reporting. Agree the evidence your reviewers and auditors need, the records that are retained and the permitted export process. A completed campaign and a confirmed removal answer different questions. A useful evaluation checks both rather than relying only on a completion percentage.

The walkthrough separates available features from planned development. We show the release and configuration being discussed, connect its capabilities to your tasks and agree what belongs in your deployment.

Your team may also need directory information, delegation or a connection to collaboration tools. We establish the supported scope for your release and configuration during the walkthrough, then include the agreed tasks in the implementation plan.

People remain responsible for access decisions. Any AI assistance needs to support that responsibility and respect the authority configured in midPoint. Its availability and data handling are established for the proposed release before it becomes part of your deployment.