Content Versioning in Workflow

Hi,

I was wondering if TeamSite tracks the changes made by each user to content during the course of a workflow.

Thanks so much!

Find more posts tagged with

Comments

moonkhanna

what is your business usage?

GroupPageNumbering.rptdesign

vtwadhwani

The business would like to have a log/history of changes made to the content by each user in the workflow.

nipper

There seems to be a disconnect on the WF and the usage. In practice, I seldom see files changed during a workflow.It is the exception rather than the rule.

If the file changes 100 times in 1 workflow, then the changes will all be lumped together. If it is changed over a period of time in 100 workflows, then the reasons for changing it (as well as approval comments) will be kept in the WF.

Ambuj

The business would like to have a log/history of changes made to the content by each user in the workflow.

How do you manage so many users in a single workflow?

I mean, can you provide a little details on your requirement as what do you want to achieve?

Sailesh

Hi,

I was wondering if TeamSite tracks the changes made by each user to content during the course of a workflow.

Thanks so much!

You can keep submitting the work after each user modification, that would generate versions for you to track later, down side is if there are number of review and reject then your version history will keep on increasing.

application_session_integrationBF.zip

Adam Stoller

Hi,

I was wondering if TeamSite tracks the changes made by each user to content during the course of a workflow.

Thanks so much!

If you need to do this - then you probably need a multiple-branch model to support the separation of "work-in-progress" from "ready-for-production".

Essentially you have (at least) two branches - the first branch is where all the content creation / changes originate and where most of the workflow tasks operate. After each task in which a file could change on the first branch, you would need to have a submittask (or equivalent) to submit / version those files - you may want something more formal that requires comments be provided to explain the modifications which were made, but that's all part of getting the requirements and doing the design and eventually implementation work. Once you get past the [final] review stage, you would use an updatetask (or equivalent) to transfer the approved files to the second branch - then you would have a submittask (or equivalent) running against the workarea in the second branch to submit the file(s) there.

Your first branch will have a record of all the individual changes that occur to a file in between releases to production.

Your second branch will have only the versions that have been released to production without all the intermediary modifications.

You could do all this in one branch - but I wouldn't recommend it.

application_session_integrationBF.zip