| 1 | Classify | Classify the artifact type (iFlow, value mapping, script collection, API provider, integration package) and change type (new deployment, update, rollback, undeploy) | Artifact type and change type documented |
| 2 | Confirm target | Confirm the exact target tenant (Cloud Integration tenant ID, environment tier: QA/PPD/PRD, Integration Suite sub-domain) | Target tenant ID, tier, and sub-domain confirmed by user |
| 3 | Criticality assessment | Assess business criticality of the affected integration (financial document exchange, order-to-cash, HR data, payment processing, regulatory reporting) | Criticality level: low/medium/high/critical |
| 4 | Requester confirmation | Confirm the name, role, and authorization of the change requester | Requester name and role documented |
| 5 | Integration-owner approval identification | Identify the integration owner — the team or individual accountable for the iFlow and its downstream partner connections (different person from requester — SoD requirement) | Integration-owner name, role, and accountability scope |
| 6 | Ticket linkage | Link the deployment to a change management ticket (ITSM reference: ServiceNow, Remedy, SAP Solution Manager ChaRM, etc.) | Ticket number confirmed |
| 7 | Scope documentation | Document the complete list of artifacts to be deployed or modified: iFlow IDs, package names, version numbers, and interdependencies with other iFlows or API providers | Artifact list with IDs, versions, and dependency map |
| 8 | Read-only current state | Read the current state of the target tenant: deployed artifact versions, runtime status, active message queues, recent error rates from monitoring | Live evidence from target tenant (read-only) |
| 9 | Diff of artifact changes | Produce a diff of the artifact changes: which iFlow steps, routing conditions, adapter configurations, scripts, and value mappings are changing relative to the currently deployed version | Diff output documenting changed components |
| 10 | Blast radius | Document all downstream partner systems, dependent iFlows, API consumers, message throughput estimates, and business processes affected; assess risk of message loss or duplication during deployment | Blast radius document with affected partners, consumers, and throughput impact |
| 11 | Rollback plan | Document the explicit rollback procedure: which artifact version to redeploy, how to trigger a previous-version redeploy from the Cloud Integration design workspace or API, and any partner notification steps required | Rollback procedure documented and confirmed feasible |
| 12 | SoD verification | Verify that requester (step 4) and integration owner (step 5) are different authorized individuals; confirm no self-approval | SoD confirmed: requester ≠ integration owner / approver |
| 13 | Approval gate | Obtain explicit written approval from the integration owner for this specific deployment | Approval statement on record in this session |
| 14 | Execute approved deployment | Deploy or modify the approved artifacts only, in the documented sequence | Deployment command log with timestamp |
| 15 | Verify via message monitoring | Verify post-deployment state: check runtime status of deployed iFlows, inspect message monitoring for errors, confirm throughput resumes within expected parameters, verify downstream partner acknowledgements where applicable | Post-deployment message monitoring log and verification results |
| 16 | Audit | Produce complete audit record: all 17 steps, evidence, commands, timestamps, integration-owner approval | Audit record |
| 17 | Report | Deliver final report to requester, integration owner, and change manager | Report delivered and acknowledged |
