Announcements
Hello,
I'm looking to map an ID provided by a managed solution to a contact ID by creating a many-to-one data structure I can populate and query to pull back the the contact ID.
Ideally I'd define this data structure in the managed solution.
With my limited experience I'm considering defining a formless Entity with 2 fields and then populating and querying the data using Dynamics Web API.
Is this the way it should be done or is there a better solution to meet my requirement within Dynamics?
Thank you,
Rob Doyle
Hi Bruno,
Thanks for all your help with my question and the tips, all very much appreciated.
Yes. if you already have a JavaScript app interacting with d365 it already has the framework in place that you can extend. just need to create the entity and invoke using the rest api.
Some apps call direct, others wrap inside a c# rest api. either way you end up using the d365 rest call that may look a little like api/data/v9.1/new_contact_channel_user.
You can use an app like this to help generate the api code with more precision: www.xrmtoolbox.com/.../
most managed solutions may have a way to offer extension you can maintain following a certain procedure, but some third party devs manage to create some stuff that will get deeply engrained in d365 and wrack it up during upgrades.
If it is doable , the provider usually will tell and provide guidance on how to upgrade without loose customization
One last thing, without a relationship, someone could accidentally start inserting guid values in the contactid field of the entity Contact_Channel_User that are not really real contact id. Just need to make sure there is some security around and good testing. (i've seen things like that happening and messing up reports)
Thanks again Bruno,
Part of the upgrade process is to remove the old version and that fails as other apps rely on (our version of) contact or other core entities we have previously customised.
I think the Contact_Channel_User entity is likely the way to go.
Our App is running javascript on a site outside of Dynamics and it is from there we need to create/read these mappings. Maybe Dynamics Web API is our only option?
You could create an entity like this
Contact_Channel_User |
|
ContactID |
ChannelUserID |
c501e605-2a84-4e32-b3e2-9188c2e4873c |
f57ea879-3b6b-4408-bca3-b03becd4d4d1 |
did you try to add the relationship to store the channel id direct into the contact ID and some upgrade dropped the relationship? Not sure if an upgrade would drop that along with the data right now. upgrades don't delete d365 components or data but maybe managed solutions may cause some extra damage.
if you go for this customization, you could add a relationship from contact table to Contact_Channel_User and put it all on a solution you can export and save on safe place and import back case the third party company upgrade drop your customizations. with a custom entity it won't lose data.
to automate in a way the agent is not aware you will need something like power automate or a plugin. But would need to know the details on how this app works. does it create a record where we can put a power automate to launch upon record creation?
Hi Bruno,
Thanks for your time and patience. I think I left an important piece of information out of my description. The app is a communication app that is integrates a 3rd party service via the Channel Integration Framework.
The ID identifies a user in a system outside Dynamics that we are aware of when the user contacts the agent. The idea of this mapping is to be able link the external ID with a Dynamics Contact ID, once the agent has identified or created the contact in Dynamics. Then when the customer next contacts the agent they will be identified automatically. This mapping should be automated and something the agent is not directly aware of. They will not be aware of the External ID itself.
I'm hesitant to alter the Contact Entity as past experience has shown that customising core entities has caused significant problems when upgrading the managed solution due to dependencies when multiple solutions are in play.
Hopefully this clarifies the situation. Do you have any further advice?
Many thanks,
Rob
Hi Rob,
Did you try the out-of-the-box many-to-one. I tried this on a managed entity with all managed properties set to false and seem to work
an custom entity is more common for many-to-many because the out of the box many-to-many is a bit limited
How are you going to fill the data? through forms or some automated process? or both?
André Arnaud de Cal...
294,033
Super User 2025 Season 1
Martin Dráb
232,854
Most Valuable Professional
nmaenpaa
101,158
Moderator