We’re establishing governance practices for our Creatio 8.2 workflow management and I’m looking for community input on version control strategies. Our team has about 45 active business processes across sales, service, and operations. We’ve had a few incidents where process changes caused unexpected issues and we needed to rollback, but our current approach is manual and error-prone.
How are others handling process model versioning in Creatio? Are you using external version control systems, relying on Creatio’s built-in features, or some combination? What’s your rollback strategy when a process change goes wrong in production?
Dependencies are definitely the tricky part. We handle this by versioning the entire package, not just individual processes. When we create a process version in Git, we also export all related schema elements - entities, lookups, pages that the process touches. This creates larger version packages but ensures consistency. For rollback, we have a checklist that includes verifying dependency versions before rolling back the process. It’s more work upfront but prevents the nightmare scenario of rolling back a process only to find it references a lookup value that no longer exists.
We use a hybrid approach. Creatio’s built-in process versioning gives you basic history tracking, but it’s not sufficient for enterprise governance. We export process definitions as XML to a Git repository before any production deployment. Each commit includes the process name, version number, change description, and approver. This gives us full audit trail and the ability to diff changes. For rollback, we can re-import the previous XML version. It’s manual but controlled.
The key is having separate environments - dev, test, and production. Never edit processes directly in production. We maintain a deployment log spreadsheet tracking every process change with before/after versions. For rollback, Creatio lets you activate a previous process version from the version history, but this only works if you haven’t deleted old versions. Make sure your cleanup policies preserve at least the last 5 versions of each process. We learned this the hard way when we needed to rollback and the previous version was gone.
From a testing perspective, I’d add that your version control strategy should include test cases. We maintain a test suite for each major process version, stored alongside the process definition in Git. When we need to rollback, we re-run the test suite for that version to verify it still works in the current environment. This has caught several cases where rolling back the process alone wouldn’t have worked because the underlying data model had evolved.
Good points on the environment separation - we do have dev/test/prod but our deployment process between them is still pretty manual. Michelle, when you re-import XML, do you find that dependencies cause issues? We have processes that reference lookup tables, custom objects, and other processes. I’m worried about import failures if those dependencies have changed between versions.
Let me share our comprehensive governance framework that addresses all three areas you’re asking about.
Process Model Versioning:
We use a multi-layered versioning approach. First layer: Creatio’s native process versioning for quick rollback within the platform - we configure auto-versioning on every process save and retain 10 versions minimum. Second layer: Package-based versioning where we create Creatio packages for each major release cycle and version those packages using semantic versioning (major.minor.patch). Third layer: External Git repository where we export process XML definitions, related schema elements, and configuration files after each sprint. This gives us platform-native rollback for immediate issues, package-level deployment control for release management, and full source control history for long-term governance.
Rollback Strategies:
Our rollback playbook has three tiers based on severity. Tier 1 (immediate rollback): Use Creatio’s version history to activate the previous working version - takes 5 minutes, works for simple process logic issues. Tier 2 (package rollback): Uninstall the current package version and reinstall the previous package - takes 30 minutes, handles cases where multiple processes or schema changes are involved. Tier 3 (full environment restore): Restore from backup and replay transactions - takes 2-4 hours, reserved for catastrophic failures. We document which tier applies to each type of change in our change management procedures. Critical success factor: always test the rollback procedure in your test environment before deploying to production.
Backup and Restore:
For backup strategy, we run automated daily backups of the entire Creatio instance including database, file system, and configuration. Additionally, we take manual snapshots before any major process deployment. These snapshots include: full database backup, exported packages, process XML exports, and environment configuration files. We test restore procedures quarterly to ensure they actually work. For process-specific backup, we export the process definition and all dependencies (lookups, entities, business rules) to a deployment package before making changes. This creates a self-contained rollback unit.
Key lesson learned: version control isn’t just about the process definition - it’s about the entire deployment unit including dependencies, configuration, and test artifacts. Invest in automation for export/import workflows to reduce manual errors.