One person.
Several campus roles.

One person can belong to a university in several ways

A doctoral researcher may also teach and hold a paid staff appointment. A student can become an employee without leaving the university community. A visiting academic can retain a research relationship after a teaching assignment ends. Those overlapping relationships make identity governance more involved than a single active-or-inactive record.

easyIGA gives people a business-facing way to request, approve and review application access. midPoint underneath provides the configured identity data, policies and target-system changes. This lets academic and administrative decision makers participate in access governance while identity specialists maintain the technical model.

The useful starting point is a relationship the institution needs to govern. Identify the authoritative record, the application access associated with it and the person who can decide on an exception. Then examine what should happen when one relationship ends but another remains.

For a service owner, the useful question is which current relationship justifies a permission. A researcher may still need a project application after their teaching appointment ends, while access associated only with teaching needs a fresh decision. easyIGA gives the responsible people a readable way to assess that need. The illustrative examples below follow overlapping affiliations, guest access and semester changes through the identity sources, business decisions and application outcomes that the institution needs to manage.

Model affiliation before automating account changes

A university can receive identity information from a student information system, HR and local guest registers. Each source describes a different relationship. The implementation needs to determine which facts are authoritative and how records referring to the same person are related.

Start with a small set of affiliation cases. A person with only a student relationship is different from a student who also holds a staff appointment. An honorary relationship may have another access policy. The business meaning of each should be agreed before the identity team configures the corresponding permissions.

midPoint supports a configured identity model and synchronisation with connected sources. The organisation still needs to decide how an attribute affects access. A useful model avoids treating the end of one relationship as proof that every relationship has ended.

For an evaluation, use a synthetic person with two concurrent affiliations. End one of them and inspect the intended permissions. Which access follows the remaining relationship? Which access must be removed? Which exceptional permission requires an explicit decision from its owner?

Also test a mismatch between sources. Similar names or changing email addresses should not be treated as sufficient evidence to merge two people. Agree how uncertain matches are investigated. Source quality and identity correlation are technical responsibilities that support the business workflow; a readable screen cannot compensate for an incorrect person match.

Make the start of term manageable for people as well as systems

A term boundary can bring a large set of expected identity changes. Some people are new, some return and some have a different relationship from the previous year. The institution needs a process that makes those changes understandable to users and operationally manageable for the identity team.

Begin by agreeing when a source record becomes authoritative for access. An application for admission, an accepted place and an enrolled student can have different meanings. The implementation should use the institution's actual rules rather than assuming that every record in the student system represents the same access entitlement.

For permissions granted through configured lifecycle rules, test the source event and the target operation. For access that requires a request, easyIGA provides a business-facing catalogue and a decision workflow. The two paths should be explained clearly so students and staff know when they need to ask for something.

Use a pilot population and representative applications. Confirm the behaviour for a new person and a returning person. Include a record that is incomplete or arrives after the expected date. The operating procedure should identify who corrects it and how the affected user receives a useful answer.

Avoid inferring performance from a small demonstration. A term-scale rollout needs testing with the proposed configuration and workload. Record the evidence needed for capacity and recovery decisions separately from the business users' assessment of the request interface. Both matter, but they answer different questions.

Let academic staff request access by purpose

An academic may need a teaching application, a shared research workspace or an administrative role. A catalogue that exposes only technical group names leaves the requester guessing. It also makes the approver's job harder because the request does not explain what access means.

easyIGA gives employees and managers a readable starting point for an access request. The institution maps each business description to a configured role and decides who can authorise it. Identity specialists remain responsible for the underlying midPoint configuration and the target integrations.

Consider an illustrative request to administer a departmental teaching application. The description should distinguish ordinary use from administration. The approval route should reach the person who owns that responsibility, which may differ from the requester's line manager.

During the walkthrough, ask the academic to identify the role they need without guidance from an identity specialist. Then ask the approver to explain the decision from the information shown. This is a direct way to assess whether the catalogue and workflow fit the institution's language.

The result should be followed beyond approval. A successful decision does not prove that a target application accepted the change. easyIGA distinguishes verified, pending, failed and unknown outcomes, giving participants a more useful account of progress. Agree which team investigates an operation that has not reached a confirmed result.

Give visiting researchers a sponsor and a defined relationship

A visitor can be known to a department without appearing in the institution's main HR system. An informal arrangement can be perfectly legitimate while still needing an accountable access process. The key is to establish an approved identity record and a responsible internal sponsor.

The sponsor should understand why the visitor needs access and which applications are involved. A department name alone is not enough if nobody is responsible for reviewing the relationship later. Decide who maintains the record and what happens when the sponsor leaves or changes role.

Use the configured request process for the applications that require a decision. easyIGA can make those requests understandable to the sponsor and the relevant application owner. The implementation determines the supported approval route and the evidence available in the proposed release.

An evaluation should include an extension of the visit and a change of host department. The correct access may change even though the person's name and email address remain the same. Test the lifecycle event rather than assuming that a continued account proves every permission remains justified.

At the end of the relationship, distinguish the access that should end from any separately approved continuation. A collaboration can continue after a visit without requiring every administrative permission to remain. The institution needs an explicit policy and a reviewable decision for that transition, with the resulting target changes checked.

Review research access with the right owner

A central IT team can know that an account exists without knowing whether the person still belongs to a research project. The project owner may understand that relationship but lack a clear list of the application permissions involved. Access reviews bring those perspectives together.

easyIGA presents the access under review with available context. Last use, granted by and approved by depend on connected sources and captured approval history. The information should help the reviewer assess the permission, while missing evidence remains visible.

easyIGA records the requester and captured approval steps for requests made through the product. Access granted outside easyIGA is identified separately, using the creation details recorded by midPoint. Historical records may lack an approver or grantor; missing information is shown explicitly.

For a research example, identify the project and the application access being reviewed. A person may remain in the institution after leaving the project. Ask the reviewer whether the current relationship still justifies the permission, using the evidence actually available.

Recent activity and business need are different questions. Some research access is used infrequently but remains authorised. A last-use field should inform the decision rather than dictate it. Record the reviewer's conclusion through the supported workflow and follow any removal operation to its target outcome. This connects the review to action instead of leaving it as a periodic list-clearing exercise.

Handle alumni and former staff through explicit policy

The end of study or employment does not necessarily mean that every service relationship ends at the same moment. An institution may provide selected alumni services or retain a temporary administrative need. Those are policy choices that should be defined precisely.

Begin by listing the services involved and their owners. Determine which access follows a continuing relationship and which requires a separate decision. Avoid using one broad status to represent both a former employee and an alumnus if their access rules differ.

The midPoint configuration can connect authoritative events to the intended roles and target changes. easyIGA provides the request and review experience around the supported workflows. The institution must decide the policy and validate the operations that implement it.

A useful test follows a synthetic person from student to alumnus while another staff relationship remains active. Examine each application rather than judging success from the continued existence of the central identity. Some permissions may remain while others should end.

Also establish the process for mistakes and late corrections. A reversed departure or corrected study record can require restoration of some access. The implementation should demonstrate the agreed behaviour without assuming that every previous permission should automatically return. The policy should explain the result that the organisation wants, and the records should show what actually happened.

Keep application integration distinct from single sign-on

A person signing in successfully does not establish that their permissions are appropriate. Authentication and identity governance address related but different questions. The campus architecture should explain how the identity provider, target applications and governance engine work together.

midPoint supplies the configured identity management and provisioning foundation. An integration may manage a directory group that an application uses, or it may change accounts directly through an application interface. The implementation must identify which mechanism governs each permission in scope.

The midPoint connector catalogue gives technical teams a starting point. Validate the actual version and operations of the student system, directory or cloud service you intend to connect. A familiar product logo is not evidence that every required campus workflow is supported without configuration.

easyIGA adds business-facing access decisions above midPoint. It does not remove the institution's identity provider or make every midPoint administration feature available through an identical easyIGA screen. Compare the proposed release using one real application role and the people who need to work with it.

Where an integration is limited, document that limit. A target may supply account data without returning detailed usage history. The review process should not invent a last-use value to make the record look complete. Knowing which facts are available helps reviewers make a more careful decision and helps the team prioritise integration work.

Give technical accounts a lifecycle of their own

Research and administration can depend on accounts used by applications or scheduled processes. Such an account may outlive the person who created it. It should have a documented purpose and a responsible owner rather than be treated automatically as an ordinary staff identity.

Choose a representative account in a non-sensitive environment. Identify the service that depends on it, the permissions required and the team authorised to decide on changes. A person match and a service owner can be different relationships, and the identity model should make the intended meaning clear.

During an easyIGA evaluation, inspect the workflow available for the account type in the proposed release. Confirm what the connected source supplies and what remains an organisational record. Do not infer universal non-human identity discovery from the presence of an account list.

Test a change in the owning team. The technical service may continue even when a researcher or administrator departs. The correct action may be a responsibility change rather than immediate account removal. That decision belongs with someone who understands the dependency.

The orphaned-account and non-human identity page explains the scope to discuss. Credentials, privileged sessions and machine authentication may require other controls. Identity governance should connect ownership and review decisions to those controls without claiming to replace every part of the security architecture.

Make cost and operating responsibility visible

midPoint has no software licence fee. Some midPoint capabilities, such as simulations, high availability clustering or a database other than PostgreSQL, need an Evolveum subscription, which we arrange and include in your quote. easyIGA is a commercial product with a published annual subscription model per governed identity and deployment included in an agreed scope. Obtain the current terms for the populations and features the institution intends to use.

For higher education, define the identity count carefully. Student, staff and guest records can overlap. Ask how the proposed commercial model treats a person with multiple relationships and which service accounts are governed. The counting rule should be agreed rather than inferred from the number of records in one source system.

Include the actual implementation work. Source cleanup, role descriptions and application testing can affect the project even when a connector exists. A quote should identify the initial systems, migration responsibilities and acceptance criteria. It should also distinguish any later phases.

Self-hosting is the default deployment model. An operated EU-hosted option is available on request for organisations without suitable infrastructure. Compare the internal operating effort with the proposed service scope, including maintenance and recovery responsibilities. Location alone does not establish all the terms an institution needs for due diligence.

Use the pricing information and deployment page to prepare a scoped discussion. Do not borrow an academic discount or subscription arrangement from another supplier's midPoint offer and assume it applies to easyIGA. Commercial terms need their own confirmation.

Distinguish access rights from academic decisions

The identity process should implement the institution's authorised decisions without inventing academic status. Enrolment, employment and research participation each have an owner. The governance configuration needs a reliable representation of those decisions before it can map them to application access.

For example, a corrected study record may justify a change in a learning application's access. The identity team should know which source event is authoritative and how the correction is verified. It should not infer the student's academic position from the presence or absence of an application account.

Use this boundary when defining support procedures. A student reporting missing access may need an identity correction or an academic-administration decision. A clear handover helps the support team route the issue to the owner who can resolve it, while the recorded target outcome shows when the application change has actually completed.

Evaluate the workflow with the people who will use it

A campus pilot should involve someone who requests access, someone who approves it and a specialist who operates the integration. Each sees a different part of the process. Their combined observations are more useful than a demonstration limited to a technical administrator.

Select a small set of representative cases. An ordinary application request shows the basic experience. A person with overlapping affiliations tests the identity model. A visitor changing sponsor tests business responsibility. A target that cannot confirm an operation tests the exception path.

Use synthetic records at the start. State what a correct outcome looks like for each case before running it. Record the actual release, the configured scope and the evidence fields demonstrated. Keep planned functionality separate from the capabilities being accepted.

Evolveum's higher-education page provides sector context for the underlying platform. Our team's 14+ midPoint deployments are provider experience, not easyIGA university references. The product should be assessed through the current workflow and the evidence relevant to your institution.

Request a 30-minute walkthrough with our team. Bring an affiliation change or an access-review question that your institution finds difficult to explain today. That gives the discussion a concrete purpose and a clear basis for deciding whether a scoped easyIGA evaluation is worthwhile.