Connector Improvement: Dynamics Sync: GlobalOptionSetTables
Answered
In the first image you see that with only access to the stringmap from dynamics, we have no way to differentiate entity option sets from global option sets.
In the second image I show how dynamics has them differentiated
We need to be able to sync the globaloptionsets into dynamics so we can query them. Below is the link we can use to query them. Hoping we can get this done quickly before the end of May when we lose access to our old MSFT service.
https://trekbikes.crm.dynamics.com/api/data/v9.2/GlobalOptionSetDefinitions
-
Official comment
Hi Travis,
It looks like you're showing that a global option set and an entity optionset could have colliding identifiers of optionsetname, option, and localizedlabellanguagecode. Is that correct? It seems like the solution would be to identify which is a global and which is entity level within the stringmap table, or instead to have multiple tables. Let me know if my understanding is correct -
Perhaps just adding a column that said 'Is Part of Global Option Set' or something would work
Global option sets are a way for us to make changes to all field references and Microsoft's export services have always referered to these as two different field types. I'm no longer seeing collision concerns, but just a nice to have because the options would be duplicated for every attribute they are associated with
I personally re-use the 'Yes No Unassigned' choice instead of the boolean because I like that my users can decide that they can leave that field blank. So instead of having to use a distinct on these rows during a search, I could just pull them in a single search.
Please sign in to leave a comment.
Comments
2 comments