If i create lookup column which in my case returns a meeting type (“Tourism”. “Planning” etc.) from a list in sharepoint it works fine until I try to inset that column as a document property (using quick parts) in Word 2016. All other columns work correctly displaying their value as document property fields except the lookup column which returns the index number (as digit) of the item chosen rather than the value (text) that the column shows. i.e. if the user choses the 3rd item from the lookup, the name of that meeting correctly display in the document library column but appears as “3” when embed into the associated word document. Oddly when looking a the info panel in Word, and clicks more info – a box pops up which displays the value from the column (i.e. the meeting title in our case) but when you return to word it still shows the index number of the item . This is reproducible.
I’d tried creating another calculated column which was simply set as = to the lookup column – but it appears a calculation based n a lookup column is not allowed (it doesn’t appear as a choice when building the formula).
Incidentally, replacing the lookup with a choice that returns the meeting name works fine – a choice column embedded in Word as a document part works fine (returning the value shown in the column).
Problem with this approach is
- meeting names are used in several list and libraries and it is important to have consistent usage (i.e. the same names) and to be easy to add a new one – a list as the source of the lookups makes this easy.
- There is other data about each item looked up that is useful (e.. chair of meeting. clerk to meeting, parent committee) – that is only available when the item is a lookup (choice is single array).
- Any ways around this? Fixes? MS accept that it is a problem but say they have no plans to fix it as we aren’t important enough (OK – they didn’t quite say the last bit like that – but it’s the gist)
I know the struggle. You could use the Choice field and use “Allow Fill in Choices”. This would allow your users to add new choices when they are filling out the field.
The caveat, there is no way to prevent them (OOTB) to not add the same values twice in your choice fields.
There is no way to link a choice field up to a lookup list unfortunately (that’s what a Lookup field is for! Which, as we know, doesn’t work).
You are kind of stuck now. Honestly, I wouldn’t be surprised to see quickparts go away all together at some point in the future.
You are correct. Lookups have never worked in Quickparts. The reason they aren’t going to invest in it, is because it’s old tech. Quick parts do not function 100% in the browser in OWA, which is why there is no effort to fix it… As OWA seemingly is the #1 place to view and edit documents in latest versions of SharePoint.
if you want consistent names, what’s wrong with creating your column as as site column and using that across your sites? Understandably, a lookup would be easier to manage your values… but not the best option in terms of quickparts.
Thanks Beau Part of the answer is 2 – when a user “touches” the lookup field, SharePoint will popup all the other meta data e.g. parent committee, chair, admin office for the group. This is quite useful – not sure if it might be worth maintaining the lookup field for this in parallel with a choice for the metadata and hoping staff won’t mind setting the same value twice? But the primary reason is that the intended users are all very non-technical. Teaching them how to add a new group/committee (and we have them all the time) to a list which has a nice easy to find link is one thing, giving them a admin account and then expecting them to modify a column definition on a site column several times a month is not on. I am not a SharePoint expert myself but I do have some 35 years in IT (many as a vendor at MS) but I am also an elected councillor so “passing through” which means they won’t have even my level of IT support all the time so it needs to be straightforward. Editing from web Word is not an issue as 99% of access will be councillors, public etc. who will not have write access anyway and the staff would simply use full Word. Much more worrying is that if it doesn’t work properly in the web and that is being used for a reason not to fix something in the desktop product (it cant be very hard to do – in fact it already works when you got to file info!) puts the whole of quickparts in doubt. As it happens, these documents about meeting are already “in trouble” because we use document sets to corral them together (all documents for the same meeting date for the same committee “live” in one document set) and as you know MS support for document sets in the modern UI is non-existent and they have been “looking at it” for over a year. I did extract a kind of promise from a PM that it would happen but not soon). To my mind, the whole of SharePoint seems to have a “not finished” “not properly resourced” feel about it. And I am always unhappy when a product has advertised features that simply don’t work over a period of time and the solution seems to be to drop the feature in a future version (with no information). So thanks – i wonder if there is a way to link the choice to a lookup so that the other meta data about a committee could be presented in the document set header?