Promoting 40 CAI processes across Dev, Test, and Production
A large enterprise has 40 CAI processes and 25 connections spread across Development, Test, and Production. Three delivery teams promote changes manually by exporting and importing; connection passwords are often pasted into chat. Last month a developer changed a shared Salesforce connection in Test to point at the production URL, and test orders appeared in the production CRM. Six processes still contain hard-coded SAP endpoint URLs. Production has a change freeze every quarter-end, and the audit team requires evidence that the tested version is the version deployed. The platform team wants a repeatable promotion path without duplicating process logic in every environment. There is no automated regression suite yet, and the teams use a shared Git repository only for documentation.
1. Design the environment and connection configuration so the same process logic can run in Dev, Test, and Prod without hard-coded endpoints.
Read the worked answer
Create separate connections per environment and per runtime location, and make the process reference the connection, not a URL. Externalize endpoint, credentials, timeouts, and environment-specific identifiers as connection properties; where CAI supports parameterized connection properties, bind them to environment-level values rather than editing process logic. The same process package should be promoted unchanged; only the connection property set differs.
Remove the six hard-coded SAP URLs and replace them with a SAP connection selected by environment. Do not share one Salesforce connection between Test and Prod; that is what allowed a Test change to hit the production CRM. Use distinct service accounts and sandbox endpoints in Dev and Test. Keep connection names stable across environments, for example SAP_ORDER, so promotion does not require process edits, but resolve the name to different values per environment. Document which connections are agent-bound versus cloud-bound so a promotion does not silently change runtime location.
2. Define the promotion workflow and dependency order from Dev to Prod, including the controls that prevent test traffic from reaching production.
Read the worked answer
Promote in dependency order: connection property sets and connections, then reusable process objects and schemas, then subprocesses, then parent processes, then schedules, event subscriptions, and gateway endpoints. Export from Dev as a versioned package, import to Test, run smoke tests and a regression subset, then promote the same artifact to Prod; do not rebuild from source at each stage.
Use a deployment checklist and an approval gate; Production should receive only the tested version. Prevent test traffic from reaching Prod with separate credentials, endpoint allowlists, and environment-specific connection properties; add a startup validation that refuses to run if a Test process resolves to a Prod host. Use a run-time environment flag in the payload or process for non-production smoke tests, but never rely on that flag alone for safety. For the quarter-end freeze, stage the promotion before the freeze, obtain sign-off, and deploy only emergency fixes under the freeze exception process.
3. What evidence and rollback plan should the team prepare for the audit team and the quarter-end freeze?
Read the worked answer
Keep an immutable promotion record: source version, package hash, Test results, approver, deployment timestamp, and the exact connection property set used, with secrets redacted. That is the evidence that the tested version is the deployed version. Tag the Git repository with the same version as the package, even if Git currently holds only documentation; the package hash is the authoritative artifact.
For rollback, export the current Prod package and connection property set before deployment, verify that the previous version can be re-imported and that its dependencies still exist, and define a rollback owner and time limit. Test rollback in Test, not during the freeze. Because there is no automated regression suite yet, define a minimal smoke set, such as one order, one approval, and one SAP read, and record its results. Schedule the promotion so it does not overlap the freeze, and require a named business approver for any emergency change.