Word 2010 has a Document Information Panel "InfoPath Form" that displays a basic set of seven default document properties...Author, Title, Subject, Keywords, Category, Status and Comments. However, if the Word Doc is in Sharepoint, you can, through a bewildering set of arcane steps, rename six of the seven document properties and then if you create a set of seven lists, and create matching columns in your sharepoint document library, and point the colums to the lists, you can get most of these document property fields in Word to have dropdown menus, allowing point and click assignment of metadata to a word.doc. But you can't get rid of, nor re-purpose, the Title document property, and you can't add other properties. Well, actually, you can add others, but they won't work. Except, you may be able to do this if you buy InfoPath editing program for $250 and spend a couple of weeks figuring out how THAT works. This appears, from what I read on the Internet, to also allow you to create more document property fields, through another arcane series of unfathomable steps. This might all be true, but to any user trying to do ACTUAL WORK with Word and Sharepoint, docoument metadata fields are 'controlled' by a bewildering chaos of hidden tinker-toy controls and restrictions scattered in all different locations throughout Word and Sharepoint, and any documentation found, is written in MicrosftSpeak with few, if any, examples or links to control locations discussed in the help. What makes this crazy is, the tagging of documents with metadata is no secret process that Microsoft's Camel Design committees need to invent from scratch, duct-taped and wired together among junk-heaps of code and marketed as a 'feature' like lipstick on a pig. It's something that has been understood and programmed expertly by thousands of document management software program writers, for over two decades. It seems as though Microsoft alone insists on organizing, programming and presenting these capabilities in the most un-user friendly way possible. A family of Microsoft word processing software products for creating web, email, and print documents. Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question. I don't use Sharepoint so I have no idea how it relates to Word's document properties, but you may find http://www.gmayor.com/BookmarkandVariableEditor.htm useful as it provides ease of access to all the document properties, both built-in and custom and allows the editing of all those that are editable and provides the option to create others. It does much the same for document variables, bookmarks and content controls also. 7 additional answers Deleted This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information. Comments have been turned off. Learn more This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information. Comments have been turned off. Learn more Anonymous 2011-05-31T12:35:34+00:00 Thanks, Peter; great insights. Much to consider and learn! 0 comments No comments Thanks, Peter; great insights. Much to consider and learn! Anonymous 2011-05-31T12:34:24+00:00 As always, Graham and Greg, you are an awesome team. Thanks for the add-in info! 0 comments No comments As always, Graham and Greg, you are an awesome team. Thanks for the add-in info! Anonymous 2011-05-30T09:58:19+00:00 "Understand" Microsoft's approach? Well, I cannot say that I do, but maybe the following will help. << and you can't add other properties. Well, actually, you can add others, but they won't work. Except, you may be able to do this if you buy InfoPath editing program for $250 and spend a couple of weeks figuring out how THAT works. >> You can add other properties. They do work. You don't need InfoPath to do it, unless you really need to create a /custom/ DIP for display/modification of the properties in Word. In fact, it's so easy to create a new property in Sharepoint and use it in Word that I can't really work out what you're missing. e.g. - precisely how to do the following depends on which version of Sharepoint you are using, and whether or not you are using Sharepoint Designer 2010 (for example), but... create a new Sharepoint document library called "mylib1" create a new column in that library called "mycol1" - let's say a "1-line text" create a new document in the library edit the properties of the document and set the value of mycol1 to "abc" open the document in Word in Word 2010 click File->Info->Show All Properties (or enable the DIP and ensure that you are seeing the DIP that shows "Document Properties - Server". You should see "mycol1" in there, with "abc". You should also be able to insert a Document Property called "mycol1" from Insert->Quick Parts->Document Property. This will be a Content Control whose content should synchronise automatically with the field in the DIP. Change the value "abc" in the DIP or the content control to "def", click somewhere else to check that it is synchronising with the content control/DIP and save the document back to the Sharepoint Document Library, then go and check the value of the property. If you can follow that - and I appreciate it's not a detailed step-by-step - you should be able to see that it is possible to create new properties and that they "work." Some builtin Sharepoint property types won't work properly in Word - e.g. you don't get a free insertable Document Property when you define a Property with type Hyperlink, but many do - single line, multiline, some of the multichoice ones. However, if that's how you actually created all your Document Properties, you definitely would end up with an unusable mess, and that's where you need more info. on Sharepoint than I can provide. For example, if you create a second library called mylib2, and create a column called mycol1, and copy the document you created from mylib1 to mylib2, I /think/ (I haven't checked) you will see that the two mycol1 values are actually different. They are, in effect, in different namespaces. Sharepoint automatically creates CLSIDs that distinguish one such "namespace" from another. You can see that if you go through the standard process of a. renaming your .docx to a .zip b. open the .zip c. look at the xml files docProps/custom.xml and the various files in the customXml folder I would assume that the key to using SharePoint effectively is to understand how it uses these namespaces (which AFAIK are either the same thing that SharePoint describes as "Content Types", or very closely related) and to set out to define and deploy the Content Types that you need rather than using the ad-hoc approach I described above. As for what you do with the various other types of Property in Word (e.g. the "Built-in" types such as Author etc.), again, I do not know enough about real-world Sharepoint use to help you there. All I would suggest is that the old Word "Custom Document Properties" (now called "Advanced Properties") are to all intents and purposes dead as far as Sharepoint is concerned (although, funnily enough, Sharepoint uses a couple of them to record Content Type info). Because built-in properties such as Author etc. are stored differently in Word documents I suppose I would probably try to steer away from using them, but since we're talking about properties such as "Dublin Core" stuff, I suspect that may not be achievable. 0 comments No comments "Understand" Microsoft's approach?

Well, I cannot say that I do, but maybe the following will help. and you can't add other properties. Well, actually, you can add others, but they won't work. Except, you may be able to do this if you buy InfoPath editing program for $250 and spend a couple of weeks figuring out how THAT works. You can add other properties. They do work. You don't need InfoPath to do it, unless you really need to create a /custom/ DIP for display/modification of the properties in Word. In fact, it's so easy to create a new property in Sharepoint and use it in Word that I can't really work out what you're missing. e.g. - precisely how to do the following depends on which version of Sharepoint you are using, and whether or not you are using Sharepoint Designer 2010 (for example), but... create a new Sharepoint document library called "mylib1" create a new column in that library called "mycol1" - let's say a "1-line text" create a new document in the library edit the properties of the document and set the value of mycol1 to "abc" open the document in Word in Word 2010 click File->Info->Show All Properties (or enable the DIP and ensure that you are seeing the DIP that shows "Document Properties - Server". You should see "mycol1" in there, with "abc". You should also be able to insert a Document Property called "mycol1" from Insert->Quick Parts->Document Property. This will be a Content Control whose content should synchronise automatically with the field in the DIP. Change the value "abc" in the DIP or the content control to "def", click somewhere else to check that it is synchronising with the content control/DIP and save the document back to the Sharepoint Document Library, then go and check the value of the property. If you can follow that - and I appreciate it's not a detailed step-by-step - you should be able to see that it is possible to create new properties and that they "work." Some builtin Sharepoint property types won't work properly in Word - e.g. you don't get a free insertable Document Property when you define a Property with type Hyperlink, but many do - single line, multiline, some of the multichoice ones. However, if that's how you actually created all your Document Properties, you definitely would end up with an unusable mess, and that's where you need more info. on Sharepoint than I can provide. For example, if you create a second library called mylib2, and create a column called mycol1, and copy the document you created from mylib1 to mylib2, I /think/ (I haven't checked) you will see that the two mycol1 values are actually different. They are, in effect, in different namespaces. Sharepoint automatically creates CLSIDs that distinguish one such "namespace" from another. You can see that if you go through the standard process of a. renaming your .docx to a .zip b. open the .zip c. look at the xml files docProps/custom.xml and the various files in the customXml folder I would assume that the key to using SharePoint effectively is to understand how it uses these namespaces (which AFAIK are either the same thing that SharePoint describes as "Content Types", or very closely related) and to set out to define and deploy the Content Types that you need rather than using the ad-hoc approach I described above. As for what you do with the various other types of Property in Word (e.g. the "Built-in" types such as Author etc.), again, I do not know enough about real-world Sharepoint use to help you there. All I would suggest is that the old Word "Custom Document Properties" (now called "Advanced Properties") are to all intents and purposes dead as far as Sharepoint is concerned (although, funnily enough, Sharepoint uses a couple of them to record Content Type info). Because built-in properties such as Author etc. are stored differently in Word documents I suppose I would probably try to steer away from using them, but since we're talking about properties such as "Dublin Core" stuff, I suspect that may not be achievable.