In the Sales Literature entity, there is a Subject attribute that acts like a "multilevel" select. Technically this is a Lookup. Is there a way to have similar multilevel select boxes in other entities?
Subject is a special entity that comes automatically with the platform for organizing the cases (incidents) or KB articles. Everyone like to have that taxonomy like custom attribute but its not achievable.
But you can use that same Subject entity to create a lookup attribute in any custom entity. Its going to be the same entries everywhere.
Go to Settings - Service Management - Subjects, to customize the taxonomy entries. Create a new lookup attribute in custom entity & add to the form.
Related
I'm new to PowerApps. I'm creating a model-driven app. I've created some custom tables in the DataVerse - Information System, and Business Process. These tables have a M:M relationship. An Information System supports one or more Business Processes and a Business Process can use one or more Information Systems. I need to capture additional attributes that describe the nature of the relationship - what role does the Information System play with respect to the Business Process, and a score indicating how effective the Information System for that Business Process.
I've learned how to create M:M relationships using the built-in functionality in PowerApps but this does not permit me to define additional attributes for the relationship.
I've created my own M:M "middle" table and created M:1 joins from that table to each of the related tables. My "middle" table contains a lookup to each of the other tables and the additional attributes I need.
I need to know how to modify the default form for each of the related tables to include the "middle" table to enable a user to select a row from the "other" table and also to supply values for the additional attributes. I have searched for several days now and have not found any literature explaining how to do this.
I'm hoping there's someone who knows how to do this or can direct me to some literature about how to do it.
Thanks in advance for any assistance you can provide.
What you did is right, initially you created a native N:N relationship and for your need it should be manual N:N relationship which you created later.
You can add the subgrid of manual N:N intersect entity (two lookups and extra attributes) in both the main entities - this way you can create related records from either side. It can be a related navigation in the form instead of subgrid as well.
Read more
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.
I want to create an OData service to fetch details from two tables of SAP and fit it using Master detail template in UI5. The first table contains only the product Id and description , while the second table contains the Product Id and product details like manufacturer address,cost , exp date etc
Currently two RFC are created writing the SELECT query on the tables to generate OData service from RFC. Shall i create One Entity set and use both RFC from Read and Query each at Map to Data Source ? or create two entity sets to map one RFC for each Entity set ?
How should be the Odata service query look to develop a master detail application in ui5 fetching data from two tables ? As well as how will make a local master table in UI5 using both table which are fetched.
Well, it depends :)
It looks like you have a 1:1 association between the product header and the details.
So you could model header and details as separate entities and define a 1:1 association between them or you could simplify you model and merge both header and detail attributes into one entity. With the information i have, i would prefer the single entity. You can use ODatas $select parameter to request only specific properties. Your DPC implementation could make use of $select and call only the header RFC if only header fields are requested.
I'm not shure if the master detail template can be used with 1:1 associations. Normally they are used with 1:n as the detail page displays a list of detail items. But you can of course leave the details unbounded in the wizard and bind additional fields later in the object header of the detail page.
I'm just looking for a bit of clarity on the correct way to model custom entities and activities in CRM 2011.
I have to model a custom activity which is called a Submission. It is really just a Case with some additional properties.
When creating this in my Solution, is it best practice to base it on the Case Entity and then add the properties, or would it be better to create a new activity instead?
We have other types of activities which are similar, so I would also be basing them on the Case entity if that's the best way to go.
Many thanks,
John
I usually err on the side of creating a new custom entity (or activity), especially if you think you might have "case types" that are significantly different. It isn't fun writing a bunch of javascript that shows/hides fields based on type.
You might pick the one activity type (perhaps Submission) that is most like a "Case" and then create custom activities for the others that are close. But then you'll have subtle differences (the Customer lookup on Case, for example, can be either a Contact or Account, but you can't add your own "Customer" lookup to your custom entities).
Unless you really need something that the built-in Case entity provides that you can't do yourself, my vote would be for new entities (activities) and then just hide the built-in Case entity by security roles.
I've made a custom entity that will work as an data modification audit (any entity modified will trigger creating an instance of this entity). So far I have the plugin working fine (tracking old and new versions of properties changed).
I'd like to also keep track of what entity this is related to. At first I added a N:1 from DataHistory to Task (eg.) and I can indeed link back to the original task (via a "new_tasksid" attribute I added to DataHistory).
The problem is every entity I want to log will need a separate attribute id (and an additional entry in the form!)
Looking at how phone, task, etc utilize a "regardingobjectid", this is what I should do. Unfortunately, when I try to add a "dataobjectid" and map it to eg Task and PhoneCall, it complains (on the second save), that the reference needs to be unique. How does the CRM get around this and can I emulate it?
You could create your generic "dataobjectid" field, but make it a text field and store the guid of the object there. You would lose the native grids for looking at the audit records, and you wouldn't be able to join these entities through advanced find, fetch or query expressions, but if that's not important, then you can whip up an ASPX page that displays the audit logs for that record in whatever format you choose and avoid making new relationships for every entity you want to audit.
CRM has a special lookup type that can lookup to many entity types. That functionality isn't available to us customizers, unfortunately. Your best bet is to add each relationship that could be regarding and hide the lookups that aren't in use for this particular entity.