What midPoint customization involves
Customization changes how midPoint behaves for your organization without changing its core code. In practice that means adjusting configuration objects: object templates that set defaults and derive attributes when a user or role is created, schema extensions that add attributes your identity model needs, mappings and expressions that transform values between HR sources and target systems, archetypes that classify objects, and custom forms and dashboards for administrators and approvers. Typical triggers are a new HR attribute set, a new target system type, or a new business role concept that the current configuration cannot express cleanly.
Short answer on in-house versus partner: a team with Java and identity skills can carry out much of this configuration itself, since most changes live in XML or YAML objects and the midPoint documentation covers them. Outside help is most useful in three places: design decisions that are expensive to reverse, complex expressions that need careful testing, and keeping every change testable so that it survives the next midPoint upgrade. Ask any partner to show how they would test an expression and how they would re-verify it against a new release.
Customization is a separate piece of work from the initial implementation plan, which covers scope, HR integration, connectors and rollout, and from role model design, which decides what business and application roles exist and how assignments are approved. Those topics have their own pages. Keep them apart in planning: a customization request often reveals a gap in the role model, and that gap should be resolved in the role design before anyone writes a new mapping to work around it.
Before you commission or start customization, confirm three things in your own environment: which midPoint version you run and its support end date, which Java version your platform team can support for it, and where configuration is stored and reviewed before it reaches production. A quote should list each customization item, the environment it will be tested in, and the test evidence you will receive before go-live.
What the work includes
A fixed-scope midPoint customization engagement is agreed as work packages with written deliverables. The packages below show what is typically included, and the final scope confirms which ones apply to your environment.
Customization needs inventory
We catalog current and requested customizations: object templates, custom schema attributes, mappings, archetypes, forms and reports, with the target system and owner for each. The inventory shows which items are configuration, which need code, and which should be dropped before build starts. Ask for the inventory to be reviewed and signed off by your identity team before design begins.
Object templates and schema extensions
This package designs the object templates that set defaults and derive values for users, roles and organizations, and the schema extensions that hold attributes midPoint does not ship with. Decisions here affect every later mapping, so the design notes should record each extension, its data type and its source. Check how extensions will be carried through upgrades before approving the design.
Mappings and expressions with test cases
Mappings and expressions move values between HR sources, midPoint objects and target systems, including correlation and transformation logic. Each expression gets test cases that cover normal values, missing values and edge cases such as name changes or duplicate identifiers. Ask to see the test evidence for each mapping, not only a summary that they passed.
Archetype and form changes
Archetypes classify users, roles and resources so that forms, policies and reports apply to the right objects. This package adjusts archetype definitions and the custom forms in midPoint's user interface that administrators and help desk staff use. Confirm which forms are changed for administrators, which for end users, and who approves changes to each.
Dashboards and reports where in scope
Where dashboards or reports are part of the written scope, this package builds the views that show identity state, pending approvals or certification progress. Each view is tied to a named data source and a named audience. Confirm that any report that feeds an audit is reviewed by the people who rely on it, since report logic can be wrong even when the underlying data is correct.
Configuration management setup
This package exports midPoint objects as XML, places them in a version-controlled repository and defines how changes move from development to test to production. Environment promotion rules, review steps and a rollback method are documented as part of the setup. Ask how secrets are kept out of the repository and how environment-specific values are handled.
Handover to your internal team
The engagement ends with a handover covering the configuration repository, design notes, a change log, test evidence and the run procedures for promoting changes. Handover sessions are planned and recorded in the written scope, and your team should be named early so that they can take part in the build. Ask which people will own each area after handover.
What drives cost and duration
This table lists the main drivers of midPoint customization effort and duration, explains how each one changes the work, and shows how to keep it manageable.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Identity sources and attributes mapped | Each source and attribute adds correlation, mapping and test cases. | Confirm required attributes with data owners early and onboard sources in phases. |
| Mapping and expression complexity | Chained logic, lookups and scripts are harder to write, debug and review. | Prefer simple mappings, keep scripts small and document the purpose of each expression. |
| Archetypes and object types | Each archetype needs its own templates, assignment rules, policies and views. | Create archetypes only for real population differences and reuse templates where possible. |
| Custom GUI forms and dashboards | Each form and dashboard must be built, tested and maintained through upgrades. | Start with standard views and add custom forms only for needs users have confirmed. |
| Target systems needing custom handling | Non-standard connectors, scripts or schema extensions add build and support work. | Use supported connectors where they fit and name an owner for each custom handler. |
| Environments and promotion steps | Each environment and promotion step repeats deployment, data refresh and checks. | Keep configuration in version control and limit the number of promotion stages. |
| Testing and acceptance requirements | Formal test scripts, sign-off and audit evidence add effort to every change. | Agree acceptance criteria in writing and automate regression checks wherever feasible. |
| midPoint version and Java runtime | Versions 4.10 and older recommend Java 21, while 4.11 and later recommend Java 25. | Choose the target release and Java version before design, and check support end dates first. |
Project phases and outputs
The sequence moves a midPoint customization from an inventory of the current configuration to a documented, upgrade-ready configuration running in production.
Discover current configuration and requirements
We inventory the existing midPoint configuration, including object templates, schema extensions, mappings, archetypes, forms and dashboards, and interview the owners of HR sources, target systems and approval processes. The output is a written requirements list and a configuration inventory that the client signs off as the baseline for design.
Design the target model
We design the target configuration: which object templates, schema extensions, archetypes and mapping expressions are needed, and how each one maps to a requirement from discovery. The client receives a design document covering each change, its reason, and the parts that will be kept simple to ease future upgrades, and the design is accepted in writing before any build starts.
Build in a non-production environment
We implement the design in a non-production midPoint environment that matches the production version, Java runtime and repository database. Configuration is kept in version control so each change can be reviewed and reproduced. The step is complete when the build deploys cleanly from version control to a fresh environment and the client receives access to the non-production instance and its change history.
Test with representative data and recorded test cases
We run the build against representative data copies and execute recorded test cases covering each requirement, including edge cases for mappings, expressions and archetype behavior. Results are logged with the expected and actual outcome for every case. The client receives the test catalog, the results and a list of any open defects with agreed fixes or workarounds.
Accept and promote to production
The client reviews the test evidence and signs an acceptance record that names the tested version and configuration. We promote the tagged configuration to production using the same deployment steps used in non-production and verify the results with a smoke test. The output is the signed acceptance record and a production deployment log.
Hand over documentation and an upgrade checklist
We deliver the configuration documentation, an operations runbook, and an upgrade checklist that lists the custom objects to re-test, the expressions that depend on midPoint internals, and the test cases to rerun before each release change. The handover is complete when the client's team has walked through the runbook and the checklist with us and confirmed they can operate and test the configuration.
What to keep in-house and what to outsource
This table shows which midPoint customization activities an identity team should keep, which are usually shared with an implementation partner, and which skills each activity needs, so the split can be planned before a quote is requested.
| Activity | Usually in-house or outsourced | Skill required |
|---|---|---|
| Identity model decisions and attribute ownership | In-house. The identity team and HR data owners decide what each attribute means and which system is authoritative for it. | Identity domain knowledge, understanding of HR and directory data sources, and sign-off authority across business units |
| Schema and object template design | Often shared. A partner drafts extensions and templates, and the in-house team reviews them against the agreed identity model. | midPoint XML object model, schema extension design, and enough PostgreSQL knowledge to judge how new attributes will be stored and indexed |
| Groovy and expression development and testing | Often outsourced at first, then transferred. A specialist writes the initial mappings and scripts, and in-house engineers take over maintenance once they can read and test them. | Java and scripting, midPoint mapping and expression syntax, and disciplined unit and integration testing against sample data |
| GUI and dashboard customization | Shared. Simple forms and dashboards can be handled in-house, while changes that touch custom forms or archetypes usually go to the partner first. | midPoint XML object model, understanding of archetypes and GUI configuration, and familiarity with how the web interface reads object definitions |
| Configuration version control and release process | In-house ownership with partner support for the initial setup. The team must own the repository, review process and promotion path between environments. | Version control practice, configuration export and import discipline, and change management across development, test and production |
| Day-to-day administration after handover | In-house. Operators manage user and role requests, certification campaigns, connector status and task monitoring. | midPoint administration, PostgreSQL basics for checking repository health and backups, and incident handling for identity processes |
| Upgrade testing of custom configuration | Shared. The partner can run the first upgrade test, and the in-house team repeats the test before each later upgrade. | Testing discipline, release notes review, and knowledge of which custom mappings depend on changed midPoint behavior |
What usually goes wrong
Most midPoint customization problems appear months after go-live, when the people who built the configuration have moved on. The cards below name the failure patterns we see most often and the checks that prevent them.
Live edits without an exported copy
Object templates, mappings and archetypes changed directly in the running system leave no record of what changed or why. Keep every customization object in version control, export it after each change, and make the live system the only place changes are deployed from. Confirm that a restore from the exported files reproduces the running configuration.
Expressions that assume clean source data
Mappings that build account names, email addresses or org codes from HR fields fail or produce wrong values when the source leaves fields empty, changes formats or sends duplicates. Before go-live, test each expression against a sample of real source records, including leavers, rehires and contractors, and define what the expression returns when an input is missing.
Schema extensions without naming or ownership
Extension attributes added to users or roles with inconsistent names, types or no named owner become difficult to remove and easy to duplicate. Set a naming convention, record who approves each new attribute and what it is for, and check existing extensions before adding one, so the same data is not stored twice under different names.
No regression testing after a version change
Upgrading midPoint can change how mappings, expressions and connector behavior evaluate, and a configuration that worked on the previous release may silently change access. Keep a test suite of representative users and assignments, run it on a staging copy of the production repository, and review the differences before any production upgrade.
Scripts understood by one person
Groovy scripts and custom expressions written by a single engineer often have no comments, no owner and no test data, so nobody else can change them safely. Require a short description, input and output definition and an owner for each script, store them with the configuration, and have a second engineer review and run every change before it goes live.
Over-customization that blocks later releases
Replacing standard midPoint behavior with heavy custom logic makes each feature release costly to assess, because every new capability must be checked against local overrides. Prefer built-in configuration options where they exist, record each deviation from standard behavior with its reason, and review the list before adopting a new feature release.
What you need to provide
Customization work on midPoint moves quickly only when the client has settled a small set of inputs before the build starts. The most important is a named business owner who can decide identity questions, such as which HR attribute drives a mapping, which target system is authoritative for a value, and how a custom object template should behave when data is missing. Without that person, object templates and mappings tend to stall while engineers wait for answers that nobody is empowered to give.
Build work needs a non-production midPoint instance on the same version the client runs in production, so that expressions, custom forms and dashboards are tested against the behavior that will actually ship. Ask for an export of the current configuration objects (system configurations, resource definitions, object templates, archetypes and roles) and confirm which parts of that export contain secrets that must be removed or replaced before the export leaves the client's environment. Access to the instance and test accounts in target systems should be granted under the client's own change control, with logging and a named approver, and the client should confirm that test accounts are isolated from production users.
Mappings and schema extensions depend on an attribute list from the HR source and each target system, with data types, allowed values and sample records. Sample data must follow the client's data protection rules. Anonymize or pseudonymize names, identifiers and contact details where those rules require it, and keep the mapping between original and masked values under the client's control. Confirm early whether anonymized samples still preserve the value patterns, such as employee number formats and department codes, that the expressions depend on.
Two decisions are easy to defer and expensive to leave open. First, name who owns the configuration repository after handover, including who approves merges, who holds the deployment path to production and who maintains the custom code in expressions and forms. Second, name an internal engineer who will pair with the build team and be able to run the configuration after the project ends. The paired engineer should be present for design reviews and testing, not only at the end, so that the knowledge of why each object template and mapping exists stays inside the client's team.
Frequently asked questions
Can our own team customize midPoint without a partner?
Yes, if the team has the skills and time to own the work. midPoint is open source, so every customization is built, tested and documented inside your environment. Object templates, mappings and expressions, archetypes and custom forms require people who understand midPoint's data model and your identity processes. Some configuration changes need Java or XML work. Many teams start in-house and bring in outside help only for a bounded piece, such as a schema extension or a custom dashboard.
What drives the cost of midPoint customization work?
Cost follows how many customizations are in scope, how deeply each one touches your identity processes, and how many target systems they affect. Effort rises with new schema extensions, complex mappings, custom approval flows and connector changes. Testing, documentation and handover to your staff add further effort. Also check who is paid for what: a partner bills for the written scope, while your own staff time is an internal cost. Ask any quote to list each customization, its test plan, the environments involved and the support that follows handover.
How long does a midPoint customization project take?
Duration depends on the written scope and your environment, so no single timeline applies to every project. The main inputs are the number of customizations, the number of connected systems they affect, the state of your source data and access, and how many environments must be promoted through testing. Change windows and the availability of your staff often cause delays. Ask for a phased plan with milestones tied to specific deliverables so you can see what each phase includes.
How do we test a midPoint customization before production?
Test each customization in a non-production midPoint instance that matches production's version, configuration and connected systems as closely as possible. Start with focused checks on object templates, mappings and expressions using known test accounts. Then run end-to-end scenarios covering joiner, mover and leaver events, role assignment, approvals and provisioning to a test target. Keep test cases and expected results in version control so you can rerun them after every change or upgrade, and record the outcomes as evidence before promotion.
Do midPoint customizations survive upgrades to new releases?
They can, but survival depends on how each customization is built and tested. Keep configuration, schema extensions and any custom code in version control, document each customization's purpose and dependencies, and test the full set against the target release in staging before going live. Read the release notes for your target version on the midPoint releases page, because feature releases and long-term support releases differ in what they change and how long they receive support. Plan any Java runtime change in the same window.
Does midPoint have an enterprise edition with extra customization features?
No. Evolveum states that midPoint has no enterprise edition and that every line of midPoint code is published under open source licenses. Customization features are part of the open source code, and no paid tier gates them. Evolveum funds development through subscriptions, training and professional services. Product Support subscriptions cover resolving product bugs with an 8x5 next-business-day or 24x7 SLA, while Platform Subscriptions add feature development and roadmap influence. Outside customization help is usually contracted separately, so confirm in writing which work each one covers.
How DeployOpen delivers midPoint customization
DeployOpen plans and builds midPoint customization inside your own infrastructure, from object templates and schema extensions to mappings, archetypes and custom forms. Work starts from a written scope, and the configuration is kept reviewable so your team can maintain it after handover.
How we scope
- Inventory the object types, attributes and mappings that the customization must change, and record which are in and out of scope.
- Agree in writing which schema extensions, object templates, archetypes and custom forms are delivered, and which dashboards are excluded.
- Confirm the midPoint release line and Java runtime the configuration will target before any design work starts.
How we build
- Build object templates, mappings and expressions in a version-controlled configuration repository, with reviewed changes and clear naming.
- Test each mapping and expression against representative identity data in a non-production midPoint instance you operate.
- Keep customizations separate from core configuration so upgrades change fewer files and are easier to compare.
How we hand over
- Deliver the configuration repository, a deployment procedure and documentation of each extension, mapping and expression.
- Walk your administrators through the test cases, the upgrade checks and how to add a new attribute or archetype safely.
- Record open decisions and known limits in the handover document so your team can act on them after the engagement ends.
How we support
- Offer ongoing support, upgrade testing and configuration reviews as a retainer, agreed separately from the initial fixed scope.
- Re-run the customization test set before each midPoint upgrade to confirm mappings and forms still behave as documented.
- Confirm with your team which Evolveum support subscription level covers product bugs, since DeployOpen support does not replace it.
