Why midPoint simulations matter before you change identity configuration
midPoint simulations give identity teams a what-if analysis of configuration or policy changes before those changes are deployed. They can run against production or development configuration, so a new resource, a changed mapping or a tighter policy can be examined before it touches live accounts. Consider the position of an identity team about to make one of these changes in an identity governance platform. A single wrong rule can move or remove access for many users at once, and the people affected are the ones who discover the error, often after the change is already live.
Teams need simulations most when a change alters what midPoint decides for a large group of identities. The common cases are adding a connector to a new target system, introducing or editing attribute mappings, and changing role or policy definitions. Each of these can cascade through assignments in ways that are hard to predict by reading the configuration alone. A simulation lets the team ask what would happen to a defined set of identities before anything is written. The decision to make early is which changes must pass a simulation before a deployment window, and who reviews the results.
This page covers the mechanics of simulations, the options available to your team, how to set them up, the security considerations, and the limits you should confirm for your midPoint version and environment. The core mechanic is simple to state. In preview execution mode, midPoint computes the changes but writes them to a simulation result object instead of applying them. In full execution mode, midPoint applies the changes to the repository and resources and records them in the audit log. Keep that distinction in mind when you review any result, because only one of the two modes changes live data.
Set expectations early, because a simulation is only as useful as the data and configuration it runs against. Confirm which environment your simulation uses, whether a development copy reflects current production configuration and connector versions, and how representative the identity data is. Simulation results describe access in detail, so decide who can read them and how long they are kept. Build a review step where the team compares results with expected outcomes before production changes are made, and confirm the exact simulation behavior for your version in the official documentation.
Which simulation option fits each kind of configuration change
This table compares the four combinations of configuration source and execution mode a team can use to simulate a change. Read each row as a question: what the run shows, and whether it writes to production. The main takeaway is that a preview run against production configuration shows the effect without applying it, but only a check of your own environment confirms that development and production configuration are separate.
| Option | What it protects | What it does not prove | Fits when |
|---|---|---|---|
| Production configuration, preview mode | Live accounts and resources, because midPoint computes the changes and stores them in a simulation result object instead of applying them. | That target systems would accept the change, or how the change behaves once applied in full execution mode. | Reviewing a proposed resource, mapping or policy against the settings in use today, before approval to deploy. |
| Production configuration, full execution mode | Little before the change. The repository and resources are updated, and the audit log records what was applied. | That the change is safe, since the systems in use have already been changed. | Only as the deployment step after a preview has been reviewed and approved, never as the test itself. |
| Development configuration, preview mode | Production accounts and settings, provided development configuration is kept separate from production. | That development matches production, so differences in mappings or resource settings can hide problems. | Testing a new resource configuration before it is added to the production configuration. |
| Development configuration, full execution mode | Production systems, only if development resources point to separate targets and not to production targets. | That the change works on production targets, or with production data volumes and account counts. | Exercising connectors and resource behavior in a test environment that has development targets only. |
| Your environment's separation of configurations | Confirm which configuration each simulation reads, and where development resources and credentials point. | Naming alone does not prove separation, so check repositories, targets and credentials directly. | Any team where development and production share a repository, target systems or service accounts. |
Which configuration changes deserve a simulation first
Not every edit carries the same risk. The four kinds of change below share one trait: a single saved edit can alter many accounts or access rights at once. For each, the simulation result works as a review checklist before anything is written to production resources.
Adding a new resource configuration
A new resource configuration connects midPoint to a target system and can start linking, matching or creating accounts there. Run it in preview execution mode against production or development configuration so the planned changes are written to a simulation result instead of the target. Check which existing accounts would be correlated to identities, which accounts would be created, and whether the proposed attribute values match what the owning team expects. A preview matters here because a flaw in matching logic may only become visible after accounts are already linked, and a development copy of the configuration lets the team test that logic without touching regular operations.
Changing an attribute mapping
An attribute mapping decides which value flows into a target attribute, and one edited expression can change that value for every identity the resource manages. Review the simulation result for the attributes that would change, the direction of the mapping, and any cases where the new expression produces an empty or unexpected value. Pay particular attention to attributes that other resources read, because a change in one place can propagate to systems the editor never opened. The preview lets the team compare current and proposed values for a broad population before any target account is updated.
Changing a policy or rule that affects assignments
Policies and rules that drive assignments decide which roles, entitlements or resources an identity receives when its attributes meet a stated condition. Review which assignments would be added or removed, how many identities each change touches, and whether any identity would lose access it needs for current work. Confirm the conditions with sample identities that cover edge cases such as leavers, transfers and contractors. A preview matters because assignment changes can take effect in later processing runs, and the simulation shows the intended result before those runs begin.
Modifying settings shared across many users
Some settings apply to a whole population at once, such as object templates, default values, shared lifecycle conditions or global thresholds. Review the simulation result for the number of identities affected, the fields that would change, and whether the change reaches any identity outside the intended group. Ask the owner of each affected attribute to confirm the expected values before approving the change. The preview matters because a single shared setting can reach far more objects than the person editing it has in mind, and that difference is visible only when the affected population is counted and compared.
How to set up a simulation run for a midPoint change
This sequence moves a proposed midPoint change from a stated scope to a recorded review in preview mode, so that no production account or resource is touched before the affected system owners have examined the proposed effects. Each step ends with a check that someone outside the project can verify.
Confirm the midPoint version and environment
The platform engineer records the exact midPoint version in production and in the environment used for the simulation, and confirms that both match. Check the release on the Evolveum releases page, since support end dates differ between long-term and feature releases, and confirm that the Java runtime and PostgreSQL repository versions are supported for that release. The check is a short written note listing the version, support end date and runtime versions for each environment, signed off by the platform owner before any configuration is copied.
Prepare a development configuration that matches the change
The platform engineer copies the production objects the change touches into a development environment, including the resource, mappings and any policy objects the change depends on. Use the development configuration option described in the Evolveum simulations documentation so the change can be tested without affecting regular operations. Confirm the copy by comparing object identifiers and versions with production, and confirm that the test resource does not point at live target systems. The check is a comparison that shows only the intended change.
Define the scope of the change in writing
The change owner lists every resource, mapping, policy and role affected by the change, the identities expected to be in scope, and the change expected for each. The owner agrees which outcomes are acceptable and which would stop the rollout, and names the owner of each affected target system. The check is a one-page scope note that the platform team and the system owners both accept, so reviewers judge the simulation result against stated expectations.
Run the simulation in preview execution mode
The platform engineer starts the simulation with preview execution mode selected. midPoint computes the changes and writes them to a simulation result object without applying them to the repository or resources. Confirm the mode in the run settings before starting, and confirm the exact menu paths and object names in the Evolveum simulations documentation for your version. The check is that production accounts and resources show no changes from the run once it completes.
Review the simulation result with system owners
The platform engineer opens the simulation result object with the owners of the affected systems and walks through the proposed changes against the agreed scope. Each proposed account change, attribute value and assignment is checked, and anything outside expectations is flagged. Each system owner states whether the target system would accept the change. Confirm the object structure and labels in the simulations documentation for your version. The check is an itemized list of findings, each marked accepted, changed or blocked, with an owner's name beside it.
Record the review and its decisions
The change owner saves the review as a dated record linked to the simulation result object and the scope note. The record includes the midPoint version, the development configuration identifier, each finding, the decision on each finding and the names of the approvers. Where a finding requires a configuration change, the change is made in development and the simulation is run again. The check is that someone who was not in the meeting can see what was tested, what was decided and who decided it.
Plan full execution from the recorded review
Full execution is planned only when the recorded review has no open blocking findings. The plan names the production configuration version, the change window agreed with system owners, the rollback approach and the person who monitors the run. Full execution applies changes to the repository and resources and records them in the audit log, so the plan states how those entries will be reviewed afterwards. The check is an approved plan that cites the review record.
Security and operational controls for simulation data and development configuration
Simulations are only safe to use when the people who can start them, read their output and choose the configuration they run against are controlled deliberately. A simulation runs the same logic midPoint would use in production, so it exposes what a change would do to accounts and access. Before the first simulation is run, confirm which roles in your midPoint deployment are allowed to start preview runs, which can open simulation result objects, and who can change the configuration a simulation uses. Those permissions should be set by the same team that owns production identity changes, and they should be reviewed as part of your normal access review cycle rather than left at defaults.
Preview execution computes the changes midPoint would make and writes them to a simulation result object instead of applying them. Those objects can contain account and attribute values taken from target systems, so they need the same protection as production identity data. Classify them that way, apply the same encryption, backup and export rules, and restrict who can view them. Ask your team how long simulation result objects are kept, who can delete them, and whether deletion is part of your retention process. These are operational decisions to document before the first project uses simulations, not defaults to accept from the tool.
Simulations can run against production or development configuration, which lets teams test new resource configurations without affecting regular operations. That benefit depends on keeping the two configurations separate. Confirm which configuration each simulation uses and make sure development resource definitions do not point at production target systems that a later full execution could change. Store development and production configuration in separate, reviewed change paths, and decide who can promote a tested mapping or policy into production. Check that a configuration copied for testing cannot be applied to live resources by accident.
Full execution applies changes to the repository and resources and records them in the audit log, while preview runs write only to simulation result objects. The audit log is therefore the record of what actually changed, and simulation results are the record of what a change would have done. Before relying on this split in an audit, confirm how your audit log is retained and who reviews it, and decide how preview activity will be traced to the project and the approver who requested it. Teams should be able to show an auditor which change was previewed, which was executed and when each happened, without treating a simulation result as evidence that a change was applied.
Some midPoint setups run as a multi-node deployment behind a sticky HTTP load balancer, with a shared central database, cache invalidation between nodes and Quartz for distributed task scheduling. In that setup, confirm where simulation results are stored, which database holds them and whether every node can read them. Ask how they are backed up with the rest of the repository and how retention is enforced across nodes. Also confirm where node-level logs are written, because investigating a simulation or a disputed change may require logs from more than one node. Write these answers into your operating procedures before the first production simulation.
Limits of simulations and what to confirm in your environment
A simulation answers one narrow question: what midPoint would compute if the change ran now. The cards below cover what that answer does not establish, and what to confirm in your own environment before you rely on a preview.
A preview is not proof of downstream behavior
In preview execution mode, midPoint computes the changes and writes them to a simulation result object instead of applying them. That result shows what midPoint intended to do. It does not show how the target system will accept, reject or interpret the change, including validation rules, naming constraints or side effects that only the live system applies. Confirm which operations your midPoint version simulates, then test the affected provisioning flows against a non-production instance of each target system using your own test accounts.
Development may not match production
Simulations can run against production or development configuration, so a clean preview depends on which configuration it used. Development copies drift when resource definitions, mappings, roles or policies change in production and nobody carries the change back. Before you trust a result, compare the relevant configuration objects in both environments, record the midPoint version on each, and confirm that your change process promotes every configuration change through development first.
Connectors do not behave identically
The Evolveum connector documentation lists connectors with support statuses ranging from supported to community and experimental. Documented connectors include LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID through the Graph API, SCIM2 and SCIMv1. Treat each connector as its own case. Check its status in the catalog for your midPoint version, read the limits it documents, and confirm that every attribute you map is supported by both the connector and the target system configuration.
Test data limits what the preview shows
A simulation evaluates only the objects it is given. If sample identities lack the attributes, lifecycle states, memberships or edge cases that production contains, the preview can look clean for the wrong reasons. Build a test set from anonymized or synthetic accounts that cover joiners, movers, leavers, shared accounts and disabled identities, and write down which production patterns the set leaves out. Illustrative example: a mapping that works for employees may fail for contractors whose records have no department value.
Release-specific behavior and support windows
Simulation behavior is tied to the midPoint release you run, and support windows differ by release. According to the midPoint releases page, midPoint 4.8 is a long-term support release supported until 17 October 2028, midPoint 4.10 is a feature release supported until 26 November 2027, and midPoint 4.9 support ends on 18 October 2026. Check the release notes for your version before you rely on a simulation, and plan upgrades so the environment you test on is the environment you run in production.
Questions teams ask before running midPoint simulations
Can our own team run midPoint simulations without an outside partner?
Yes, in principle. Simulations are a feature of midPoint itself, and preview execution mode is available to any team that operates a midPoint deployment. What decides whether your team can do it alone is whether it has people who can read resource configurations, attribute mappings and policy rules, keep a development configuration aligned with production, and interpret simulation results against the target systems. Evolveum offers training and subscriptions that can build those skills. Confirm your team's readiness by reviewing one recent change end to end: could your staff predict what the simulation should show before they run it, and explain any difference afterward?
What makes setting up a development configuration and review process take longer?
The number and complexity of production configuration objects. Effort rises with the number of resources, mappings, correlation rules and policies that the development configuration must reflect, and with how far the test environment differs from production. Other drivers include whether test connectors can reach non-production copies of target systems, how much data must be copied and sanitized, how many approvers must sign off, and how simulation output is stored so reviewers can compare runs. Setup costs are one-time, such as building the environment, pipeline and review templates. Keeping the development configuration current and reviewing each change are recurring costs. In a quote, ask for each of these items to be listed separately.
What do identity, application and security owners need to contribute?
Decisions and access, not just approvals. Identity owners confirm the joiner, mover and leaver rules and what each role should grant. Application owners explain what each attribute means in their system, how accounts are created, disabled and deleted, and which test accounts can be used. Security owners set the review criteria, the approval thresholds for changes and who may view simulation results, since those results can contain personal data. Each group needs time at defined points: during scoping, during the first design review and at each change review. Ask for named owners and expected time commitments in the written scope before work starts, so delays do not come from unassigned decisions.
How long does simulation work take for a given number of changes?
This page gives no duration figure. Timelines depend on the change set, not just its count. Drivers include how many resources the changes touch, how complex their mappings and policies are, whether a change is a small update to an existing mapping or the onboarding of a new resource, how closely the development environment matches production, and how many review rounds the approvers need. Access to target system owners and test accounts often sets the pace more than midPoint work does. A fixed-scope engagement should tie the timeline to a listed set of changes and to milestones that the client can check. Ask for the duration to be stated per milestone with the assumptions behind it.
Do midPoint simulations replace testing in target systems?
No. Simulations do not replace testing in target systems. A simulation shows what midPoint would compute and write, based on its own view of the configuration and the data it has read. It does not prove that the target system accepts the change, applies it as expected, or handles edge cases such as locked accounts, naming conflicts or unusual account states. Keep test accounts and test cycles in each target system, and plan them as a separate step after the simulation review. A good scope states which target system tests the client runs, which ones the partner supports, and who signs off on the results.
What should a fixed-scope quote for simulation work include?
Written scope that names the boundaries. Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A useful quote lists the resources and change set in scope, the development configuration to be built, the review process and its approvers, and the number of review cycles included. It should also state what your team provides, such as access, owners, test accounts and environments, and what is excluded, such as target system testing or production changes. Ask for acceptance criteria, handover documentation and any recurring support as a separate line. DeployOpen does not publish a price list, so the quote follows from the written scope.
Does midPoint itself carry license costs for simulation work?
midPoint has no license fee for its code. Evolveum states that midPoint has no enterprise edition and that every line of its code is published under open source licenses. The repository is licensed under the European Union Public License (EUPL-1.2), with Apache 2.0 as a secondary license. Costs come from the infrastructure you run, the people who operate it and any services you buy. Evolveum sells Product Support subscriptions, which resolve product bugs with an 8x5 next-business-day or 24x7 SLA, and Platform Subscriptions, which add feature development and roadmap influence. Its support page lists no prices, so request current pricing from Evolveum and compare it with the scope of your own support needs.
How DeployOpen scopes and delivers midPoint simulation work
DeployOpen treats a midPoint simulation as a planned review step before production changes. We scope which resources, mappings and policies need previewing, set up development and production-configuration runs in infrastructure you control, and document how your team repeats the check for each future change.
How we scope
- Written scope lists which new resources, mappings and policies will be previewed in simulation before production.
- Scope states which configuration the simulations run against, production or development, and who may start them.
- Scope names the accounts, sample data and expected outcomes the reviewers will compare results against.
- Engagements are fixed-scope, so the agreed simulation deliverables and timeline are fixed in writing before work starts.
How we build
- We set up simulation runs in preview execution mode so computed changes land in simulation result objects, not in target systems.
- We build test resources against development configuration so new connector settings are exercised without affecting regular operations.
- We review each simulation result with your identity team, comparing proposed account changes against the intended mapping behavior.
- We record each simulation run and its outcome so changes can be traced back to the review that approved them.
How we hand over
- You receive documented simulation procedures covering how to start, read and archive preview results in your environment.
- Handover includes a checklist that defines which changes must pass simulation before full execution mode is used.
- Your team gets a walkthrough of the simulation results, including what each result object shows and what it does not.
- Documentation records the midPoint version, connector versions and configuration used, so reviews can be repeated after upgrades.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover, scoped in writing.
- Support can cover re-running simulations when midPoint upgrades change mapping or connector behavior.
- Evolveum offers its own Product Support and Platform subscriptions, which you should compare with any retainer before choosing.
- Confirm with Evolveum which subscription level and support window fit your simulation workflow before the project starts.
