Change management

Integrations change for three reasons: the business wants something different, the systems change underneath, or something keeps failing. PartnerMCP handles all three the same way. A change is a new version of the spec: proposed, tested in a sandbox, approved under your policies, promoted, watched — and reversible.

Where changes come from#

• You ask. “Don't create ERP orders below $500 anymore.” PartnerMCP finds the integration, writes the condition and estimates its impact from recent runs.
• PartnerMCP proposes. When the same failure keeps coming back — orders rejected because a customer's VAT number is missing, say — it proposes a fix, such as a validation step that holds those orders for review before they are submitted.
• The systems change. A required field is added, a module is licensed, an API is retired. Vendors publish these timelines: NetSuite's SOAP web services stop working with release 2028.2, and SAP deprecates individual APIs within S/4HANA Cloud releases. Integrations have to move with them.

Anatomy of a change#

1. 01Proposal — what will change, in one sentence, and why.
2. 02Diff — the exact lines of the spec that change.
3. 03Impact — what the change would have done over recent runs, computed from the run history.
4. 04Tests — the integration's fixtures plus new cases for the change, run in the sandbox.
5. 05Approval — by the people your policy names for this integration and this class of change.
6. 06Promotion — the new version goes live; the previous one stays deployable.

 steps:   - match: priority.CUSTOMERS+  - condition: Opportunity.Amount >= 500+    else: skip-and-log   - create: priority.ORDERS

The impact estimate is computed from your own run history — “based on the last 30 days, this rule would have excluded 17 orders” — so the decision is made on evidence, not intuition. Reviewers see the proposal, the diff, the impact and the test results on one screen.

When a system changes underneath#

Schema drift should be caught before it fails a run. When a system adds a required field, removes a column or retires an API, PartnerMCP compares the new metadata with what the spec depends on and proposes the smallest change that keeps the integration correct — a mapping for the new required field, a move to the successor API. The proposal then takes the same path as every other change.

Environments#

Integrations live in at least two environments: a sandbox, connected to test instances of your systems, and production. Each environment has its own connections and credentials — for Priority, a test environment or a duplicated company — so a test can never write to production. Promotion moves a tested version forward; nothing is edited directly in production.

Policies decide who approves what#

Not every change deserves the same scrutiny. Policies name the classes of change PartnerMCP may apply on its own — and then report — and the ones that always wait for a person.

policies:  apply_then_report:            # within the limits you set    - retry-tuning    - concurrency-reduction  require_approval:    - mapping-change    - new-condition    - new-write-operation  approvers:    production: [integration-owner]    finance-impacting: [integration-owner, finance-owner]

Slowing down after repeated HTTP 429 responses is a typical pre-approved change: it is safe, reversible and logged. A new write into your ERP never is.

Rollback#

Every production version stays deployable, so rolling back is a promotion of the previous version. Rollback changes behaviour from that moment on; it does not unwrite records already created in your systems. PartnerMCP lists what the rolled-back version touched — orders created, records held — so you can decide what to do with them.

The audit trail#

For every version, the history records who asked, what PartnerMCP proposed, the diff, the test results, who approved and when it went live. “Which integrations changed this week?” has a precise answer, and so does “who approved that?”.