I am very new to Dynamics. I'm trying to figure out if I can use dynamics to create sub-types of the contact entity which have all the common attributes and relationships of the contact entity but each has their own specific attributes as well.
I am thinking about this in an object oriented frame of mind but cannot see how this could be accomplished in Dynamics.
As an example say I was managing schools in a region and I had 3 types of contacts in the system:
School Teachers
School Administrators
School Pupils
All of these would share the attributes from the contact entity but teachers and administrators would have some employee specific attributes and students would have some student specific attributes.
Can someone give me an example of how to accomplish this?
You could set up a picklist on the contact entity with the different "types" on contacts there were. Then attach some javascript to that attribute, so that when it changes, it shows/hides the extra type-specific fields you've defined.
In SAP there are diffrent Roles for a Business Partner (Contact in your example) maybe its similar in the ms crm, but thats just a clue.
Related
I have the below requirement -
We have an entity named Garden. A garden is owned by a person or company, and can also be leased by one or more people or companies. Each garden has a unique number.
Ideally, we would want to be able to see a single grid of all the people that own and/or lease the garden, regardless of whether they are a person or a company.
Questions -
1) Which entity to choose for person -> User or Contact
2) Which entity to choose for company?
3) How to design record ownership or leasing of garden?
This is a broad question, I’ll try my best.
Fact: We don’t have an option today to create a custom polymorphic entity - to capture/store multiple types of entities. There are some available OOB entities - Customer to store Account/Contact, Owner to store User/Team, Activity Regarding to store any Activity enabled entities.
If you look at Bookable Resource entity, even MS store the type like User or Equipment & respective lookup records separately. This is what you need exactly. Read more
1) Which entity to choose for person -> User or Contact
2) Which entity to choose for company?
User (owner) in case you need security around the ownership of the records. Then company has to be the Teams, because you mentioned Garden maybe owned by Person or Company. How many records you’re going to manage and are they going to get login in CRM?
You may have to look at PowerApps (Dynamics) portals which gives B2B, B2C options to control records ownership by Accounts/Contacts.
3) How to design record ownership or leasing of garden?
Partially answered in the above points. For leasing, you can have multiple subgrid (1:N) relationship. If required, you may need a custom component or web resource to pull the multiple type of owned/leasing records by UNION the results & render as a grid.
I have a Account Relationship entity with two lookup fields called Recipient Account and Guide Account. I would like to be able to go on an Account and see all records where the Account Relationship's Recipient Account and Guide Account are set to the account I'm viewing.
In CRM, I can definitely create a view to fetch all account relationships on the Account Relationship entity and then inside the Account entity's form I can include the view with the data source set to Related Records Only and the entity set to Account Relationship (Recipient Account). But I can't do both in a single view.
Through what mechanism can I have it all be in one view? One thing I was considering was creating separate grids, one for Recipient Account and another for Guide Account. But I want to know if there is a mechanism where I can combine all records that have "Recipient Account = Current Account or Guide Account = Current Account" that is basically the query I want to run.
You could use connections. It's pretty flexible and will fulfill your needs as long they stay simple. That's the only viable option I see aside from using two views.
Keep only one subgrid of Account Relationship N:N intersect entity (either Guide account or Recipient account relation)
Register RetrieveMultiple pre-operation plugin to intercept the query & pass the custom fetchxml query by incorporating or filter
Fetchxml has to be built something like explained
Try this unrecommended if you wish but two grids are better choice. This alternate solution also you can try.
In our system, some contacts are linked to the leads later in the process, therefore those contacts don't have the Originating Lead (originatingleadid). Also, we want to connect some contacts to multiple leads.
Currently, we are connecting contacts and leads through the Parent Contact for Lead field (parentcontactid in lead entity).
But the problem is that if the contact does not have an Originating Lead, the activities from the lead are not displayed in the contact's social pane. The relation made through parentcontactid field is ignored.
Is there any workaround for this? Is it possible to make such a relation between the contact and the lead that the activities from the lead are displayed in the contact's social pane?
The originatingleadid field is not valid for update, it can be set only on create.
You can change the Rollup View Relationship Behavior on custom 1:N relationships to Cascade All. In this way the activities from children will be shown on the activity view for the parent.
This would require you to create a custom relationship between Contact and Lead, since you cannot change this property on the standard relationships in the system.
You have not specified a version. The Rollup View Relationship Behavior was added in Dynamics 365 (version 8.2).
I have an entity - EntityZ, which has a ParentId where ParentId could be EntityA.Id, EntityB.Id or EntityC.Id. Is it possible to create this in MS Dynamics CRM 2016? If yes, how? I've looked but couldn't find a similar question or any help on the web.
An entity can be the child party in only one full parental relationship. When you are looking for a way to cascade record ownership, deletion a.o. between mutiple parent - child entities you can create configurable cascading relationships.
As Arun Vinoth pointed out you can design your entity as an activity type. However, this may conflict with the semantics of activity records in CRM. Also, doing this would make it possible to associate the child entity to any entity that is enabled for activities.
There’s a trade off to achieve this. Custom entity as Custom Activity
Creating custom entity EntityZ as custom activity and EntityA, B, C can act as parent.
EntityA or B or C can be chosen as RegardingObjectId of EntityZ.
This has security limitation like EntityZ will be visible to everyone as this will be listed like other activities (Email, Phonecall, Task, etc)
I think it is worth nothing that Dynamics 365 does contain and out-of-box "polymorphic" customer field.
This field can link to either an Account or Contact:
And while it can be kludgy, another option would be to create 3 lookups and only populate one. Once one is populated you could hide the other two. Or, you could have a "Parent Type" option set to determine which lookup to show.
It would be a bit messy to show three lookups in a view, with only one populated, so you might also want a Parent Name text field in to which you could concatenate the type and name. You could use a workflow to populate it, and then use it in views and reports.
can anyone tells me how I can retrieve a contact in relationship with the marketing list in crm 4.0 ?
Marketinglist ("blabla") --> Contact(Adam Meyer)
I will see if a contact with a specicic Guid is in a Marketing List.
Hope you unterstand me...
Those relationships are stored in a hidden entity called listmember. However, you can't retrieve those records directly. You'll have to do a retrieve on the contact entity, join it to list member, and then filter it based on the listid of the marketing list. Here's an example.
To remove someone (as you mentioned in the title), you'll need to execute a RemoveMemberListRequest. The SDK has the details.