Plan a ServiceNow or Jira integration

Planning guide: this article does not establish that a packaged ServiceNow or Jira connector is supplied, or that ChangePilot has agreed to deliver a custom integration.

Applies to: Dataverse-based ChangePilot Enterprise with a customer-specific integration agreed for your environment.

Who this is for: the change process owner, ChangePilot administrator and the owner of your service management platform.

Agree the integration approach

Enterprise can be extended with Power Automate and customer-specific workflows. The connection, fields, permissions and behaviour depend on the integration configured for your organisation. Do not assume a packaged ServiceNow or Jira connector is installed, or that a tag alone creates a ticket.

Ask your ChangePilot contact or support@changepilot.cloud which guidance or services are available for your requirements. Agree delivery, responsibilities and any commercial scope separately before enabling an integration.

Define what should create work

List the service categories, primary services and impact levels in scope. Specify whether ticket creation follows a tag, an assessment decision or another agreed event.

For example, a team responsible for Teams and collaboration may not own Identity or device management. A High-impact rule without a service-scope check can create work for the wrong team.

Define the record and ownership rules

• Source reference: retain the MCID and a link to the ChangePilot item.
• Duplicate prevention: define how the integration recognises an existing ticket before creating another.
• Accountability: map the ChangePilot owner to the right service management team or person.
• Status: agree which system owns each status and how changes map between systems. Do not assume a closed ticket always means a closed ChangePilot item.
• Updates: define what happens when Microsoft changes dates or content after a ticket has been created.
• Failure handling: identify who monitors failed runs and how work is recovered without creating duplicates.

Build in the customer configuration

Keep customer-specific flows and assets in the Configuration solution. Use connection identities and permissions approved for the integration’s purpose, and record who maintains them.

For existing examples, see flow template instructions and the standard included automations. Those examples do not establish the behaviour of a customer-specific ITSM connection.

Validate before wider rollout

1. Agree an appropriate test item and the expected destination.
2. Confirm an in-scope item creates or updates the intended record with the correct owner and reference.
3. Confirm an out-of-scope item does not create unintended work.
4. Repeat the agreed event and verify duplicate prevention.
5. Check status updates in each direction that is configured.
6. Check how moved dates, connection failures and retries are handled.

Use an agreed test environment or controlled test process. Tests can create real tickets or messages, so coordinate them with the receiving team.

Operate and maintain the integration

Check integration health during your regular review and after a ChangePilot update. Reassess mappings when categories, people or customer statuses change. Include the integration in the post-update validation and use the support checklist for failures.

Documentation reviewed: 12 November 2026.