A workflow editor makes changes look easy: add a step and publish. The hard question is what happens to requests already halfway through the old process. Version the definition and make the transition policy explicit.
Related service: Custom software development- 01Draft and validate the new definition.
- 02Identify affected active cases.
- 03Choose continue or migrate rules.
- 04Publish for the intended new work.
- 05Monitor exceptions and preserve prior history.
SECTION 01
Separate the template from each running case
A workflow definition describes steps, transitions and allowed actors. A running case records the actual decisions for one request. Keep a stable version reference between them. Otherwise a new required field or approval stage can make yesterday's completed request appear incomplete without any business event.
Define what the editor may change and who can publish. Validate unreachable steps, missing decision owners and transitions with no exit. Database references can preserve the version relationship; authorization controls determine who may activate it. A general-purpose visual rules engine may be unnecessary if the business only needs a few maintained workflows.
SECTION 02
Illustrative example: adding a second review
Suppose equipment requests currently need one manager's approval. The business adds a facilities review for future requests. Some cases are already approved, while others await the manager. This is a hypothetical workflow change, not advice about an organization's approval policy.
One defensible rule is to let existing cases finish under version one and start new requests under version two. Another is a reviewed migration of selected open cases. Either choice should explain what happens to prior decisions and notify affected owners. Do not silently insert a step into completed history or copy an old approval to a new decision it never covered.
SECTION 03
Test changes with representative in-flight cases
Start with explicit versions and a small set of supported edits. Existing workflow products may already handle publication and running instances; verify their migration behavior before writing custom logic. Flexibility increases testing and support work, so price the allowed changes rather than an unlimited promise to configure anything.
Ask the agency to test cases at every meaningful stage, a withdrawn definition, a missing approver and a migration that cannot complete. Keep the previous definition readable after publication. A reversal of the new workflow should not erase work performed under it. The handoff needs version history, publishing rights and a practical process for reviewing the next change.
SECTION 04
Frequently asked questions
Should active requests always use the newest workflow?
Not automatically. Decide whether they finish under their existing version or undergo a controlled migration with explicit treatment of prior decisions.
Can a published workflow be deleted?
Preserve definitions referenced by historical or active cases. Retirement from new use is different from deleting the meaning of existing records.
Do we need a visual workflow builder?
Only if its flexibility solves a real operating need. A few well-defined workflows may be simpler and more reliable to maintain.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Database constraintsPostgreSQL
- Authorization guidanceOWASP Foundation
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy