CODEWITHSUNDEEP
dynamics-crmdata-migrationdynamics-crm-4dynamics-crm-2016scribe-workbench
mahajan
mahajan

Reputation: 68

Scribe Insight: Migrate Principal Object Access table data from CRM 4.0 to CRM 2016

Scribe MapI 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.

Upvotes: 0

Views: 669

Answers (2)

Mike Feingold
Mike Feingold

Reputation: 368

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.

Upvotes: 0

Brendon Colburn
Brendon Colburn

Reputation: 1912

A few things I've noticed from your screenshot that might help you out:

  1. 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.
  2. 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.
  3. 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.

Upvotes: 0

Related Questions