Forum Discussion
ApplyProvisioningTemplate doesn't have token {listid: Project Team} in token list.
Hi Paul,
I will need to scrub the xml and verify it's ok to send but I'll try.
What elements set the order that you mention? I've seen that within a gouping E.g. Site Groups order matters and that they aren't always written out in an order that will work with sequential play back.
In ApplyRemoteTemplate the handlers are added Fields first then Content Type, then List. Seems like the list skeleton (with just a title) should be created first to get an ID for putting back when creating a Field.
From your description I understand there are Lookup fields in the play? Lookup fields need special attention because of the reasons you are describing. PnP should support Lookup Fields and special handling was implemented. There was an issue submitted in PnP earlier around the provisioning of lookup fields, see the link below.
https://github.com/SharePoint/PnP/issues/906
Are you using the latest version of PnP Core? If so the issue seems to be still there albeit currently closed in PnP. I think it really helps to share your template or a scubbed version of it that fails in order to be able to fix this.
- Jonathan LoweFeb 28, 2017Copper Contributor
That discription from github is right on the money. I'm trying to make a site that I can download the xml that will reproduce should have that soon. I'm using the 2/10/2017 release.
- Jonathan LoweFeb 28, 2017Copper Contributor
Ok I think I know what happened. If you have a field like Paul pointed out lookup in site column, it will create the field. If you crash later on in the ApplyProvisioningTemplate process and rerun (which I did because we had an issue with a non existant item) prior to the list being created then the check for existing field IDs will be true and you'll try to update the field instead of create. In that case given the list hasn't been created it'll still have {listid.} and will fail the xml syntax check. Not ideal but it makes sense now.
Thanks for the help Paul