Assuming your Approved status is the End step of the workflow, my understanding is that once the End step or Terminal status is reached, the workflow is complete and the status cannot be changed, even to Terminated status. This too is a concern of mine: what to do with records that user's have approved (or whatever the End step may be) that they should not have. The End step does allow the Record Editor to edit some fields (not Status), so if the approval is invalid, we can annotate the record.
Now I'm cloud user but consult what we have of an ERD to attempt to create decent reports from Unifier, so perhaps you could make the correction in the backend if you understand the structure.
You cannot terminate a record if it has reached the End step. There are two rules to Terminal status:
- Any line or elbow that routes a record to the End step must have a Terminal status assigned to it, and;
- Whenever a record reaches a Terminal status, the status can never change
If you combine thoise two things, that tells you that a record that has reached terminal status can be routed further, but it will always have the same status (for example, Approved). Terminating a record gives it a new status (Terminated) which is not allowed. The only thing that can be edited are designated fields on the upper form, or those upper form fields identified in integration can be bulk edited. Unfortunately, status is always added via routing on a workflow BP and cannot be edited.
What you can do is issue a modifying change order to the contract.
To follow on to Sean's response, I have a couple comments:
1. While "Unapproving" or "Deleting" of records may be acceptable in other software (including, for example, Primavera Contract Management), it is generally not a good business practice, and can result in missing data within your record set. It is for this reason that Unifier has the prohibition to changes to terminal status documents. While feasible that Unifier could contain code that would provide the means to undo and document an incorrect terminal status document, I would agree with Sean that the best way to handle this would be to create a deductive change that undoes the transaction, which would give you ample room to document what happened. This is not much different from accounting systems that create Journal entries to correct postings done in error.
2. If this kind of event occurs more than once or twice, I would suggest that consistent process training is in order as a way to minimize these things happening (i.e. those that are trigger happy)
3. This could likely be a condition that needs to be specifically addressed in training sessions for companies used to other software that allow the changes; otherwise, I'll just expect that I could do like I've done before.