Auto-incrementing in-Word-document version number from template across multiple SP online sites

%3CLINGO-SUB%20id%3D%22lingo-sub-1155974%22%20slang%3D%22en-US%22%3EAuto-incrementing%20in-Word-document%20version%20number%20from%20template%20across%20multiple%20SP%20online%20sites%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1155974%22%20slang%3D%22en-US%22%3E%3CP%3EHi%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI've%20been%20looking%20at%20this%20for%20some%20time%20now%20but%20cannot%20find%20a%20solution.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20can%20solve%20the%20first%20part%20of%20the%20issue%20-%20embedding%20a%20version%20number%20field%20into%20a%20Word%20document%20template%20which%20will%20automatically%20keep%20in%20sync%20with%20the%20checked-in%20version%20number%20when%20a%20document%20created%20from%20that%20the%20template%20is%20stored%20in%20the%20Sharepoint%20document%20library.%20The%20most%20straight-forward%20way%20seems%20to%20be%20to%20create%20a%20label%20in%20the%20Sharepoint%20document%20library%20against%20the%20'Document'%20type.%20That%20label%20shows%20the%20value%20in%20the%20included-as-standard%20Version%20field%20via%20%7BVersion%7D.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EProvided%20the%20template%20is%20created%20within%20same%20Sharepoint%20library%20that%20any%20documents%20generated%20from%20that%20template%20are%20stored%20in%2C%20then%20Happy%20Days%20-%20it%20all%20works%20and%20generated%20.docx%20documents%20do%20pick%20up%20automatically%20incrementing%20Version%20fields%20via%20the%20label%20which%20got%20embedded%20into%20the%20.dotx%20template%20file.%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWhere%20it%20falls%20down%20is%20if%20a%20document%20created%20with%20that%20initial%20template%20is%20stored%20in%20a%20different%20Document%20Library%2C%20or%20tenant%20site%20-%20even%20if%20that%20new%20destination%20also%20has%20a%20version%20label%20created%20in%20exactly%20the%20same%20way%20as%20the%20original%20Library%20had.%20I%20suspect%20that%20behind%20the%20scenes%2C%20Sharepoint%20is%20using%20GUIDs%20to%20manage%20these%20references%20(keeping%20the%20friendly%2C%20matching%20column%20names%20for%20human%20consumption)%2C%20and%20that%20a%20label%20or%20field%20is%20in%20fact%20uniquely%20identified%20across%20the%20entire%20tenant%20site%20collection.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20challenge%20is%20that%20our%20processes%20involve%20the%20creation%20of%20'standard'%20Sharepoint%20sites%20on%20a%20project-by-project%20basis.%20Each%20project%20will%20create%20its%20own%20set%20of%20documentation%20and%20store%20that%20in%20the%20document%20library%20of%20the%20Sharepoint%20site%20which%20was%20created%20for%20it.%20We%20use%20a%20set%20of%20standard%20document%20templates%20which%20are%20picked%20up%20from%20a%20central%20location.%20I%20need%20to%20be%20able%20to%20equip%20these%20centrally-held%20document%20template%20files%20(.dotx)%20with%20embedded%20version%20metadata%20which%20will%20automatically%20reflect%20the%20incrementing%20version%20number%20which%20the%20generated%20document%20is%20assigned%20within%20its%20(revisioning-enabled)%20Sharepoint%20document%20library%20through%20the%20check-in%20process.%3C%2FP%3E%3CP%3EThe%20overhead%20involved%20in%20re-specifying%20the%20version-number-references%20in%20every%20template%20to%20reflect%20the%20new%20document%20library's%20label%20GUID%20every%20time%20a%20new%20project-Sharepoint-site%20is%20created%20is%20not%20workable.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ECan%20anyone%20advise%20on%20how%20to%20do%20this%20please%3F%26nbsp%3BWe%20use%20Sharepoint%20online%2C%20rather%20than%20a%20locally-hosted%20installation%2C%20incedentally.%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EManaged%20Metadata%20columns%20defined%20at%20the%20'root'%20tenant%20level%20looked%20promising%20initially%2C%20but%20it%20seems%20that%20these%20can%20only%20store%20static%20data%20-%20intended%20to%20be%20referenced%20by%20lookups%20etc%20-%20so%20can't%20help.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EOther%20suggestions%20surround%20creating%20Visual%20Studio%20Add-Ins%20or%20Apps%20and%20uploading%20them%20but%3A%3C%2FP%3E%3CP%3EA)%20I'm%20not%20sure%20on%20exactly%20what%20we%20need%20to%20create%20as%20there%20doesn't%20seem%20to%20be%20anything%20which%20speaks%20to%20our%20specific%20scenario%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3Band%3C%2FP%3E%3CP%3EB)%20I'm%20concerned%20that%20if%20we%20did%20that%2C%20we%20would%20be%20back%20to%20square%20one%20by%20dint%20of%20these%20unique%20GUIDs%20across%20different%20tenant%20sites%20or%20document%20libraries.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EInput%20would%20be%20great%20appreciated!%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThanks!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1155974%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EDocument%20Library%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3ESharePoint%20Online%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E
Visitor

Hi,

 

I've been looking at this for some time now but cannot find a solution.

 

I can solve the first part of the issue - embedding a version number field into a Word document template which will automatically keep in sync with the checked-in version number when a document created from that the template is stored in the Sharepoint document library. The most straight-forward way seems to be to create a label in the Sharepoint document library against the 'Document' type. That label shows the value in the included-as-standard Version field via {Version}.

 

Provided the template is created within same Sharepoint library that any documents generated from that template are stored in, then Happy Days - it all works and generated .docx documents do pick up automatically incrementing Version fields via the label which got embedded into the .dotx template file. 

 

Where it falls down is if a document created with that initial template is stored in a different Document Library, or tenant site - even if that new destination also has a version label created in exactly the same way as the original Library had. I suspect that behind the scenes, Sharepoint is using GUIDs to manage these references (keeping the friendly, matching column names for human consumption), and that a label or field is in fact uniquely identified across the entire tenant site collection.

 

The challenge is that our processes involve the creation of 'standard' Sharepoint sites on a project-by-project basis. Each project will create its own set of documentation and store that in the document library of the Sharepoint site which was created for it. We use a set of standard document templates which are picked up from a central location. I need to be able to equip these centrally-held document template files (.dotx) with embedded version metadata which will automatically reflect the incrementing version number which the generated document is assigned within its (revisioning-enabled) Sharepoint document library through the check-in process.

The overhead involved in re-specifying the version-number-references in every template to reflect the new document library's label GUID every time a new project-Sharepoint-site is created is not workable.

 

Can anyone advise on how to do this please? We use Sharepoint online, rather than a locally-hosted installation, incedentally. 

 

Managed Metadata columns defined at the 'root' tenant level looked promising initially, but it seems that these can only store static data - intended to be referenced by lookups etc - so can't help.

 

Other suggestions surround creating Visual Studio Add-Ins or Apps and uploading them but:

A) I'm not sure on exactly what we need to create as there doesn't seem to be anything which speaks to our specific scenario     and

B) I'm concerned that if we did that, we would be back to square one by dint of these unique GUIDs across different tenant sites or document libraries.

 

Input would be great appreciated!

 

Thanks!

1 Reply