Handiling failure in complex Approval process

adam1

I'm designing the work flows to manage our content change process. Its a relatively basic process. The author completes his assigned tasks and the files attached to the workflow are copied to the QA workarea where the QA team approves the process.

The problem I am having is handling the failure conditions. If the QA person fails the changes, and those changes could include a number of files, I need to revert the QA envrionment to the condition it was in before the failed files where copied in.

There are complications.

1) There are going to be multiple simultaneous jobs which will be submitting files to QA. As I update the files from those jobs, they are going to become merged with files already in QA. If QA fails a job that shares files with other jobs that are ready for QA, the merge has to be undone.
-- I can solve this by forcing (anyone know how?) my QA people to QA one job at a time. Except that I have more than one QA person, and giving each their own work area is a problem. If each approves a different job that affect the same file, when those changes get merged, there is a potential for conflicts to occur and that should never happne.

2) we have a two step QA process. One is internal and the second is external where our clients have to review our changes. The problem is there exists a very real chance that some jobs will get held up either becuase they have forgotten them OR they actually want those changes to go out at a later date. I can't hold up other jobs waiting for this one to pass.

I'm at a loss. I want to avoid putting anything into staging that hasn't passed through our QA processes.

Any thoughts?
Adam van den Hoven

13adam13

I am not really clear on why you need to copy the files out of the workarea that the files were modified in. In our QA process, we simply unlock, and relock, the files that are submitted. This prevents the authors from making further changes to those files until we have QAed them.

As far as the conflict situation, we depend on TeamSite to help us with that. Before anyone on my QA team submits a file to the STAGING area, we do a 'Compare to Staging' check to make sure that there are no conflicts.

Finally, we do not actually submit anything until it has gotten final approval from our business leaders. If we discover somethign is wrong with the pages, we will either reject the task back to the Author to make the required changes (at which time the locks are changed back to that individual), or we make the 'Quick Changes', and then get the additional approval before hitting the Submit button and moving it to staging.

That having been said, I have an idea for how you can get some of the functionality that you are looking for.

1) With multiple jobs, if you want to force TeamSite to only enable on workflow at a time, I would set a value (true/false) in a flat file on the TeamSite server. When ever someone tries to start a job, the first thing that it would do is check this file to see if another is already being done. You caould make it very friendly and include in that file all the pertinant information about the task currently being performed. This way, if there are schedluing conflicts, it is easier to resolve.