Migrating Related Dataverse Tables between Environments

(0) Share

Report

Posted on by NPrice99

1,302

I have a Solution that contains two tables where one field in the first table is a lookup to a second table.

I have a Business Rule that takes the value of one field in a form based on the first table and depending up on the value of that field shows or hides a second field.

The value of that field is actually sourced from the second table via Lookup view.

So one assumes that the GUID corresponding to the value in the second table in the DEV environment is not the same GUID corresponding to the value in the second table in the UAT environment. SO there fore the Business Rule will never fire because its looking for a GUID and the GUID is different in the UAT environment to the DEV environment.

Surely the Deployment Pipeline takes care of this ? Doesn't it ?

Thanks

Nigel

Categories:

Microsoft Dataverse with Power Apps

I have the same question (0)

All responses (7)

Answers (0)

ivan_apps 2,187 Moderator on at

Like (0)

Report

Not that i've experienced. Customizations are transferred over but not data. Your GUID is tied to the data on the environment, and if your business rule is dependent on a specific data value, then unfortunately i don't see how it would work.
You could try a data import and enforce the GUIDs to be the same, but you probably want a more robust setup than being dependent on specific GUIDs.
You can also update the target environment as a post deployment step to create an unmanaged layer on top of a managed solution, that way your GUID update is maintained.

Was this reply helpful? Yes No
NPrice99 1,302 on at

Like (0)

Report

Hi @ivan_apps
You say "a more robust setup". What would "a more robust setup" look like ?

What is "best practise" in this use case ?
Regards
Nigel

Was this reply helpful? Yes No
ChrisPiasecki 6,422 Most Valuable Professional on at

Like (1)

Report

Hi @NigelP,

I recommend using the Configuration Migration Tool to migrate configuration records where your customizations take dependencies on.

The GUIDs will be maintained when you import the config data into other environments so that any business rules / workflows or other processes will still work.

You can store the Schema and data files produced by the tool in source control since its XML based so you can compare differences when you make updates to it.

You can use the tool to manually import the zipped config data to another environment, or you could automate this as part of a CI/CD pipeline using the Power Platform Tools extension for Azure DevOps, or use the Power Platform (PAC) CLI directly using the PAC data import command.

---
Please click Accept as Solution if my post answered your question. This will help others find solutions to similar questions. If you like my post and/or find it helpful, please consider giving it a Thumbs Up.

Was this reply helpful? Yes No
Jonathan Manrique 2,687 on at

Like (0)

Report

Hi @NigelP
I recommend using the DataMigration Tool or the similar XRM ToolBox tool to migrate records, otherwise when the business rules and workflow are passed they will fail because they will not find the record.
It is one thing to migrate the components of the solution such as tables, web resources, etc. and another is to migrate data.

If I have answered your question, please mark your post as Solved.
If you like my response, please give it a Thumbs Up.
You can accept more than one post as a solution

Was this reply helpful? Yes No
ivan_apps 2,187 Moderator on at

Like (0)

Report

I would say that best practice is not to create business rules that center around lookup values, unless you're ok making that a manual post-install step (config migration). I tend to prefer as simple as possible transfer from one environment to another.
So instead of depending on a GUID (or lookup text), can you make it dependent on a Choice? You have more control that way over the way the values are stored. Is there a flag perhaps that you can set on the form that would trigger the show/hide event? For example, say you want to show/hide fields if a user is a 'super user'. Instead of setting the business rules based on user names/GUIDs, you would simply add a boolean marking your user a 'super user' and trigger your business rule on that Boolean. Same effect, but now I've lost that dependency on a specific ID.

Business rules do have a lot of limitations so if you're retrieving data from related fields to show/hide on your form, it would be best to switch to Javascript.

Was this reply helpful? Yes No
NPrice99 1,302 on at

Like (0)

Report

Thanks @ivan_apps
Javascript is a no - no.
Choice columns are not very flexible as you have to go back to the developer everytime you need to add a new value. Lookups are much more flexible as a Super User can add values to the reference data.
The use case I have is I am looking at, is checking to see if a field in a form is a certain value (derived from a reference data) and then hide / show a second field.

Regards

Nigel

Was this reply helpful? Yes No
ivan_apps 2,187 Moderator on at

Like (0)

Report

That is true, choices are more locked down for regular users by design. If you have constantly changing values, a lookup is best vs more constant values for a choice.
I would be interested in seeing the definition of your Business Rule and how it relates to your Reference Data table, if you are showing and hiding based on values you may be running the risk of allowing a user to make mistakes on your reference data and triggering your business rule when you didn’t intend to or deleting your reference data if you didn’t lock down their delete permission. I would also confirm a GUID comparison is taking place vs a primary field text reference in the comparison.
Ultimately it is your choice to decide how you want your deployment steps to go. If importing reference data to maintain data GUIDs is acceptable to you, no reason not to do it. After all it would be transparent to the end user so it only affects the person doing the initial solution deployment.

Was this reply helpful? Yes No