I am using scribe to migrate the Principal Object access data from CRM 4.0 to CRM 2016 DB.
The source adapter is a SQL Data Adapter which reads the data from the POA table in 4.0.
The destination adapter is the CRM Adapter and I have an insert step to insert the data into CRM 2016.
In the destination adapter, Scribe does not allow me to add the data links to PrincipalId and ObjectId fields from the source.
As far as I know, both of these fields are required to create a principal access object. However, since I can not create the data links, I do not know how I can copy this data over to CRM 2016.
Has anyone ever tried to Migrate the Principal Object Access table using scribe and have any suggestions for me to try out?
Any help will be greatly appreciated.

- 22,364
- 14
- 59
- 168

- 68
- 9
2 Answers
A few things I've noticed from your screenshot that might help you out:
- You're trying to set the principalobjectaccessid on insert. I would think this is a no-no as you are creating a crm record and want a new guid to be assigned at that time instead.
- You're doing the lookup to the type code but not to the foreign keys for the objectid and the principal id. You would need to refer to those (probably by name or an xref table as the guids will be different post import) in order to get the sharing in place.
- In order to lookup those objects and principals you will need them to be entered into CRM2016 in a prior step.
One caveat I'd add is that based on the limited knowledge I have of you trying to move a 4.0 thought process involving sharing over to CRM 2016 this very well could be a bad idea. While sharing is still supported and certainly a part of the application there's performance issues that come up with extensive sharing and it's honestly a much more complex thing to work with then utilizing teams.. As I'm sure you're noticing now.

- 1,902
- 1
- 9
- 10
-
Thanks for the reply. 1. On insert, we are trying to map the id so that the id is the same as the one in CRM 4.0. I have done this for the account, contacts and other custom entities and it copies the ids correctly. I will try by removing the mapping to the id and insert with the new id and see if that helps. 3. I have migrated the objects and principals from CRM 4.0 and they have the same guids as they had in 4.0. – mahajan Jul 14 '16 at 17:01
-
Regarding Point 2. I did not understand. I can set up the lookups but that does not really solve the problem. It still does not allow me to set up data links to copy the principalId and the ObjectId to the object. Can you please elaborate? Let me try out the suggestions mentioned above and I will let you know how it goes. – mahajan Jul 14 '16 at 17:05
-
Ok I'll wait to hear back on that front. Have you searched Scribe's knowledge base for the error message you're getting? [openmind.scribesoft.com](https://openmind.scribesoft.com/forums) – Brendon Colburn Jul 15 '16 at 14:21
-
I ended up writing a console app to take the data from the 4.0 POA table and then call the Grant Access method of the SDK on the new CRM environment. – mahajan Jul 28 '16 at 21:01
The POA table is internal to CRM and shouldn't be written to directly, even via the API.
It stores details of how records (determined by the objectid) are shared to users/teams (determined by principalid).
It sounds like you want to migrate your shares from CRM 4.0 to 2016. Scribe has a mechanism for doing this, using virtual fields. Look in the help for "Adapter for Microsoft Dynamics CRM" and search for "Granting Access". This explains how to use the virtual fields.

- 368
- 1
- 10
-
I tried setting the virtual fields from the source but that did not work. It seems to only work for create. If an object has multiple rows in the POA table, the update step does not write the values to the new CRM environment. – mahajan Jul 28 '16 at 20:56