midPoint HR system integration: how joiners, movers and leavers reach midPoint
HR is the authoritative source for employment events, so midPoint has to act on joiners, movers and leavers from the HR system's own records. The Evolveum catalog lists the CSV and DatabaseTable connectors as supported, the ScriptedSQL connector as supportable for custom SQL work, and the PeopleSoft HCM and SmartRecruiters connectors as supportable connectors maintained by Evolveum. The connector you choose sets how the feed arrives, who can help when it breaks, and how much custom code your team will own.
midPoint uses the ConnId connector framework to read HR data. The connector fetches employee records from the source, and midPoint's lifecycle logic decides what each change means. A new record may start a joiner process, a changed department may start a mover process, and a record that disappears or is marked terminated may start a leaver process, depending on how the resource is configured. The connector does not make those decisions, so the lifecycle rules, the unique identifier and the attribute mapping must be designed and tested together. Ask your HR team which attribute is the stable identifier, because a personnel number that changes on rehire can create a second identity unless the design accounts for it.
The CSV connector suits HR exports delivered as files on a schedule. Your team owns the export job, so the checks that matter are whether each file is complete, whether its header matches the mapping, and what happens when a file is late or empty. An empty file read as the full population could look like a mass of leavers, so plan a guard before the first production run. The DatabaseTable connector reads through JDBC from a table or view the HR team exposes. Use a read-only service account, a view that hides fields midPoint does not need, and a change indicator such as a last-modified timestamp that the connector can filter on. Where the HR schema needs joins or transformations, ScriptedSQL provides custom SQL, and the code and its testing become your responsibility.
The PeopleSoft HCM connector and the SmartRecruiters connector are supportable connectors maintained by Evolveum, so they suit organizations that want vendor-specific integration without writing it themselves. Each depends on the source product's version and API. Confirm with Evolveum which PeopleSoft release and which SmartRecruiters API the connector covers before design starts, and confirm how your subscription treats each one. SmartRecruiters holds recruiting data. Candidate-stage events describe applicants who may never join, so decide early which hiring stage should trigger account creation, and make sure a candidate record cannot create an identity on its own. Request the connector's documentation of supported objects and fields before you commit to the attribute mapping.
A community connector also exists: the Convenia HR connector is maintained by Atricore and listed as community in the Evolveum catalog. Community status means support expectations differ from those for the supported and supportable connectors above. Confirm with Atricore and Evolveum what testing has been done, who fixes defects, and whether a Product Support subscription covers it. If you choose it, plan for your own regression tests, a version check at every midPoint upgrade, and a named owner for the connector. Treat the connector as part of your change scope, so it is tested again before each midPoint upgrade.
What a midPoint HR system integration needs before the build starts
These six checks decide whether the HR feed can be built and supported. The runtime, database, release and connector choices set the platform baseline, while the account, network and source details define how joiner, mover and leaver data reaches midPoint. Settle them in the written scope before the build starts.
Java runtime and midPoint version
Your midPoint version sets the Java runtime. Evolveum recommends Java 25 for midPoint 4.11 and later, and Java 21 for 4.10 and older. Confirm which JDK build your platform team can patch and monitor in production, and check that it matches the midPoint version you plan to run. Settle this before the build, because changing the runtime later adds testing work across the whole deployment.
PostgreSQL as the repository
midPoint uses PostgreSQL as its native repository database, and Evolveum recommends running it on a separate database server from the midPoint host. Confirm the PostgreSQL version your database team supports, where backups run, and who owns the account midPoint uses. The HR data usually sits in a different database, so keep the midPoint repository and the HR source as separate schemas with separate credentials.
Release support windows
Choose the midPoint release against its support window before you plan the build. Release 4.8 is a long-term support release supported until 17 October 2028. Release 4.10 is a feature release supported until 26 November 2027, and 4.9 support ends on 18 October 2026. Release 4.11 is planned for 21 October 2026, so confirm its support end date on the releases page before you commit to it.
HR export or database account
Request a dedicated account for the HR source, or a scheduled export, before the build starts. For a database table, agree on the table or view, the columns midPoint will read, and the field used to match each person. For a CSV feed, agree on the file location, delimiter, encoding and delivery schedule. Ask HR who approves the account and how its credentials are rotated.
Network paths to the HR source
Map every network path between midPoint and the HR source before any connector configuration starts. For a database connector, confirm the listener port, the TLS settings and the firewall rules that allow midPoint to connect. For a CSV feed on a file share or transfer location, confirm the route and the access method. In multi-node deployments, confirm that every node can reach the source, and ask your network team to record the routes in writing.
Connector and support status
Confirm which connector and support status applies to your HR product. The Evolveum catalog lists the CSV and DatabaseTable (JDBC) connectors as supported, and ScriptedSQL for generic SQL databases with custom scripts as supportable. It lists the PeopleSoft HCM and SmartRecruiters connectors as supportable and maintained by Evolveum, and the Convenia connector as community, maintained by Atricore. Ask Evolveum what supportable status covers before you scope a subscription.
Choosing between CSV, DatabaseTable, ScriptedSQL and HR-specific connectors
The first decision in an midPoint HR integration is which connector reads your HR data. The options are a scheduled CSV export read by the CSV connector, a direct read from an HR database table through the DatabaseTable (JDBC) connector, a ScriptedSQL setup for a generic SQL source that needs custom scripts, or a vendor-specific connector such as the PeopleSoft HCM or SmartRecruiters connector. Each option moves the same joiner, mover and leaver events into midPoint, but they differ in how much of the mapping is configuration and how much is code your team must own.
Evolveum's connector catalog classifies these options by support status, and that status determines what your subscription covers. The CSV connector and the DatabaseTable (JDBC) connector are listed as supported. The ScriptedSQL connector for generic SQL databases with custom scripts is listed as supportable. The PeopleSoft HCM and SmartRecruiters connectors are maintained by Evolveum and listed as supportable, and the Convenia HR connector is maintained by Atricore and listed as community. Read the status as a statement about who stands behind the connector code and what Product Support can be asked to resolve, not as a measure of how well the connector works.
In practice, a supported connector with a stable export is usually the lowest-risk path when your HR product can produce a clean file or a readable table view. The CSV route puts the export job and file delivery on your side, so you must decide who produces the file, where it lands, and how a failed or partial export is detected before midPoint processes it. The DatabaseTable route needs a read-only database account, a view that exposes only the attributes you intend to govern, and an agreed approach to deleted or rehired employees. ScriptedSQL gives the most flexibility for an unusual schema, but the custom scripts become code your team or a partner must test, version and maintain after each midPoint upgrade.
Before choosing, ask Evolveum to confirm the current support status of the connector for your specific HR product, the midPoint version it was tested against, and whether that connector supports the version you plan to run. Ask in writing and keep the answer with the design record. Ask also which Java and PostgreSQL versions the connector requires, since midPoint 4.10 and older and 4.11 and later have different Java recommendations. If your HR product is not named in the catalog, treat it as a ScriptedSQL or CSV design and plan the testing that comes with it.
Decision check: write down the HR product name, version and the feed type it can produce, then match it to a catalog status and a confirmed midPoint version. If the only connector for your product is community or the status is unclear, plan for your own testing, ownership of the connector code, and a clear answer on what Evolveum subscription support will and will not cover for that feed.
How to configure the midPoint HR system integration step by step
This sequence takes an HR source from catalog review to scheduled synchronization in midPoint, with a check at each stage. Each check confirms that the data arriving in midPoint matches what HR owns before the next stage builds on it.
Confirm connector and support status
Open the Evolveum identity connectors catalog and find the connector that matches your HR source. The CSV connector and the DatabaseTable (JDBC) connector are listed as supported, ScriptedSQL for generic SQL databases with custom scripts is listed as supportable, and the PeopleSoft HCM and SmartRecruiters connectors are listed as supportable and maintained by Evolveum. A community connector, such as Convenia maintained by Atricore, carries community status, so plan your own support for it. Record the connector, its status and the midPoint release you will run, then confirm with your subscription provider what support covers. This step closes when the project owner approves that record.
Prepare a read-only HR source
Ask the HR system owner for either a scheduled extract or a database account limited to read access on the fields your identity model needs, such as employee identifier, names, organization unit, manager, job position, employment status and dates. For a CSV feed, agree on the file location, delimiter, encoding, naming pattern and delivery schedule. For a database, create a dedicated account with select rights on one agreed view only, with no write or schema privileges. This step closes when the HR owner confirms the file or account in writing and a sample extract, opened outside midPoint, shows the expected columns and record count.
Create the resource with connector configuration
In the midPoint administration interface, create a resource for the HR source and select the connector confirmed in the first step. Enter the connection settings, such as the file path or JDBC URL, and reference the credentials from your secret store so they are never stored in the resource in plain text. Define the object class and map each source column to a connector attribute, using the field list agreed with HR. This step closes when the resource saves without configuration errors and midPoint reads the credentials at runtime.
Test connection and discover schema
Run the connection test on the new resource, then run schema discovery to list the attributes midPoint can see in the source. Compare the discovered attributes with the column list or view definition from the previous step, and confirm that the employee identifier is unique across records. If a field the identity model needs is missing, raise a change request with the HR owner before continuing. This step closes when the connection test succeeds, the discovered schema contains every agreed field, and the test result is saved in the project record.
Define HR-to-user mapping and lifecycle rules
Build the inbound mapping from HR attributes to midPoint user properties, and set the correlation rule that matches HR records to existing users, typically on the employee identifier. Translate each employment status value into a lifecycle state, and define how effective dates drive joiner, mover, leaver and rehire events. Write a case table that lists each scenario, including duplicates and organization changes, with its expected outcome. This step closes when the identity and HR owners sign off the table and a preview or simulation on sample records produces the outcome the table describes.
Run a limited import with a small set of records
Select a small test population, for example a single department or a list of agreed employee identifiers, and run an import task limited to those records. Review the resulting user objects for attribute values, lifecycle states and account links, and check the task log for errors. Confirm that no provisioning reaches target systems during this test unless that is an agreed part of the test. This step closes when the reviewed sample matches the source for each case in the table, the error log is empty or each error is explained, and the reconciliation report agrees with the source count for the selected population.
Enable scheduled synchronization
Widen the population to the full HR extract, then create a schedule for the import and reconciliation tasks at an interval the HR owner and operations team agree on. In a multi-node deployment, confirm how distributed task scheduling runs the tasks so that each one executes once. Before enabling leaver processing against live accounts, review the leaver outcomes with the approvers and document a rollback procedure. Name an owner for failed runs in the operations runbook. This step closes when the first scheduled runs complete and the reconciliation report matches the source counts.
Mapping HR fields to midPoint users, organizations and roles
This table lists the HR attributes most integrations carry into midPoint, the midPoint object or property each one populates, and which fields drive lifecycle changes or need agreement with HR. Use it as a starting draft: replace the generic HR field names with the exact columns from your own export or schema, and confirm the attribute support of your chosen connector before you finalize it.
| HR attribute | Populates in midPoint | Lifecycle role | Agree with HR |
|---|---|---|---|
| Employee identifier | User object: stable personal number, used as the key that links the HR record to the midPoint user | Matches the record on every run; a changed identifier looks like a new joiner and an orphaned old account | Confirm the identifier never changes on rehire or contract conversion, and who issues it |
| Legal name (given and family) | User properties for given name and family name, which feed target system account attributes through mappings | None directly; a change may trigger attribute sync only | Agree which name is legal and which preferred name, if any, is used in directories |
| Email address | User email property, often the source for target mail and directory accounts | Changes may trigger account updates; keep it out of the join key unless it is guaranteed unique | Confirm who owns the corporate address format and how aliases are handled |
| Employment status | User activation and lifecycle state, mapped through an inbound mapping with explicit values | Primary driver of joiner, mover and leaver transitions: active, leave, terminated and similar values | Agree the full list of status codes and what each one means for access |
| Manager | Reference from the user to a manager user, used for approvals and organizational assignments | Changes can trigger mover logic and recalculated approver paths | Confirm whether HR supplies the manager identifier or only a name, and how vacancies are represented |
| Department or org unit | Organization object assignment and org membership of the user | Mover driver: a change can add or remove org-based roles | Agree the org code scheme and who owns the hierarchy in HR |
| Job code or position | Role assignment rules, often through an inbound mapping to a role or a job-based policy | Mover driver when job codes map to birthright roles | Agree the job catalog, its update frequency, and the owner of each job-to-role decision |
| Start date | User validity or activation timestamp, used to schedule future-dated access | Drives joiner timing; access should not start before the agreed date | Confirm the date is the effective start, not the hire or offer date |
| End date | User validity end timestamp, used to schedule disablement and removal | Drives leaver timing and the delayed deprovisioning window | Agree whether HR end dates are final, how late corrections are handled, and the retention rule for leavers |
How joiner, mover and leaver events change accounts and roles
The HR feed does not trigger midPoint directly. Each synchronization run reads the source (a CSV file, a database table or, where you use it, a PeopleSoft HCM or SmartRecruiters connector) and compares what it finds with the state midPoint already holds for each person. A joiner, mover or leaver is therefore not an event that arrives on its own. It is a difference the reconciliation detects between the last run and this one. Before you build anything, decide what counts as a change. Choose the attributes that matter for lifecycle, such as employment status, effective dates, department, manager and job code, and decide whether a change in a cosmetic field such as a phone number should trigger any action at all. Each of those choices determines how much work every run performs and how often accounts are touched. Once a change is detected, midPoint maps the source record to the user object and applies lifecycle logic. A new hire typically creates the identity and requests its initial accounts and roles through the assignment and role model. A transfer changes organizational attributes, which can add or remove roles that are driven by those attributes. A termination does not normally delete anything at once. Many organizations move the user into a disabled or leaver lifecycle state, remove high-risk access immediately and schedule final deprovisioning after a retention window agreed with HR, legal and the business owners. Confirm with your own policy owners which states, windows and exceptions apply, because midPoint can model these steps but the business must decide them. The change then reaches each target system through that system's own connector. The HR source does not write into Active Directory, a database or an application directly. Each resource has its own connector, schema mapping and provisioning rules, so a single mover can produce different outcomes in different systems. Check that every target you plan to drive from HR has a connector with the support status you need, and test how it handles a disable, a re-enable and a delete. Some resources will need manual cases or tickets instead, which changes how fast access is removed and who is responsible for confirming it. HR records are often corrected after the fact. A leaver may be entered with the wrong end date, a transfer may be backdated, or a new hire record may arrive late with a start date in the past. midPoint reconciles against the current source state, so a corrected record can reverse earlier actions, but only if your mappings and lifecycle rules were designed to run in both directions. Plan explicit test cases for reversal: a termination withdrawn before the retention window ends, a transfer entered with the wrong department, and a late joiner whose accounts were created on the wrong date. Agree with HR how corrections are entered, and record in your runbook which reversals are automatic and which need an operator to approve. Finally, verify the behavior before go-live with a controlled set of test records that cover joiners, movers, leavers and corrections. Confirm the exact outcome in each target system, not only the midPoint task result. Document the resulting state for each case and keep those results as evidence for access reviews. Timing depends on your synchronization schedule, the size of the feed and the number of target systems, so measure it in your own environment rather than assuming a figure.
Securing the HR feed, service account and midPoint data
An HR-driven midPoint deployment moves employee records, personal data and privileged connector credentials across several systems. The controls below cover who can read the source data, how the feed travels and where secrets live, along with how runs are logged and who may change mappings.
Read-only service account for the source
Create a dedicated account in the HR database or export location that can read only the tables, views or files the feed needs. Confirm that it cannot write, cannot read unrelated employee fields such as payroll or health data, and is excluded from interactive logins. Review its grants whenever the HR schema changes, since new columns can silently expand what the feed exposes.
Encrypted transport for the feed
Protect every hop that carries HR records, including the JDBC connection from midPoint to the database and any file transfer used for CSV handoff. Require TLS with certificate validation on the database connection rather than trusting the network path. Confirm which HR system endpoints support encrypted connections in your environment and document the ones that do not.
Connector credentials in a secrets store
Keep database passwords, API tokens and certificate passphrases out of connector configuration files and version control. Store them in a secrets manager you operate, grant midPoint's runtime access to only the secrets it needs, and plan rotation with a tested procedure. Ask the Evolveum connector documentation for the supported way to reference externally held values for your chosen connector version.
Restricted paths for CSV handoff
When HR exports a CSV file for the CSV connector, define one drop directory with write access for the HR export job and read access for the midPoint service user only. Check ownership, permissions and the process that moves files in and out of that directory. Decide what happens to processed and rejected files, and how long they remain on disk before they are removed.
Synchronization logs without personal data
Record the outcome of each synchronization run, including counts of created, changed and failed accounts, the task identifier and timestamps. Keep employee names, national identifiers and salary-related fields out of log messages and error text, and confirm this with a test run on sample data. Set retention periods for logs in line with your data protection policy and restrict who can read them.
Separation of mapping changes and HR data ownership
Assign midPoint administrators who edit mappings and resources to a different group from the team that owns the HR source data and approves changes to its schema. Use midPoint's own role and authorization model to limit who can alter inbound mappings, and require review before a mapping change reaches production. Record which administrator changed which mapping and when.
How to test joiner, mover and leaver handling before go-live
Test joiner, mover and leaver handling against a non-production copy of the HR feed before any production run touches a real account. The test plan should cover five synthetic or anonymized employees: a new hire, a department transfer, a manager change, a leave of absence and a termination. Each case needs a written expected outcome in midPoint and in every target system, agreed before the first run, so that a pass means something to the people who sign off on go-live.
For each case, check the midPoint objects first. Confirm that the user object reflects the HR attributes that were mapped, that the organizational unit and manager references moved correctly on a transfer or manager change, and that the assignments, roles and any approval or policy outcomes match the expected result. For a leave of absence, confirm which lifecycle state midPoint sets and whether access is suspended rather than removed, as your HR and security owners have defined it. Review the task and audit records as well, because they show what midPoint decided and why, which is the evidence an auditor will ask for later.
Then check the effects in each target system the connector writes to, such as directory accounts, group memberships or database rows. A CSV or DatabaseTable connector writes to a file or table, so verify the row or file content and the account state on the target side, not only the midPoint view. Run the same cases twice to confirm that repeated runs are idempotent and do not create duplicate accounts or stray group memberships. Record any difference between the midPoint view and the target state as a defect, not as an acceptable variance.
Reconcile the results against the HR source. Export the population from the HR test copy and compare it with the midPoint user set and the target system accounts, looking for orphaned accounts, users present in HR but missing in midPoint, and attributes that drifted. Reconciliation should be scheduled as it will run in production, so you also test the reconciliation job itself. Keep the reconciliation output with the test evidence.
Plan rollback before the first test run. Define how to restore the midPoint repository and the connected target systems to a known state, who authorizes the restore, and how the test copy of the HR feed is refreshed between runs. Confirm the backup and restore procedure on your own database and infrastructure, and agree in writing with the client's HR and security owners which cases, systems and sign-off criteria form the required test coverage.
Common failures in midPoint HR feeds and how to fix them
This table lists the failures most often seen when midPoint reads HR data from a CSV file or database table, with the likely cause, a diagnostic check and a fix for each. Work through the rows in order when a feed stops or produces unexpected results. Connector behavior varies by version and configuration, so confirm each fix against the Evolveum connector documentation before changing production.
| Failure | Likely cause | Diagnostic check | Fix |
|---|---|---|---|
| Connection refused or timeout to the HR database | Network path, firewall rule, DNS name or JDBC URL points to the wrong host or port, or the database service is down or overloaded | Test the JDBC host and port from the midPoint node, review the midPoint task error for the connection exception, and check database server logs | Correct the connection URL and firewall rules, confirm the database account can log in from the midPoint network segment, and set reasonable connection and read timeouts |
| Attribute mapping breaks after an HR export schema change | HR added, renamed, retyped or removed a column or CSV header, so the midPoint attribute mapping no longer matches the source | Compare the current export header or table definition with the attribute names in the resource schema and mappings, then run a test fetch of a few records | Update the resource schema and mappings in a non-production copy first, agree change notice with the HR team, and add a check that fails the feed when expected columns are missing |
| Duplicate identities from a non-unique identifier | The identifier used to correlate HR records to midPoint users (for example an employee number reused, blank or shared across contract types) is not unique | Query the source for duplicate values of the chosen identifier and count records per value before the first load | Choose an identifier that the HR system guarantees is unique and stable, filter or reject incomplete records, and resolve duplicates in HR before enabling synchronization |
| Leavers not deprovisioned because the end date is missing | The termination or end date is empty, in a different format, or never populated for contractors, so the lifecycle logic does not see a leaver | Count active accounts whose source record has no end date or an unparsed date, and review the date format in the export | Standardize the date format and population rules with HR, add a reconciliation report of accounts without a valid status, and confirm the lifecycle mapping treats the chosen field as the leaver trigger |
| Unexpected mass changes after a bad feed | A partial, empty or truncated export is read as the full population, so records appear removed or changed when the source is incomplete | Compare the record count and file timestamp with the previous successful run, and review the projected changes before the feed applies them | Add a minimum record count or change-threshold check that stops the run, keep the previous export, and recover by correcting the source and re-running the feed rather than forcing changes through |
| Connector status mismatch with subscription scope | The HR connector in use is supportable or community rather than supported, so it may fall outside the subscription support scope | Check the connector status in the Evolveum catalog and compare it with the terms of your support subscription | Confirm which connectors your subscription covers in writing before go-live, and plan for self-maintenance or a community connector review where support does not apply |
What does a midPoint HR system integration cost and require?
What drives the cost of a midPoint HR integration?
The cost follows from the written scope, and the main drivers are the number of HR sources, the connector status of each source, mapping complexity, approval rules and the number of target systems. Who is paid for what: a partner is paid for planning, building, testing and cutover, while your organization pays for internal time from the HR owner, the data owner and the people who approve access rules. One-time work includes design, build, testing and cutover. Recurring costs include platform support, upgrades and any subscription you choose. Ask for a quote that lists each HR source, each target system, each mapping, each approval path and the items that are excluded. Effort is quoted from a written scope, so ask for the assumptions behind each estimate.
Does a supportable or community HR connector change the work?
Yes, connector status changes who maintains the code, how much custom work is needed and what vendor support covers. In Evolveum's connector catalog, the CSV and DatabaseTable (JDBC) connectors are listed as supported. The ScriptedSQL connector is listed as supportable for generic SQL databases that use custom scripts, so script ownership moves to your team or partner. The PeopleSoft HCM and SmartRecruiters connectors are maintained by Evolveum and listed as supportable. The Convenia HR connector is maintained by Atricore and listed as community, which means more testing and long-term ownership must be planned. Confirm the status for your midPoint version and ask Evolveum whether your subscription covers it.
How long does a midPoint HR integration build take?
Duration depends on scope, and the timeline is set in the written scope rather than from a fixed figure. The main drivers are the number of HR sources, data quality in the source feed, the complexity of attribute mapping, the number of approval rules and how many target systems receive joiner, mover and leaver events. The schedule also depends on how quickly the HR owner can make decisions about edge cases. Work usually moves through discovery, build, testing and cutover, and each phase should have agreed exit criteria. Ask for a timeline that shows which tasks depend on client input and which depend on the build team, so delays can be traced to their source.
What must our team provide before an HR integration starts?
Three inputs decide whether the build can move forward: an HR owner, sample data and a test environment. The HR owner must have authority to define how employment status, job changes and departures are interpreted, and must be available for decisions during testing. Sample data should include representative joiner, mover and leaver cases, including rehires, contractors, manager changes and records with missing fields, with personal data handled under your own policies. The test environment needs a non-production HR feed or extract, non-production target systems and service accounts with the permissions the connectors require. Confirm each item in writing during scoping, because late delivery of any input is a common cause of schedule slippage.
Can our own team build a midPoint HR integration without a partner?
Yes, an internal team can build the integration if it has midPoint configuration skills, experience operating Java applications and PostgreSQL, and detailed knowledge of your HR data and target systems. Evolveum offers subscriptions, training and professional services, which can support an internal team. The trade-off is between time, skills and risk: an internal team keeps the knowledge in-house, while a partner works to a fixed written scope with defined deliverables. Many organizations start with one HR source and one target system as a pilot, then decide on the remaining scope. Assess your team's skills against the connector status, mapping complexity and approval rules in your scope before deciding.
What does an Evolveum support subscription cover for HR connectors?
Evolveum's Product Support subscriptions cover resolving product bugs, offered with an 8x5 next-business-day SLA or a 24x7 SLA. Platform Subscriptions add feature development and roadmap influence on top of product support. The support subscriptions page does not list prices, so ask Evolveum for current pricing and terms. Support coverage for a connector depends on its catalog status, so a supportable connector and a community connector may be treated differently. Subscriptions are recurring costs, and they should be compared with the internal effort needed to maintain connectors and fix issues yourself. Ask Evolveum to confirm in writing which connectors and versions your subscription covers.
Which midPoint release should a new HR integration target?
Target a release that is inside its support window for the full planned life of the integration. According to the midPoint releases page, 4.8 (Curie) is a long-term support release supported until 17 October 2028, 4.10 (Braille) is a feature release supported until 26 November 2027, and 4.9 support ends on 18 October 2026. Version 4.11 (Čapek) is planned as a feature release for 21 October 2026. midPoint recommends Java 25 for version 4.11 and later, with Java 21 supported, and Java 21 for 4.10 and older, with Java 17 supported. Confirm the release plan and Java requirements against your own platform standards before you commit to a version.
What breaks most often in HR-driven joiner, mover and leaver flows?
The most common failures come from data that does not match the assumptions in the mapping. Typical problems include duplicate or changed employee identifiers, late or missing leaver events, changed attribute formats, manager relationship changes, rehires and people who hold more than one employment record. Each of these can create accounts that are never disabled or access that is never removed. Build test cases for each pattern using sample data before cutover, and record the expected result for every case. Check how the feed behaves when a file is empty, partially delivered or delivered twice, because those cases are easy to miss in a normal test run.
How DeployOpen scopes and supports the midPoint HR feed
DeployOpen plans, implements, integrates, documents and supports midPoint in your own infrastructure, including the HR feed that drives joiner, mover and leaver events. Engagements start from a written scope that names the HR source, the connector type and the target systems before any build begins. Ongoing support is available as a retainer.
How we scope
- Identify the HR source system and the export method, such as CSV files or a database table view.
- Check each connector's catalog status, because CSV and DatabaseTable are supported while PeopleSoft HCM and SmartRecruiters are supportable.
- Record the joiner, mover and leaver rules, identity attributes and target systems in the written scope.
How we build
- Map HR fields to midPoint user attributes, with lifecycle states that drive provisioning and deprovisioning.
- Configure the CSV or DatabaseTable connector and test reads against a copy of the HR extract.
- Where a custom query is needed, build it on the ScriptedSQL connector and review it as code.
How we hand over
- Deliver the connector configuration, mapping rules and deployment notes as version-controlled documentation.
- Run a documented reconciliation check that compares HR records with midPoint accounts before cutover.
- Walk your operations team through the feed schedule, error handling and the runbook for failed extracts.
How we support
- Watch the feed for failed extracts, rejected records and task errors, with the response agreed in the scope.
- Plan midPoint upgrades on the release calendar, because 4.9 support ends on 18 October 2026.
- Confirm with Evolveum which subscription covers the connector you use and what response times it includes.
