How midPoint and Microsoft Entra ID provisioning works
The supported method for managing Microsoft Entra ID and Office 365 accounts from midPoint is the Evolveum Microsoft Entra connector, which uses the Microsoft Graph API. Evolveum maintains this connector, and the Evolveum connector catalog lists it as supportable, covering both Office365 and Entra ID. An identity team that needs cloud accounts and groups in Microsoft 365 driven from midPoint should start from this connector rather than from a legacy option.
Through the connector, midPoint manages two kinds of objects in the Microsoft tenant: user accounts and groups, including the membership of those groups. When a midPoint role or assignment changes, midPoint computes the resulting accounts and memberships and pushes the difference to Entra ID. The same logic also works in reverse for reconciliation: midPoint compares what it expects with what the tenant holds and reports or corrects drift, depending on how the resource is configured. Which attributes, group types and object scopes are in play is a design decision that belongs in the scope document, not something to discover during testing.
The connector runs inside the client's own infrastructure. midPoint itself is deployed in the client's environment, and the connector authenticates to the Microsoft tenant from there, so the team controls where the service runs, how its credentials are stored and which network paths are opened. DeployOpen plans, builds and tests the integration with the client, from the app registration and permissions model through to the mapping rules and test cases. The client remains responsible for the tenant itself, including its licensing and administrative roles.
Before the build starts, confirm three points with Evolveum and within your own tenant. First, confirm the connector version and the midPoint release it targets, since connector support is tied to the platform release in use. Second, confirm which Graph API permissions your app registration will receive and whether your security team accepts them. Third, confirm whether any Office 365 functions you need depend on the legacy Office 365 or .NET Exchange connectors, because those are listed separately in the catalog and do not carry the same path.
Prerequisites for Microsoft Entra ID provisioning in midPoint
Six prerequisites shape the first midPoint and Microsoft Entra ID provisioning project: the Java runtime, the repository, where midPoint runs, the release line, the connector version, and the Microsoft tenant identity. Settle them in this order, because the release choice sets the Java version and database support. Confirm each one in writing before implementation begins.
Java version matched to release
midPoint runs on a Java version tied to its release line. Evolveum recommends Java 25 for midPoint 4.11 and later, with Java 21 supported, and Java 21 for 4.10 and older, with Java 17 supported. Install the recommended version on every midPoint node and record it in your build sheet, since a mismatched JVM is a common cause of failed starts after an upgrade. Confirm the current requirements on the system requirements page before you order servers or images.
PostgreSQL repository on a separate server
midPoint uses PostgreSQL as its native repository. Evolveum recommends running the database on a separate server from the midPoint nodes, so backup, patching and sizing follow their own schedule. Ask who owns the database instance, how it is backed up, and which PostgreSQL version your chosen midPoint release supports. Multi-node deployments share this one central database, so its availability limits the whole deployment.
Linux virtual machine or Docker host
midPoint can run on Linux in a virtual machine or from Docker images. Choose the option your operations team already supports for patching, secrets and monitoring. Either way, each midPoint node needs outbound HTTPS to the Microsoft Graph endpoints and a network path to the PostgreSQL server. Check egress rules, proxy settings and certificate trust with your network team before the first connector test, because firewall blocks often look like connector errors.
Release line chosen against support dates
Pick the release line first, because it fixes the Java version, database support and upgrade path. As published, midPoint 4.8 (Curie) is a long-term support release supported until 17 October 2028, and 4.10 (Braille) is supported until 26 November 2027. Support for 4.9 ends 18 October 2026, and 4.11 (Čapek) is planned for 21 October 2026. Compare these dates with your go-live and upgrade plan, and confirm the support window in your subscription terms.
Connector and midPoint compatibility
The Microsoft Entra connector is built on the ConnId framework and is listed in Evolveum's catalog as supportable. Before you choose a midPoint release, open the connector documentation and confirm the connector version and the midPoint version it supports. Record both versions in your change request. If the documentation does not state the combination clearly, ask Evolveum to confirm it in writing before the release is fixed.
Entra administrator and named service account
Someone with an administrator role in the Microsoft tenant must register the application that midPoint uses and grant the consent its Graph permissions require. Ask who holds that role and whether consent needs separate approval under your tenant governance. Create a named service account for midPoint, with credentials stored in your secrets tooling, so its actions are attributable in Entra audit logs and can be included in access certification campaigns.
Which Entra connector to use and what it covers
The Evolveum connector catalog lists the Microsoft Entra (former Azure) Connector as supportable, and it covers Office365 and Entra ID through the Microsoft Graph API. That is the connector this plan is built on. Before you commit to it, confirm that the Graph-based connector is the right fit for your tenant, because the catalog is a statement of documented scope rather than a guarantee that every workload is covered.
The same catalog also lists a Legacy Office 365 Connector and a legacy .NET Exchange connector. These older connectors sit alongside the Graph API connector, and they are not the path this plan follows. Do not assume that a feature you saw in an older integration carries over automatically. Treat the Graph connector as the starting point and identify each function that your current process depends on, then check it against the connector's documentation.
Confirm Exchange and mailbox needs before scoping. Older connectors may still be the only documented path for some Exchange or mailbox functions. List the mailbox operations you need from midPoint, such as creating or updating mailboxes, managing mailbox properties or handling shared resources, and map each one to a documented capability of the Graph connector. Any gap becomes an explicit scope decision: either accept a manual step, plan a different mechanism, or confirm with Evolveum that the function is supported before the statement of work is signed.
Ask Evolveum or review the connector documentation for the exact version of the Entra connector that matches your target midPoint release. Connector capabilities and support status can differ between releases, so the check should be run against the versions you will actually deploy. Record the result as part of the scope, including which operations are covered, which are not, and which depend on the legacy connectors.
Keep the scope to what the catalog documents. Do not plan around features that you assume the connector provides but cannot find in its documentation. Where a required function is not clearly listed, write it down as an open question, assign an owner and resolve it before design sign-off, because an unresolved gap found during build usually costs more to fix than one found during scoping.
Configuration sequence for the Entra ID connector
This sequence takes a midPoint installation from a confirmed platform baseline to a tested Entra ID connection that can create and remove accounts in a non-production tenant. Each step closes with a check, so the team knows whether to continue. Confirm the exact permissions and settings against the connector documentation for your release before you start.
Confirm the midPoint release and platform baseline
The platform team confirms which midPoint release you will run and whether its support window covers the planned go-live. Check the releases page for current support dates, then check the system requirements for the Java version, PostgreSQL version and deployment model that release expects. Record the platform versions and node layout in the change ticket, and keep the connector documentation for that same release open for the steps that follow. Check: the baseline is written down, the release is covered by your support plan, and the team agrees on it before any tenant change is made.
Register the application and grant admin consent
A tenant administrator creates an app registration in Entra ID for midPoint and assigns the Microsoft Graph application permissions that the Evolveum connector documentation lists for your release. Use only the set the documentation requires. Then grant admin consent for the tenant so the permissions apply without user sign-in. Record the application ID, tenant ID and permission list in your configuration record. Check: the permissions show admin consent as granted in the portal, and no extra permissions are assigned.
Store the client credential where midPoint can read it
Create the credential the connector documentation specifies for the app registration, either a client secret or a certificate, and confirm which type your connector version supports. Place it in a store that midPoint's service account can read, such as a secrets manager or a configuration file with restricted permissions. Keep the value out of ticket comments, shared documents and version control, and record its expiry date in your renewal calendar. Check: the midPoint service account can read the value on the midPoint host, and a test read does not write the secret into logs.
Install and configure the connector in midPoint
The platform team installs the Microsoft Entra connector into midPoint, using the version that matches the release baseline, and restarts midPoint so the ConnId framework detects it. The Entra connector is maintained by Evolveum and listed as supportable in the connector catalog, which matters if you plan a subscription. Confirm the installed connector version in the administration interface. Check: the connector appears in the list of available connectors with the expected version, and the midPoint log shows no load errors.
Create the resource and run a connection test
An identity engineer creates a resource in midPoint that points to the tenant ID, application ID and credential location, and sets the connector configuration fields described in the documentation. Enable only the object classes needed for users and groups in the first version. Run the connection test from the resource page. Check: the test returns success with no authentication or permission errors. If it fails, compare the error with the granted permissions and the consent state before changing any other setting.
Import the schema and review object classes
Run a schema import from the resource so midPoint reads the object classes and attributes that the connector exposes from the Graph API. Review the account and group classes, and confirm the attribute names and types your mappings will depend on. Note any attribute that is read-only or needs a permission you have not granted. Check: the import lists the expected account and group objects with the attributes your design requires, and any missing attribute is traced to a permission or API limit.
Define mappings and correlation for users and groups
An identity engineer writes the mappings that set user attributes and group membership, and defines correlation rules that match existing Entra ID accounts to midPoint users before anything is created or changed. Agree the authoritative source for each attribute with the business owner, and keep the first version narrow. Run a simulation on a sample of existing accounts. Check: the simulation shows the matches and proposed changes, and the owner has reviewed and signed off on them before any provisioning runs.
Run a non-production provisioning cycle
Run a provisioning cycle against a non-production tenant or a test organizational unit, with test identities assigned through midPoint. Confirm that a test account and group membership are created, change one attribute, then unassign the account and confirm its removal. Compare the tenant state with midPoint's view after each action. Check: the test account is created and removed in the tenant, the actions appear in the midPoint audit record, and no unintended accounts changed. Plan production scope only after this check passes.
Identity and group attributes mapped between midPoint and Entra ID
This table lists the attribute categories that midPoint and Microsoft Entra ID exchange through the Entra connector, with the midPoint source, the Entra target, the direction of flow and the owner who confirms each rule. Use it as a planning checklist before mappings are built. Before the first sync, confirm exact attribute names against the connector schema in your midPoint version and decide which system is authoritative for each attribute.
| Attribute category | midPoint source | Entra ID target and direction | Rule owner to confirm |
|---|---|---|---|
| Account identity (UPN and primary identifier) | Identity object identifier and the attribute chosen as the account name in the resource mapping | Entra user principal name and object identifier. Outbound on create, matching on reconciliation | Identity architect with the Entra directory owner |
| Display and name attributes | Given name, family name and display name on the identity object, usually fed from HR | Entra given name, surname and display name. Outbound by default, confirm any inbound edits | HR data owner with the identity team |
| Mail and alias attributes | Primary email and any alias values on the identity object | Entra primary mail and proxy addresses. Outbound, with mailbox settings owned by the Microsoft 365 mail service | Messaging team with the identity team |
| Account enabled state | Activation status derived from lifecycle state, such as joiner, mover or leaver events | Entra account enabled flag. Outbound on lifecycle change, confirm whether sign-in changes return | HR lifecycle owner and security team |
| Password handling | Password value or generated credential set under the credentials policy on the identity object | Entra password profile on create and reset. Outbound only, confirm the password reset path | Security team with the identity team |
| Group objects | Group definitions held as role or resource objects in midPoint, named by policy | Entra group objects created and named by the connector. Outbound, with group settings owned in Entra | Application or collaboration owner |
| Group membership | Assignments of roles or associations that produce membership for each user | Entra group members and owners. Outbound for managed groups, confirm how manual Entra changes are handled | Role owners and access certification reviewers |
| Authoritative source per attribute | Identity object or Entra, recorded for each attribute before the first sync | Sync direction and precedence recorded per attribute in the mapping register | Governance lead who signs off the attribute register |
How to test Entra ID provisioning before production
Test midPoint's Entra ID provisioning in a scope where a mistake cannot reach live users, and agree the test boundary before the first connector configuration is saved. A separate test tenant is the cleanest option. If you must test in a production tenant, confirm with Microsoft's Graph documentation and your own tenant administrators whether the application permissions you grant can be limited to a dedicated set of users, groups or administrative units. If they cannot be limited, the test boundary is the tenant itself, and the test should run in a tenant you can rebuild. Record the tenant identifier, the application registration used by the Graph API connector and the permissions granted, so the reviewers can see exactly what the test could touch.
Build a test matrix that covers each lifecycle action midPoint can trigger against an Entra ID account and each group change. Create dedicated test identities for create, update, disable and delete, plus at least one identity that is added to and removed from a group. For every midPoint change, write down the expected state in Entra ID before the run, then compare it with the observed state afterward. For example, an illustrative case might expect a disable action to block sign-in and leave the object in place, while a delete action removes the object according to the retention rules your tenant applies. Confirm in your own configuration how the connector handles disable and delete, and whether group membership is removed when an account is disabled.
Reconciliation testing answers two questions: does a rerun create duplicates, and does drift get detected as expected. Run the same reconciliation task twice against unchanged data and confirm that no second account or group appears. Confirm which attribute midPoint uses to correlate and match Entra ID objects, and check that it is unique in the tenant. Then change a test account directly in the Entra admin center, such as altering a department value or removing a group membership, and run reconciliation. Check whether the result is reported, corrected or left alone, and compare it with the policy your team has written for drift.
Test the leaver path end to end before any production run. Simulate an HR or source-system leaver for a test identity, then verify the disable, group removal and any license handling that your Office 365 subscription requires. Write the rollback plan before the first production run: name the person who can stop the synchronization task, define how to pause resource assignments, export the relevant Entra ID state before each run, and state when midPoint changes are reversed rather than repaired. Keep every test run's logs, exports, screenshots, timestamps and approval records in a location that governance reviewers can reach. DeployOpen prepares this evidence for assessments, but independent auditors decide whether the controls meet the applicable framework.
Security settings for the Entra ID integration
These cards cover the controls that decide how far the midPoint connector can reach into your Microsoft tenant and how well its activity is recorded. Work through them in order, because the app registration defines the permissions that consent approves, and the credential, server and network controls limit what those permissions can be used for.
Application registration scope
Create the app registration for midPoint in the tenant that will be provisioned, and limit it to the Microsoft Graph permissions the connector needs for the accounts and groups in scope. Ask Evolveum or check the connector documentation for the exact permission list in your connector version, then remove any permission that serves only optional features. Record why each permission is requested so a reviewer can trace it to a specific provisioning task.
Admin consent and separation of duties
Name one administrator who is accountable for granting admin consent to the requested permissions, and record that approval in your change system. Keep this role separate from the people who approve access requests in midPoint and from the people who maintain the connector configuration, so that no single person can both request a permission and apply it. Confirm with your identity team which approvals they require before consent is given.
Service account credential lifecycle
Confirm which credential types the connector version supports, such as a client secret or a certificate, and choose the type your policy allows you to rotate and protect. Store the credential in a secrets manager or protected keystore, outside plain configuration files, and assign a named owner to a rotation schedule. Write a documented process for disabling the service account: who triggers it, how the app registration and its consent are revoked, how midPoint stops the connector, and how the disablement is confirmed in the audit logs.
Protecting midPoint configuration and secrets
Restrict read access to midPoint's configuration files, keystores and repository database connection to the service account that runs midPoint and to named administrators. Keep the connector credential out of exported configuration, backups and application logs, and check how your deployment displays stored values in the administration interface. Apply operating system hardening to the midPoint host and confirm file permissions again after each upgrade.
Network controls to Microsoft endpoints
Allow outbound HTTPS from midPoint nodes only to the Microsoft endpoints that the Graph API connector calls, and block all other destinations at the firewall or proxy. Confirm the current host list in Microsoft's documentation, because endpoints can change over time. In a multi-node deployment, limit node-to-node traffic for cache invalidation to the internal network, and confirm that the load balancer and database paths are reachable only from the midPoint nodes.
Audit logging in midPoint and Entra ID
Enable midPoint's audit records for provisioning actions, including which account or group changed, which task made the change, and the result. Forward these records to your central log store. Separately, review directory audit and sign-in events in Entra ID for the application's activity, and match them to midPoint records by timestamp and account. Confirm retention periods for both sources against your policy.
Common Entra ID provisioning failures and fixes
This table lists the failures teams most often meet when midPoint provisions accounts and groups to Microsoft Entra ID through the Graph API connector, with a likely cause and first fix for each. Causes are described in general terms, so confirm the specifics against the Evolveum connector documentation and your own tenant configuration before changing anything. Start with authentication and consent, because many later symptoms trace back to them.
| Failure | Likely cause | Fix |
|---|---|---|
| Connection test fails on authentication | An expired or mistyped client secret or certificate, or a tenant ID and client ID that belong to a different tenant or app registration. | Issue a new credential, update the midPoint resource configuration, and recheck the tenant and client IDs. Confirm the supported authentication method in the connector documentation. |
| Permission errors on specific operations after consent | Admin consent covers fewer Graph permissions than the failing operation needs, or consent was granted before new permissions were added to the configuration. | Compare the granted application permissions with the connector documentation, add the missing ones, grant admin consent again, and retest each operation separately. |
| Missing objects in midPoint | The enterprise application's assignment scope or the midPoint search filter excludes users or groups that midPoint expects to manage. | Review the assignment scope in Entra ID and the search filter in the resource. Confirm the affected objects are in scope before running reconciliation again. |
| Duplicate accounts in Entra ID | A correlation rule matches on an attribute that is not unique or is populated inconsistently, such as a display name or a secondary mail address. | Base correlation on a stable, unique attribute from the authoritative source. Test matches against a sample set, then clean up duplicates in Entra ID before enabling the rule. |
| Group membership not updating | The group falls outside the sync scope, its membership is controlled by a dynamic rule or another process in Entra ID, or the membership attribute is missing from the mapping. | Confirm whether the group is dynamic or managed elsewhere, check the membership mapping and object types in the connector configuration, then run reconciliation to verify the change. |
| Slow runs or throttling under large volumes | Full reconciliation generates many Graph calls in a short period, and the service slows or rejects requests when the request rate is too high. | Split work into smaller tasks, schedule full runs outside business hours, and use filtered or incremental runs where the connector supports them. Review Microsoft throttling guidance and connector settings. |
| Drift introduced by administrators in Entra ID | Administrators change users, groups or licenses directly in Entra ID, outside the attributes midPoint is configured to own. | Decide which attributes midPoint owns, schedule reconciliation to detect drift, and set a change path so manual edits are reviewed, documented or reverted. |
What supportable status means for subscription support
The supportable label for the Microsoft Entra connector in the Evolveum connector catalog describes the connector's documented status. Evolveum maintains the connector, which covers Office365 and Entra ID through the Graph API. The label tells you the connector is documented and maintained by the vendor. It does not tell you the connector will fit every tenant, licensing model or provisioning pattern your organization runs. Treat the label as the starting point for a scope conversation with Evolveum, and verify the remaining details before a project depends on them. Your Entra design, including how groups are sourced and how assignments are reviewed, should be checked against the documented behavior.
Evolveum offers two subscription types that matter for this connector. The Product Support subscription covers resolving product bugs, with either an 8x5 next-business-day or a 24x7 service level. The Platform Subscription adds feature development and roadmap influence, which suits teams that need changes to the connector or want a voice in its direction. Evolveum's support subscriptions page lists no prices, so the cost of either option comes from a written quote tied to your deployment. Ask what each option includes, how bug fixes are delivered, and whether a feature request would be scheduled under the Platform Subscription.
Before you rely on a subscription for Entra work, ask Evolveum two specific questions. First, which connector version and which midPoint release does the subscription cover? A connector version tied to one midPoint release may not match your upgrade plan, so name both in the quote and in your contract. Second, is the specific Entra scenario in scope? Examples to raise include group provisioning from your chosen source, license-related assignments and any use of the legacy Office 365 or .NET Exchange connectors that appear beside the Graph API connector in the catalog. Get both answers in writing, and confirm them again when your plan changes.
Plan for the gap between a catalog label and a confirmed answer. If a scenario falls outside the subscription scope, you still need a way to run it: a documented workaround, a custom change funded through a Platform Subscription, or an internal owner who accepts the risk in writing. Record the connector version, the midPoint release and the list of confirmed scenarios in your change records, so that audits and upgrades can check them later. Revisit these answers whenever you change the midPoint release or the connector version, because the coverage may change with them.
Questions buyers ask about midPoint and Entra ID provisioning
What drives the effort in an Entra ID provisioning project?
Tenant design, the number of identities and groups, mapping complexity, approval flows and test scope drive most of the effort. Each one changes how much design, build and verification work the project carries.
- Tenant design: how many Entra ID tenants and Office 365 licensing scopes midPoint must reach, and how admin consent is handled for each.
- Identities and groups: volume affects the initial load, reconciliation runs and test data preparation.
- Mapping complexity: attribute mappings from HR or directory sources, group membership rules and license assignment logic.
- Approval flows: whether requests need manager, owner or security approval before a change reaches Entra ID.
- Test scope: how many joiner, mover and leaver cases must be proven in a test tenant before production.
Ask for a written scope that names each of these so the quote reflects your environment.
Can our own team set up midPoint and the Entra ID connector alone?
Yes, a capable team can do it alone using the Evolveum connector documentation and a test tenant, but design choices and sign-off need named owners. The documentation covers configuration of the connector, and midPoint's documentation covers the platform itself. Teams most often underestimate ownership. Someone must decide the tenant model, approve attribute mappings, own the service account and consent, and accept test results. Without those owners, the project stalls at the first design question. A partner adds the most value where your team lacks midPoint experience, needs a fixed delivery date, or wants an independent review of the design before production. Decide early which roles you will fill internally and which you will buy in.
How long does an Entra ID provisioning implementation take?
Duration depends on the fixed scope agreed in writing before work starts, so this page does not give a figure. The scope sets the number of tenants, the mapping and approval rules, the test cases and the change windows. Prototyping in a test tenant early in the project usually shows how many design decisions remain open, which helps you judge the timeline. Calendar time also depends on access. Consent approvals, change freezes and data owner reviews can take longer than the build itself. Ask any provider to split the timeline into design, build, test and cutover, and to state which phases depend on your team's availability.
What must our organization provide before implementation starts?
Before work starts, you need to provide tenant access, an administrator who can grant admin consent for the connector's application permissions, data owners who approve attribute mappings and group content, test identities in a non-production tenant, and agreed change windows for cutover. Confirm the required Graph permissions in the connector documentation before the consent request goes out, so the administrator receives a clear list. Name one decision-maker who can respond quickly, because delays in consent or sign-off usually move the whole schedule. Also provide an export of current accounts and groups so the team can measure a reconciliation baseline before any changes are made.
Is the Entra ID connector supported for production use?
Yes, the Evolveum connector catalog lists the Microsoft Entra (former Azure) Connector as supportable, maintained by Evolveum, covering Office365 and Entra ID through the Graph API. Supportable status describes the catalog's maintenance position, but it does not by itself establish a support contract. Product Support subscriptions resolve product bugs under an 8x5 next-business-day or 24x7 SLA, while Platform Subscriptions add feature development and roadmap influence. Confirm in writing with Evolveum that your production use of this connector and your midPoint version fall under the subscription you plan to buy. Check the current terms on Evolveum's support subscriptions page, since catalog status and subscription coverage are separate questions.
What recurring costs come with midPoint and the Entra ID connector?
Recurring costs fall into four groups: midPoint subscriptions, release upgrades, connector maintenance and day-to-day operations. Evolveum offers Product Support and Platform Subscriptions, and its page lists no prices, so request current terms directly. Upgrades recur because midPoint releases reach end of support on fixed dates. The 4.9 line, for example, reaches end of support on 18 October 2026, and each move to a supported release requires regression testing of your Entra ID mappings. Connector maintenance covers reviewing Graph API changes and retesting after midPoint upgrades. Operations includes Java and PostgreSQL patching, backups and monitoring. Ask any partner to separate one-time build fees from retainer fees and to list what each includes.
How does DeployOpen price an Entra ID provisioning engagement?
DeployOpen does not publish a price list. A quote follows from the written scope, which lists the tenants, identities and groups, mappings, approval flows, test scope and the environments the team will work in. Most engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers and are quoted separately from the build. To compare quotes, give each provider the same written scope and ask for the assumptions behind the effort, what the client must provide, and which items are one-time and which recur. Subscription fees paid to Evolveum are a separate cost, so confirm them with Evolveum.
Which Entra ID connector should we choose, Graph API or legacy Office 365?
Plan around the Microsoft Entra connector based on the Graph API, which the catalog lists as the Entra ID route. The catalog also lists a Legacy Office 365 Connector and a legacy .NET Exchange connector alongside it, so check whether any requirement forces you onto one of them. Confirm the current status of each connector before you commit, because status can change between releases. Identify the Graph permissions the connector needs for the provisioning actions you plan, including account creation, group membership and license assignment, and check that your security team accepts the consent model. Test group membership, license assignment and account disablement in a non-production tenant before relying on them in production.
How DeployOpen scopes and delivers the Entra ID integration
DeployOpen scopes each midPoint and Microsoft Entra ID provisioning engagement in writing before work starts, and builds it inside your own cloud accounts, data centers or air-gapped network. The work starts with a check of which Entra ID and Office 365 objects are in scope and which connector status applies to each, then moves through build, testing, documentation and handover. Ongoing support, upgrades and testing are available as a retainer.
How we scope
- Written scope naming the Entra ID and Office 365 accounts and groups that midPoint will manage.
- Connector support status checked against the Evolveum catalog entry before the Graph API connector enters scope.
- Fixed-scope agreement with deliverables and timelines confirmed in writing before any build work begins.
How we build
- Tenant app registration and Graph API permissions designed with your identity team, reviewed before first connection.
- Attribute mappings, correlation rules and group handling built in a non-production midPoint environment first.
- Test cases covering create, update, disable and group membership changes against a non-production tenant.
How we hand over
- Runbook covering connector configuration, credentials rotation, and the steps to recover from failed provisioning tasks.
- Documented mapping of each Entra ID attribute and group to its midPoint source and target fields.
- Walkthrough with your operations team, with the subscription support path confirmed before go-live.
How we support
- Retainer options for ongoing operation, connector updates and midPoint upgrades, agreed in writing.
- Evolveum subscription terms, including SLA level, come from Evolveum, so confirm them with the vendor directly.
- Legacy Office 365 and .NET Exchange connectors are listed separately, so confirm their status before scoping them.
