Developing Metadata fields is always a complicated case of the developers. My previous posts(Add Metadata Taxonomy Custom Field using Visual Studio) I explained how we can create metadata site columns. In this post, I will target Office 365/SP online users who can only use sandbox solutions to update/create metadata fields.
Reason why treditional solutions does not with Office 365
In practical scenario, Metadata service details like SSPID, Default term store etc keep on changing. I notice that the name of Metadata service of SharePoint Online keeps on updating after some updates. We all know that code in sandboxed solutions is being deprecated by Microsoft. But even if we were happy to use sandboxed code – in Office 365/SharePoint Online, we cannot use the Microsoft.SharePoint.Taxonomy namespace in server-side code anyway – the net result is that we are unable to “finish the job” in this way to ensure the field is correctly bound to the Term Store. This is a problem! Even worse, whilst it is possible in the CSOM API to bind the field, having this execute in the provisioning process (e.g. as a site is being created from the template) is challenging, maybe impossible. Maybe you could come up with some imaginative hack, but that’s probably what it would be.
If I talk about the solutions of this issue, then our thoughts might lands on setting the metadata field manually. But again its very tedious for clients to do such configuration for 500/1000 sites. There could be one alternative which can save our life if we can figure out the SSPID and Termset Id for particular environment . Following is the code for creating custom fields if you want to map the columns with particular Term set provided you must be aware of two of the required Ids.