How do you handle navigational properties and optionsets during CRUD operations?

[nilanjenator]

I am looking for some high level advice.

When you have an app to read and write data from Dynamics, how do you handle the navigation properties or option sets.  (My question is not which API to use).  What are some best practices?

I assume you don't use hard coded names for entities?  Do you need to know the values of option sets?  How do you navigate navigation properties?

I assume this is really more related to the concepts of open data?

[jlindstrom]

please specify if you are talking about model-driven apps or canvas apps? 

Model driven apps take care of all of that for you--they provide the navigation--for example, I add two entities: Inspection and step.

I create a 1:N relationship between inspections and steps. 

CDS creates the relationship and any app with those entities in it provides the navigation path without you having to do anything. on Inspection, you see the related inspection steps in the inspection navigation, from inspection step you have a lookup field with hyperlink back to the parent inspection.

Canvas apps are different in that you have to set up the navigation to the form, etc, but CDS provides the relationship linkage. You do need to add a connection to any entity in your canvas app.

Option sets provide a list of options with a string value and support multiple languages of text label. https://docs.microsoft.com/en-us/dynamics365/customerengagement/on-premises/customize/create-edit-gl...

Did that help, or are you looking for more?

[EricRegnier]

Hi @nilanjenator,

Generally as guidelines, especially for larger implementations, we try to use entities (lookups) as reference (i.e. navigation properties as you call it) instead of option sets. Future thinking and for flexibility, entity allows us to determine additional properties (e.g. Display Order, or Code) whereas option sets are just key value pairs. Even for a field like Gender where the obvious choice might be an option set, but analyzing more in details, Gender can be exposed in a Portal, internally in different apps and each of those might have difference requirements. For example portal needs a different display order and a different user-friendly label. But if we have to use option sets then always go for global option set in case another entity needs it in the future.

That said, to go back to your original question, how do we handle these? Well it depends on the scenario. Here are the typical ones:

1. Model-driven app, as @jlindstrom said, it's sort of handled out-of-the-box with lookups and option sets. So you don't have to worry about the references assuming you deploy those correctly. It's important that you import these values properly in the target environments to ensure the same behavior after release. For instance, if you reference a lookup value in a workflow, if that record was imported/created with another ID (GUID) that workflow will fail (the system wouldn't be able to activate the workflow after solution import). The typical methods to import reference data is with the Configuration Migration tool and for option sets is with a standard CDS solution.
   1. https://docs.microsoft.com/en-us/power-platform/admin/manage-configuration-data
   2. https://docs.microsoft.com/en-us/power-platform/admin/import-configuration-data
2. In custom code such as plugins and web services (e.g. Azure Function), you can generate the entities, fields and option sets types in C#, this is known as early bounds. The option set values will be typed as enums which you can then easily reference in code. More info on early and late bounds:
   1. https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/org-service/early-bound-pro...
   2. There's also a XrmToolBox tool to facilitate the  generation: https://www.xrmtoolbox.com/plugins/DLaB.Xrm.EarlyBoundGenerator/
3. In Power Automate, Logic Apps, and Canvas App, you'll have to know the exactly what the option set values are so hard code, which again should match in all environments (Dev, Test, UAT, etc). The CDS connectors does have some intellisense so you should be able to identify what the values are at configuration time. For entities, if the GUID matches in all environment you can use the ID or many times, it is preferred to have a more friendly type of ID (like a Code field) and retrieve the references by the Code instead of hard the IDs. 

Hope this all makes sense....