midPoint ServiceNow integration: ITSM ticketing services

How midPoint integrates with ServiceNow when no connector exists

When a target system has no midPoint connector, provisioning still has to reach that system, and in many organizations the only sanctioned route is an IT ticket that a person fulfills. midPoint's built-in manual connector can manage provisioning tickets on a real ITSM system through a dedicated ticketing resource, and the tickets are managed as projections of midPoint cases. The Evolveum connector catalog also lists a ServiceNow connector, but it carries community support status and is maintained under ConnId, so it is not the same kind of commitment as a supported connector. Both paths are covered in this section, and the support implications are covered later on this page.

The ticketing resource is introduced in midPoint 4.11, which Evolveum's releases page plans for 21 October 2026. Before you plan anything that depends on it, confirm two things with Evolveum: the current release status of 4.11, since planned dates can move, and the midPoint version your environment will run when the work goes live. If your production deployment runs 4.10 or older, the ticketing resource is not available to you without an upgrade, and the upgrade path has to be planned as its own work item. Record the target version in the design document so every later decision references the same release.

The working model is that a midPoint case represents the pending change, and the ticket in ServiceNow is a projection of that case. When midPoint needs an account or entitlement created, changed or removed on the unconnected system, it opens a case, the ticket is created from it, and the status of the ticket flows back so the case can close. Your design should define which midPoint resource object maps to which ServiceNow table and category, which fields the fulfiller needs to act without asking questions, and who owns the ticket queue. Ask your ServiceNow administrator to confirm the table, the assignment group and the state values before any mapping is built.

The community ServiceNow connector is a different decision. It may offer direct account management, but its status means Evolveum's subscription support does not cover it in the same way as supported connectors. Treat it as a candidate that needs its own evaluation: test it against your ServiceNow instance version, confirm the authentication method and review what it can and cannot change. Compare that effort with the ticket-based route, which keeps the human fulfillment step that some change policies require. The choice often depends on whether your audit obligations need evidence of a person approving each change at the target system.

What you need in place before building a ticket-based integration

These six items must be in place before you configure the ticketing resource. They cover the midPoint platform baseline, the database and topology decisions, and the ITSM accounts, routing and network path that connect midPoint to the ticket queue. Work through them in order, because the topology and database choices shape how the service account and network path are set up.

midPoint 4.11 with Java 25

The ticketing resource is part of the 4.11 release, so the midPoint build must be 4.11 or later. The midPoint releases page lists 4.11 as a feature release planned for 21 October 2026, so confirm the released build before you schedule the work. midPoint recommends Java 25 for 4.11 and later, and Java 21 is supported. Check your JVM version against the system requirements now, because a mismatch blocks every later step.

PostgreSQL on a separate server

PostgreSQL is midPoint's native repository database, and midPoint recommends running it on a separate database server from the application. Ticket case records and task state are stored in this repository, so its sizing, backup method and connection credentials need agreement before installation. Ask who owns backups and restore testing for that server, and confirm that the team can recover it independently of the midPoint nodes.

Single-node or multi-node topology

Decide the topology before building the integration, because it changes how cases and scheduled tasks run. A single node is the simpler setup. A multi-node deployment needs a sticky HTTP load balancer, a shared central database, cache invalidation between nodes over HTTPS and Quartz for distributed task scheduling. Record the chosen pattern in the design document and test ticket creation and updates on each node in your environment.

ITSM administrator and service account

Create an administrator account in the target ITSM instance with rights to create and update tickets. Give midPoint a named service account, so every ticket action traces to one identity that a named owner manages. Confirm with the ITSM owner which roles grant ticket creation and update in your instance, and who handles password or token rotation for that account.

Fixed category and assignment group

Provisioning tickets should land in one fixed category and one assignment group, so queue ownership and routing stay predictable. Agree the category and group names with the service desk, and confirm that both exist in the target instance before you configure midPoint. Changing them later alters which tickets midPoint creates and which ones your team reviews, so record the decision and its owner in the design document.

HTTPS network path and vendor terms

midPoint must reach the ticketing API over HTTPS, so open a route from every midPoint node to the ITSM endpoint through your firewalls and proxies. Test the path from each node, not only from one. Confirm the vendor's API version, authentication methods and licensing requirements for API access with the ITSM vendor before you commit to a design, because API access can depend on the license tier you hold.

How midPoint turns provisioning cases into IT tickets

When midPoint needs a person to make a change on a system that has no connector, it opens a case. Each case records what access should exist, for whom and why, and it stays open until someone completes the work and the outcome is recorded. Without the ticketing resource, that person completes the case in the midPoint interface. The midPoint 4.11 release notes describe a different option: the built-in manual connector can manage provisioning tickets on an ITSM system through a dedicated ticketing resource. Each ticket is a projection of a midPoint case, so the request leaves midPoint and lands in the service desk queue while the case remains the record of what was asked for.

The two paths differ mainly in who does the work and where that work is tracked. A manual case is completed by a named midPoint user in the midPoint interface, and the decision and outcome are recorded there. A ticket is completed by service desk agents in the ITSM tool, which usually means queues, assignment groups, work notes and service levels that midPoint does not manage. Your service desk will expect that second model. The design question is whether agents need any midPoint knowledge at all, or whether the ticket text alone must give them enough to act without contacting the requester. Plan the ticket content with that reader in mind before the first flow is built.

Ownership needs to be split explicitly. midPoint should stay authoritative for the case itself, the intended assignment the case asks for, and the audit trail showing who requested the change, who approved it and how it was closed. The ITSM system should stay authoritative for the work log and the fulfillment steps, such as the notes an engineer writes while provisioning an account. Agree this split in writing before go-live, and decide which record a reviewer consults when the two disagree. Auditors will ask which system proves that an access was granted, so the answer should name one system for each fact.

The status round trip is where most of the integration risk sits. The release notes describe the ticket state being reflected back into the case so that the outcome can be recorded, but they do not list every ticket state, closure reason or reopen path. Those details depend on your ITSM configuration and your midPoint version. Before relying on the flow, test each outcome you care about in a non-production instance: completed, rejected, cancelled, reopened and closed without action. Record what midPoint shows for each one. If an outcome does not map cleanly, decide in advance whether the case stays open for a person to close manually.

Keep the ServiceNow question separate from the ticketing resource. The Evolveum connector catalog lists a ServiceNow connector with community support status, maintained under ConnId. A community connector carries a different level of commitment than a supported one, so confirm with Evolveum what subscription support covers before you place a ServiceNow-dependent flow in scope. Ask the same question about the ticketing resource in the release you plan to run. The 4.11 release is a feature release planned for 21 October 2026, so confirm its availability and your upgrade path on the midPoint releases page before you commit a project date.

Ticketing resource, manual cases or community ServiceNow connector: which fits

The built-in manual connector with the ticketing resource is the path midPoint 4.11 documents for managing provisioning tickets on a real ITSM system. Tickets are handled as projections of midPoint cases, so each ticket stays linked to the case that requested the change. The 4.11 feature release is planned for 21 October 2026 according to the midPoint releases page, so this option applies only once the team runs 4.11 or later.

Support status: documented in the 4.11 release notes as part of the release itself.
Maintainer: Evolveum maintains the built-in connector and the ticketing resource.
Effort to operate: configure the resource against the ITSM instance, map ticket fields, and confirm how ticket state returns to midPoint.
Decision drivers: a team that can run 4.11 or later, and an ITSM product the release notes cover.
Upgrade planning: a move to 4.11 is a version change with its own test cycle, so schedule it with the other upgrade work.

Confirm the supported ITSM products and version requirements in the 4.11 release notes before you design the integration around them.

How to configure the ServiceNow or ITSM ticketing integration in order

This sequence takes a midPoint 4.11 environment from version checks to a limited rollout of IT tickets opened from manual provisioning cases. Each step closes with a check, so the team confirms the previous step held before adding the next dependency.

Confirm the midPoint version and Java runtime
Confirm the midPoint version in your environment and read the 4.11 release notes before changing any configuration. midPoint recommends Java 25 for version 4.11 and later, with Java 21 supported, so check the runtime your nodes actually run against the runtime in your install plan. Ask the platform owner to record the exact midPoint build and the Java version output for each node. The step is closed when every node reports the same supported build and runtime, and the notes are filed with the change request.
Prepare the ITSM service account and category
Ask the ITSM administrator to create a dedicated service account for midPoint and a provisioning category or request type that midPoint's tickets will use. Take the permissions the account needs from the ITSM vendor documentation, and limit them to creating and reading records in that category. Confirm the account and category names with the ITSM owner in writing. The step is closed when a login test run outside midPoint shows the account can create and read one record in the category and cannot reach unrelated records.
Define the ticketing resource in midPoint
Create the ticketing resource in midPoint using the dedicated resource type described in the 4.11 release notes. Enter the instance endpoint, the authentication method and the field mapping from the ITSM vendor's API documentation. Confirm exact endpoints and field names with the ITSM administrator before saving. Store the service account secret in your protected credential store and keep it out of shared resource exports. The step is closed when the resource test connection succeeds with the service account and the mapped fields match the vendor documentation for the category.
Map case-to-ticket states
Write a table that links each midPoint case state to the ticket state that should appear in the ITSM system, and to the state midPoint should accept back from the ITSM side. Agree the table with the provisioning owner and the ITSM team, because the ITSM workflow may need states that the vendor's default setup does not include. Check that every case state has a defined ticket counterpart and that every returned ticket state leads to a defined outcome. The step is closed when the signed-off table exists and matches the behavior the 4.11 release notes describe for the manual connector.
Create one test object for a single ticket
In a non-production environment that mirrors your ITSM configuration, create one test identity or assignment that triggers one manual provisioning case. Let the workflow run once and watch for exactly one ticket in the ITSM system. Record the case identifier and the ticket identifier together so the link can be checked later. The step is closed when one ticket exists, it is linked to one case, and the midPoint log shows a single operation with no repeat tickets from retries.
Verify ticket content and returned status
Open the ticket and check each field against the mapping from the resource step: the summary, the description, the requester, the category and any custom fields the ITSM team configured. Then change the ticket status in the ITSM system and confirm the new state appears on the midPoint case. Test the completion path and, if your process uses them, the rejection or cancellation paths. The step is closed when the content matches the mapping, the returned status updates the case, and a repeat of the same test produces no duplicate ticket.
Test the community ServiceNow connector separately
If your team chooses the community ServiceNow connector from the Evolveum catalog instead of the built-in ticketing resource, install it first in a non-production environment and test it there. The catalog lists its support status as community and maintains it under ConnId, which affects what your subscription covers, so confirm that with Evolveum before depending on it. Repeat the single-ticket and status checks against it, and record the connector version, the midPoint version and the ServiceNow instance version in the change record. The step is closed when the platform owner and security team have reviewed the results and recorded versions.
Enable the flow for a limited group first
Enable the ticket flow for a small, named group of users or one business unit, and leave other provisioning paths unchanged. Assign one person to watch the ITSM queue and the midPoint case list during the first cycle, and agree a rollback step with the ITSM team, such as disabling the resource or pausing the workflow. Widen the scope only after the limited group completes its first cycle without duplicate tickets or unmatched status changes. The step is closed when the limited rollout has run its agreed period and the owner signs off the wider rollout.

Which midPoint case data maps to ticket fields

This table lists the midPoint case data that the ticketing resource is expected to carry into an ITSM ticket, the side that owns each value, and what to confirm in your instance. Read it as a design checklist to complete before build. State changes flow back from the ticket to the case, so confirm the return path before relying on a closed ticket to complete a provisioning case.

midPoint concept	Ticket concept	Source of truth	What to confirm
Case title or summary	Short description or summary of the ticket	midPoint case, projected onto the ticket when it is created	Maximum length in your ITSM instance and whether midPoint sets it at creation or later
Requested action (grant, change, revoke)	Work item type or category that signals the action to fulfillers	midPoint provisioning operation that opened the case	That each action is visible as a separate ticket value, so fulfillers do not need to parse the summary
Target account or entitlement	Structured field or description text identifying the account and entitlement	midPoint projection and the entitlement assignment in the case	Whether the target is a structured field or free text, and whether it can be searched and reported on
Requester and approver	Requester on the ticket and approval records attached to it	midPoint case history and approval decisions	Whether the midPoint approver can be stored on the ticket, or whether approval stays only in midPoint
Assignment group	Assignment group that receives the fulfillment work	Mapping defined in the midPoint ticketing resource configuration	Which group values midPoint sends, who maintains the mapping, and what happens when a group is renamed
Due date	Due or target date on the ticket	Deadline on the midPoint case, where one is set	Whether ticket SLA timers are separate from midPoint case timing, and which one drives escalation
Completion state	Ticket state, including its closed and cancelled states	Ticket state, read back into the midPoint case work item	Which ticket states count as complete, rejected or cancelled. Whether midPoint polls the ticket or receives a callback, and how a reopened ticket updates a closed case
Closing comment	Close notes or work notes on the ticket	Outcome note written by the fulfiller, copied to the midPoint case	Whether the closing comment is written back to the case and whether it is retained for audit review

Security settings for a ticket-based provisioning flow

When midPoint hands a provisioning step to a person through an ITSM ticket, the ticketing resource becomes an identity-relevant system in its own right. The controls below cover the credentials, transport, roles, and logs that the flow depends on, and they map to the access review and audit processes your organization already runs. midPoint is an identity management system, so this flow does not change your SSO design.

Dedicated least-privilege service account

Create a service account in the ITSM tool used only by the midPoint ticketing resource. Grant it only the ticket create, read, and update rights the manual provisioning cases need, and deny administrative functions such as user management, workflow design, and integration configuration. Ask the ITSM team to confirm the exact permission set in writing, since role names differ between products.

Ticketing credentials kept out of plain configuration

Store the ITSM account password or API token in a secrets store or an encrypted credential mechanism rather than in the midPoint resource XML or a readable configuration file. Confirm how your midPoint deployment loads these values, who can read the secret store, and how the credential is rotated and revoked when the integration owner changes. Include the rotation step in your runbook.

HTTPS with certificate validation

Allow only HTTPS between midPoint and the ITSM endpoint, and make sure midPoint validates the server certificate against your trusted certificate authority chain. Do not disable verification to get a test working, and check that a plain HTTP fallback cannot be configured. Confirm the certificate renewal process with the team that owns the ITSM instance.

Separation of duties on approved requests

Where policy requires it, the person who approves an access request in midPoint must not be the person who completes the matching ticket. Define this rule before build, decide which roles or groups it applies to, and test it with real approver and fulfiller accounts. Record the exception process for urgent requests, so approvers cannot quietly bypass the split.

Audit logging across midPoint and the ITSM system

Enable logging of case and ticket events in midPoint, including case creation, work item completion, and ticket state changes, and confirm that the ITSM system records the same ticket activity with the service account identity. Decide where both logs are retained and who reviews them. Check that a single request can be traced from the midPoint case to the ticket and back.

Review of who can edit the ticketing resource

Limit edit rights for the ticketing resource in midPoint and the change rights for the ITSM integration to a named group. Changes to endpoints, credentials, or the ticket mapping alter where provisioning requests go, so treat them as configuration changes with review and logging. Include this group in your periodic access review so the list stays current.

Common failures in ticket-based provisioning and how to fix them

This table lists seven failures that can appear when midPoint provisions access through IT tickets, with the likely cause, the first check to run and the fix for each. Work through the rows in order, confirming that the request reached midPoint and the ticket system before you examine mappings or the community connector. The main takeaway is that most failures trace back to logs, service account permissions or resource configuration, so check those before changing anything.

Failure	Likely cause	First check	Fix
Tickets not created	The operation never reached the ticketing resource, or the resource is not in your midPoint version (the ticketing resource arrives in 4.11).	Read the midPoint task and case logs for the triggering operation and confirm whether a case was opened.	Confirm your version includes the ticketing resource, correct the resource assignment, then rerun the affected provisioning.
Tickets created with empty or wrong fields	Attribute mappings from midPoint to ticket fields do not match the fields or form that the service account can write.	Compare the resource configuration before and after the last change, then inspect one sample ticket.	Correct the mapping, test with a single identity in a non-production instance, then review and correct open tickets.
Status not returning to the case	Ticket state changes are not read back into midPoint, so the case never receives the closed signal.	Check the case log for the last status update and confirm in the ITSM system that the ticket was closed.	Fix the read-back path for the status field and confirm the service account can read the ticket.
Duplicate tickets after retries	A failed request is retried without checking whether a ticket already exists, so a second ticket is raised for the same case.	Search the ITSM system for two tickets with the same identity and operation, and review retry entries in the task log.	Key the create step to the case reference so retries update the existing ticket, and limit retries to requests that truly failed.
Cases stuck open after the ticket closes	The status mapping does not cover the closed state your ITSM workflow uses, so midPoint never marks the case complete.	Compare the closed states in your ITSM workflow with the status mapping in the resource configuration.	Add the missing closed state to the mapping, then reprocess the stuck cases.
Authentication failures from the service account	The password has expired or the account is locked, or its ITSM role lacks read or write rights on the ticket table.	Test the account login outside midPoint and review authentication and audit logs in the ITSM system.	Confirm service account permissions and credential rotation, then update the stored secret in midPoint.
Community connector behaves differently after an upgrade	The community ServiceNow connector is maintained under ConnId and is not a supported connector, so its behavior can change when midPoint or the connector is updated.	Compare the resource configuration and connector version before and after the change, and read the release notes for both.	Retest mappings in a non-production instance with the new version, pin versions until testing passes, and decide whether to keep the connector or move to the ticketing resource.

How to test ticket-based provisioning before go-live

Test ticket-based provisioning in a non-production environment that mirrors the production midPoint configuration and the ITSM workflow it will drive, and agree the pass criteria before the first test case runs. The core question for the security or audit team is simple: when midPoint records a provisioning need for a system with no connector, does exactly one ticket appear, does its state stay in step with the midPoint case, and does a failure at the ITSM endpoint leave no duplicate work behind? Each part of that question needs its own evidence. Build the test environment from two parts: a non-production midPoint deployment on the same release line as production, and a sandbox or test instance of the ITSM product with the same ticket type, required fields, assignment groups and workflow states. Confirm with the ITSM owner that the test instance's workflow matches production, because a ticket that closes in the sandbox but waits for an approval in production will invalidate the closure tests. Confirm the midPoint version against the release notes for the ticketing resource, since the ITSM ticketing resource was added in midPoint 4.11, and check the Java and database requirements for that release before you install it.

Script the test cases so they can be rerun after every configuration change. Cover four operations: create (a new assignment that requires a manual fulfillment ticket), update (a change to attributes or entitlements that the ticket must reflect), complete (the ITSM agent closes the ticket with a fulfilled outcome) and cancel (the assignment is removed or the request is withdrawn before fulfillment). For each case, record the midPoint case identifier, the ticket identifier, the timestamps of each state change and the expected end state. Run each case against a sample of identities and entitlements that spans the roles and systems in scope. The sample size and the duration of the test cycle depend on how many connected systems are in scope and how complex the ITSM workflow is, so ask the implementer to size the sample from your system inventory rather than accept a fixed number. The failure test is where most ticket integrations fail in practice. Make the ITSM endpoint unavailable during a create operation, let midPoint retry, then restore the endpoint and count the tickets. Repeat the test during an update and a cancel. The team should confirm that retries reuse the existing case and do not open a second ticket, and that the case reflects the true state once connectivity returns. Check that a closed ticket closes the corresponding midPoint case, and that a ticket cancelled in the ITSM system does not leave an orphaned open case. Record the retry settings in use, since they determine how long a failure can persist before someone must act.

Acceptance evidence should be ready for review before the test window opens. Auditors will typically ask for the test plan with its version and approver, the list of executed cases with pass or fail results, the midPoint case and ticket identifiers for each run, the relevant midPoint and ITSM log extracts with timestamps, screenshots or exports showing the ticket and case states at each checkpoint, and a record of every defect found and how it was resolved. Keep the logs from the failure test separately, because they are the main proof that retries did not duplicate work. Store the evidence in a location with access control and retention that matches your audit policy. Close the test with a formal sign-off from the identity owner, the ITSM owner and the security or audit representative. The sign-off should state the release and configuration tested, the scope covered, any accepted deviations and the conditions for go-live. DeployOpen can run this testing as part of a fixed scope agreed in writing before work starts, including the test plan, the execution, the evidence pack and the sign-off support. Ask the quote to state which environments are provided by you, which are built by DeployOpen, and who maintains the ITSM sandbox after handover.

What buyers ask before hiring help for ServiceNow or ITSM ticketing

What drives the cost of a midPoint ServiceNow integration?

The main cost drivers are the number of target systems, the complexity of your ITSM workflows, the approval design, the testing scope, and the midPoint version in use. More ticket types, categories, assignment groups and state transitions mean more design and test work. One-time costs include the design, build, testing and handover. Recurring costs include ServiceNow licensing, any midPoint support subscription you choose, and retesting after midPoint or ServiceNow upgrades. Ask for a quote that separates one-time work from recurring items, names the systems in scope, and lists which approval paths and ticket types are included. Also ask how client time for owners, testers and ServiceNow administrators is counted.

Can our team build a midPoint ServiceNow integration without a partner?

Yes, if your team has midPoint administration skills, ServiceNow administration skills covering workflows and API roles, and time to test ticket lifecycles from request to closure. The midPoint 4.11 release notes describe a ticketing resource for the built-in manual connector that manages provisioning tickets as projections of midPoint cases. The 4.11 release is planned for 21 October 2026, so confirm the release status before you plan around it. Teams without spare test capacity often find that the hardest work is handling failed tickets, reopened requests, and changes made directly in ServiceNow. Those cases need to be designed and tested before go-live.

How long does a midPoint ServiceNow ticketing integration take?

Duration depends on the scope and on the ServiceNow instance you run. A typical sequence covers discovery, workflow design, build, testing and handover. Instance access, sandbox availability and the speed of your approval decisions often set the pace more than the build itself. DeployOpen delivers most engagements as fixed-scope work, so scope, deliverables and timelines are agreed in writing before work starts. No duration applies to this integration until the scope is written. Ask the provider to show the timeline against each phase and to state which client dependencies it assumes, such as test instance access by a specific date.

What does our organization need to provide for a ServiceNow integration?

You need to provide four things. First, ServiceNow access, meaning a test instance, production access for cutover, and an integration user with the roles the ticket workflow requires. Second, a named owner who can make scope and approval decisions. Third, sample tickets for each request type, including typical and failed examples. Fourth, workflow documentation that covers ticket states, required fields, approvers, assignment groups and escalation rules. You should also provide midPoint test environment access and representative test identities. Missing documentation is one of the most common causes of rework, so ask for a documentation checklist in the quote.

Is the community ServiceNow connector acceptable for production use?

It depends on your risk tolerance and on what support you need. The Evolveum connector catalog lists a ServiceNow connector with community support status, maintained under ConnId. Before you rely on it, confirm with Evolveum which subscription coverage, if any, applies to community-status connectors. Check the connector's compatibility with your ServiceNow release and your midPoint version, and test failure modes such as timeouts and rejected updates. You also need an owner for fixes and upgrades. If the built-in ticketing resource covers your workflow, compare the two options on those points in writing before you choose.

How does midPoint track provisioning requests raised as tickets?

In the ticketing resource described for midPoint 4.11, each provisioning ticket is managed as a projection of a midPoint case. The case records the request, and the ticket reflects its state in your ITSM system. A person working the ticket completes the change, and midPoint updates the case, so the audit trail stays in midPoint. Confirm the exact states, callbacks and error handling against the release notes and your ServiceNow configuration during design. Test what happens when a ticket is cancelled, reassigned or closed without completing the change, because those cases determine whether access records stay accurate.

How does DeployOpen deliver a fixed-scope midPoint integration?

DeployOpen is a Chainscore Labs company that plans, implements, integrates, documents and supports self-hosted open-source platforms in your own infrastructure. Most engagements are fixed-scope. The scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope. Testing, documentation and handover are defined as deliverables, so you can check them against the agreement. After go-live, ongoing support, upgrades and continuous testing are available as retainers. Ask for the written scope to list the target systems, workflows, approval paths, test cases and the midPoint version it covers.

How DeployOpen works on this

DeployOpen scopes, builds and supports midPoint ServiceNow and ITSM ticketing integration inside your own infrastructure. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. The work begins with the systems that have no connector and the provisioning steps that depend on tickets. Ongoing support is available as a retainer.

How we scope

Written scope lists which target systems move to tickets and which stay on a connector.
We confirm the ITSM product, version and API access before build work is planned.
Ticket fields, states, approvers and closure rules are documented as part of the scope.

How we build

Tickets are built as projections of midPoint cases, with the ticketing resource configured for your ITSM system.
Where a ServiceNow connector is used, its community support status is recorded and reviewed before go-live.
Test plans cover ticket creation, updates, closure and failed ticket calls against a non-production instance.

How we hand over

Handover documents the case definitions, ticketing resource settings and the ITSM fields they depend on.
Your team receives run notes for ticket failures, retries and manual reconciliation steps.
Delivery includes the configuration in version control you operate, with access under your control.

How we support

Ongoing support can run as a retainer covering fixes, monitoring of ticket failures and changes.
Upgrades are planned against midPoint release timing, including the 4.11 feature release planned for 21 October 2026.
Before adopting 4.11 features, confirm the release date and the ServiceNow connector status with the vendor.

midPoint ServiceNow and ITSM ticketing integration