Yeah this was fun to explain to the Lawyers,

Lawyer: "So you can track versions, that will be useful when we draft up some documents..."

Me: "Yeah but it doesn't quite work how you think it would work..."

@Ian - The users can leave the Version comments blank until they are happy they have finished with the document so it would look something like this in the Version History.

@████████ I think the issue Ian is having is that the changes are being made in Workflow. If it were a user, they could have a little more control since they can decide at what points to save the changes, but in workflow it's saving each change as it goes.

Correct: and more than this, there does not appear to be a way to me create an entry in a separate place (without versioning) and then move it to replace the entry with versioning active and allow versioning to be useful for real changes.  If there is a way to do this, it would allow me to stop the extra copies from accumulating.

What do you mean? You could create the document, then once it is complete, turn the versioning on and move it where you want.

After it is created and "ready-to-go" you just use the Version Control activity to start tracking versions at that point and move it where you want.

If it is a new document, you shouldn't need to replace any existing entry.

Not that simple.  The problem is that generating a new version of a fillable PDF for an existing entry yields more than one new version; how can I do this without the new (null) versions added.

So if entry A is the version controlled target entry for a new version where I only one one new version to be created, I could create a new version of A in entry B without version control and then I could copy B to A and allow A to version control the replacement of the new document I am writing, and then delete B.  Or so I thought.  

I did not see a way to generate, in a separate entry, a new version of an existing  document and then copy that new document it to the target entry (which is version controlled) and have it all work out as I would like.  The versioning of the separate new entry is not what is required.  It is the historic versioning of the existing entry that needs to be preserved, while I add (by copying or other method) a new version to the entry.  Using attach to entry, followed by fill PDF did not accomplish the objective.

Perhaps I am missing something.

It's hard to say without knowing all the details of your process. If you're just replacing the PDF portion, then you could generate the updated PDF within a new entry.

Then get the electronic document from that new entry using Download Electronic Document and replace the one on the original document using Attach Electronic Document.

But even that could be considered two changes because your both deleting an electronic document and adding a new one, which is technically two changes and could be tracked that way by versioning.

The only other option, which I use, is to build an SDK Script in the workflow that makes all of the changes in one go and then saves at the end so it all counts as a single change.

To make it all one version through the SDK you would start by checking out the document, make all changes, then save once at the end and you end up with only one new version in the history.

What I'm unclear on is why you were using Create Entry if the process is designed to update an existing entry. Are you talking about taking a document you already had and then changing the PDF, or when you say "existing entry" are you talking about the one you created with Create Entry?

We are generating fillable PDF forms in an HR onboarding process where a user may "redo" the forms at any time in the process.  A redo would result in two versions of the same tax form (for example) when only the most recent is used.  This was an ideal case of document versioning because it came from one process that may be completed in a week or less and all documents apply to the same time period.  The forms is a fillable PDF.  Next year's tax form would NOT be a new version of this year's form because we want them both to be separate records one for each year.

What I found was when I used Create Entry with the option to use existing if it exists, I got intermediate versions that were unfilled versions of the PDF form.  The Create Entry (use existing) is exactly what I would need to replace or add a new version to the history of an existing document without me needing to program for a specific exception.  So I could use Find Entry to see if it exists and then add to it if it exists but I found that the empty PDF was created from the Attach activity that fetched the Workflow repository PDF template to be filled in, then when I filled it in, I got a new version with the filled-in PDF.  (What I said in the original post).  I realized that using versioning that yielded intermediate empty PDF forms would confuse the business stakeholders if they wanted to examine the version history for user "Redo" activity.

Our external database will show all submissions and record the "Redo" activity but the generated documents are part of the outcome that needs to align to the process step.  The result was I dropped use of document versioning when it could have applied very well and I now generate a new entry for every "Redo" activity.  The reason: because the activities used to generate a filled-in PDF cause a problem for document versioning and, as said in a previous post, that is because it is document versioning and the empty PDF is one version and the fill-in PDF is another version.

This led me to contemplate how else to add a new version to a PDF fillable form without getting an empty PDF version created.  I did not see a way to do this.

Like @████████ said, it was fun to explain to lawyers.  My users are not lawyers but I had the same concern about their confusion on empty PDF forms appearing in historical versions.

The problem is that attaching the "empty" PDF is a separate event/change because it is replacing the existing PDF with a new blank copy.

You're then filling in that PDF creating yet another version which is tracked as another change because they occur separately.

If you don't want that empty PDF in the version history, then you need to wait until you have a filled-in PDF before you update the existing document.

Stop retrieving the existing with "Create Entry" and always create a new and separate entry to work with, regardless of whether or not it's a "redo."

Then if you are in a "redo" scenario you retrieve the existing document afterward and replace the PDF with the already-completed one from the new document.

That way all those intermediate changes are only occurring on the "working" document and you're never adding a blank PDF to the existing document.

I contemplated this as well.  So I think you are saying use only a completed PDF in an Attach Document activity to the entry for which I want document versioning integrity.

I can generate the Redo copy separately without versioning active and then attach it to the "outcome" entry.  I will have to see what source location options are available for the Attach Electronic Document.  This might work.

Yup you got it!

You'll most likely still need to create a new entry to fill in the PDF, but the change would be that in a "redo" situation you would yank out the PDF, transfer it over, then dispose of the unneeded document afterward.

Here's a very basic example,

1. You create a new (and separate) entry no matter what
2. You add the PDF
3. You fill out the PDF
4. IF it is a Redo
   1. Download the PDF with the Create Entry output as your source
   2. Find your "existing" entry for the redo
   3. Attach the filled out PDF to the original (use the download activity as the source)
   4. Dispose of the "working" entry

The end result is only one tracked change on the original document because you did all the intermediate changes on the other entry and just added a "finished" PDF.

Why would I not make the first generation of a PDF the same as any later generation.  If there is not entry when I do this then it is created with versioning?

Which document needs to be downloaded?  Why is the filled-in PDF not accessible without downloading it?