The Deployment That Broke a Process
A team deploys an application from a development environment to production using an application package. The package includes a process model, a record type, and an integration. After deployment, running process instances that were mid-flight in production fail at a node that calls the integration. Investigation shows the integration's endpoint URL was changed in development to point at a new test server before packaging, and the package carried that value into production. Separately, the record type's data store was configured in development to point at a development database, and the production deployment now queries the wrong database. The team has no documented environment-specific configuration list.
1. What is the root cause pattern here, and how should environment-specific values be handled so packages don't carry them?
Read the worked answer
The root cause is that environment-specific configuration was stored in the same objects that get packaged, so development values traveled with the deployment. Two separate instances of the same mistake: the integration URL and the data store connection.
The fix is to separate what is deployed from what is configured per environment:
- Integration endpoints, base URLs, and credentials should be externalized to environment-level configuration (e.g., a configuration record or environment variables) that is set per environment and not overwritten by the package.
- Data store connections should be defined per environment, with the package carrying the data store definition but not the development connection string.
- Maintain a written environment configuration checklist listing every value that differs between dev, test, and production, and require it to be reviewed at deployment.
The package should be environment-agnostic; if a value differs by environment, it does not belong inside the packaged object.
2. Why did mid-flight process instances fail, and what does that imply about deploying process model changes?
Read the worked answer
Running instances execute against the currently deployed process model definition. When the new version was deployed, in-flight instances encountered a node whose integration now pointed at a test server - so the node ran, but against the wrong endpoint, and failed.
Implications:
- Deploying a process model change affects live instances, not just new ones. Changes to nodes that running instances will still traverse are risky.
- Before deploying, identify in-flight instances and which nodes they will hit. If a node's behavior changes incompatibly, either let instances drain, migrate them, or version the process so old instances finish on the old definition.
- The integration URL change should never have reached production at all (see prior task), but the process-model deployment amplified its impact.
The lesson: process model deployment is not a safe no-op for running work. It must be planned against live instance state.
3. What should the team add to their deployment process to prevent recurrence?
Read the worked answer
A deployment gate with three checks:
- Configuration diff review: before packaging, diff every environment-specific value (integration URLs, data store connections, credentials, feature flags) against the production baseline. Any dev/test value present is a blocker.
- In-flight instance impact assessment: list running instances and the nodes they will traverse; flag any changed node they will hit.
- Post-deploy smoke test: immediately after deployment, run a synthetic case through the integration node and query the record type to confirm it reads from the production database - before declaring success.
Also maintain the environment configuration checklist that was missing. The absence of that list is why the same class of error happened twice; the checklist converts tribal knowledge into a repeatable control. Prevention here is procedural, not technical - no platform feature stops a developer from packaging a test URL.