When introducing a new approval rule, the question is not just how new cases will start, but also what happens to those already in progress. The effective date alone does not determine how to handle previous decisions and assigned tasks.
Using a procurement example, we explain the criteria for choosing whether to complete cases under the old rules, migrate them or restart them, and what needs to be clarified for a safe transition.
A new threshold from Monday—three cases still pending under the old rules
Consider an illustrative example: from Monday, a company will require a second approver for internal purchase requests only above 1 million forints, rather than 500 thousand. The new rule seems straightforward. But several requests are still in progress on Friday afternoon, and on Monday someone will have to decide how they should proceed.
Same amount, different case statuses
Let us follow three requests, each for 750 thousand forints:
The first is still awaiting initial approval.
The second has already received initial approval and is on the second approver’s task list.
The third was rejected, but is due to be amended and resubmitted.
The amount is the same, but the histories differ. Different decisions are needed for a step not yet completed, a task already assigned and a request resubmitted after rejection.
What the effective date does not resolve
“Effective from Monday” alone does not specify which requests the new rules apply to. Alongside the date, you need a classification rule and a transition procedure. Without these, the buyer, the approver and the IT team may all interpret the same situation differently.
First, define which rules apply to which cases
What determines the rule version for a case?
When a rule takes effect is a business or regulatory matter; deploying the workflow to production is a technical implementation event. The two must be aligned. If the new rules apply from midnight on Monday but the system is not updated until later that morning, handling the intervening period must also be defined in advance.
Classification may be based on the time of submission, acceptance for processing or decision, or on a specific case status. These are not interchangeable: a request submitted on Friday and accepted for processing on Monday may fall into a different group depending on the criterion chosen. The precise cutoff and the point at which status is assessed must also be defined.
What happens when a request is amended or resubmitted?
For our third sample request, one point needs clarification: does the amendment continue the same case, or start a new procedure? Changes to the amount, the subject of the purchase or the cost center may warrant a new check. The rule version applicable to resubmissions should therefore be specified separately.
Mandatory legal or internal requirements may limit the available transition options. These should be checked before making a choice; the framework presented here is not a universally applicable legal answer.
Complete under the old rules, migrate or restart?
When is completion under the old rules appropriate?
With this approach, designated cases are completed under the previous approval rules. This may be appropriate if they are already close to completion and continued use of the old rules is permitted. The benefit is continuity, but the burden is maintaining two operating models in parallel: the old roles and checks must also remain available.
What conditions make migration safe?
With migration, the request continues under the new rules. This requires mapping the old process states to the new ones: for example, what does “awaiting second approval” mean in the new process? A case should only be migrated if the validity of previous steps and the next action are clear.
When is a restart justified?
A restart is justified if the required checks cannot be reliably carried forward, or if the request has changed significantly. Restarting the procedure must not, however, erase its history. Repeated work, new notifications and longer turnaround times must also be taken into account.
Criterion | Completion under old rules | Migration | Restart |
|---|---|---|---|
Applicability | The old rules may still be applied. | The process states can be mapped. | A new procedure is required. |
Previous decisions | They count under the old rules. | Their validity must be checked. | They remain on record; whether to use them is a separate decision. |
Workload | Maintaining parallel operations. | One-time transition and task reconciliation. | Repeat processing. |
Main risk | Prolonged operation under two sets of rules. | Incorrect state mapping. | Duplication and delays. |
Required checks | Tracking legacy cases and those responsible for them. | Checking decisions, tasks, and the target state. | Reviewing links to prior records and repeated steps. |
Not all ongoing cases need to be handled in the same way. If the classification rule and applicable requirements allow it, the first sample request can continue under the new rules with a single approval. For the second, this also requires determining whether the existing approval is acceptable and what happens to the second task already assigned; if it is completed under the old rules, however, the second approval remains required. For the third, the first decision is whether the amended submission is a continuation or a new procedure. In every case, different treatment must be based on consistent, documented classification.
Previous decisions and assigned tasks must be addressed separately
Does the approval remain valid, need to be repeated, or become unnecessary?
Our second sample request is already waiting with the second approver. If we transition it to the new rules, this step may become unnecessary based on the amount. First, however, we must check whether the content covered by the first approval has remained unchanged and whether that approval is also acceptable under the new rules.
In consultation with the compliance owner, the process owner determines who is authorized to decide whether previous decisions can be accepted or must be repeated. The record of those decisions must be retained even if the step in question is no longer required. The new threshold does not turn a previous rejection into an approval.
Do not leave tasks unowned or running in parallel
It is not enough to ignore a second approval task that has become redundant. It must be withdrawn or closed in a controlled manner, with an appropriate reason, without marking the approval as completed. The assignee must be notified, and reminders, substitutions, and escalations must also be addressed. The requester must receive clear information about the next step.
The transition also needs a process and an owner
From compiling the case list to a verified transition
Handling ongoing cases should be a separately planned workflow, not a one-off, uncontrolled bulk update:
Identify the affected cases and their open tasks.
Group them according to the approved criteria.
Obtain approval for each group's transition decision.
Implement the changes and send the notifications.
Verify the results and route exceptions to a designated owner.
The case list must be refreshed before implementation, as case states and open tasks may have changed in the meantime. However, this does not mean automatic reclassification: if classification is based on the state at a fixed point in time, that remains the determining factor. Any changes must be reviewed to establish whether the approved transition decision can still be implemented or requires reconsideration.
Who decides, who implements, and what remains traceable?
The process owner decides how operations should work, the compliance owner checks compliance, and the technical team implements the approved change. The person carrying out the technical implementation should not be forced to make a business decision on an ambiguous case.
For each case, the applicable rule version, the transition decision, its rationale, its date and time, and the person responsible must remain traceable. In xFLOWer's approach to process modeling, not only the new approval path but also the transition leading to it must be modeled: with branches, designated owners, and checkpoints.
What needs to be tested before Monday's launch?
Edge cases and actions during the transition
Testing should involve more than running a new request through the process. At a minimum, test the following cases:
Requests submitted immediately before and after the new rules take effect.
An amount of exactly 1 million forints: the example says “exceeds,” not “reaches.”
A partially approved case with the second task already assigned.
Approval granted by a designated substitute.
A request revised and resubmitted after rejection.
Examine separately what happens if someone completes a previously assigned task during the transition itself. Define in advance how to avoid conflicts and how to handle a case status that changes in the meantime.
Checkpoints and error handling
After migration, every affected case must be easy to find, have the correct status, and have a clear next step. No duplicate tasks should be created, and no active reminders should remain for a revoked approval.
Designate a decision-maker and establish a procedure in advance for stopping a faulty migration and isolating and resolving affected cases. A simple technical rollback is not always sufficient: new decisions, notifications, or external actions may have occurred in the meantime.
The transition does not end at go-live
What should you monitor in the first few days?
Use a short, regularly reviewed list to track the number of cases remaining on the old version, stalled tasks, exceptions, and turnaround times. Assign an owner and a resolution deadline to every deviation. The aim is not merely to count errors, but to verify that case processing can actually continue.
When can the transition be considered complete?
When every affected case has been accounted for, exceptions have been handled, and the previous way of working no longer requires active support. Case histories must remain retrievable afterwards. A well-managed process change clarifies the path not only for new cases, but also for those already in progress.
Planning to change your approval procedures? Consult the xFLOWer team on how to plan for the new rule and ongoing cases to coexist.
