Choose your path Increase your proficiency with the Dynamics 365 applications that you already use and learn more about the apps that interest you. Up your game with a learning path tailored to today's Dynamics 365 masterminds and designed to prepare you for industry-recognized Microsoft certifications.
Visit Microsoft Learn
2019 release wave 2 Discover the latest updates and new features to Dynamics 365 planned through March 2020
Release overview guides and videos Release Plan | Preview 2020 Release Wave 1 Timeline
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
when I build an entity, the system always auto-generate a primary key named --id,what shall I do to choose some fields as the primary key?
can you share bit more info on this.. because all records are assigned GUID by default in Dynamic CRM. If you need custom unique identifier (for each record) you can have auto generated numbers (alphanumeric also) associated with crm records using simple code.
Hope this helps.
For this you need to create your own custom unique identifier may be you can use plugin.
got it, thank you very much.
What is the purpose?
You can also use the Keys feature in Dynamics 365. You can set an alternate way of creating new records by using a different set of alternate keys.
That's just the way Dynamics works - you can't define your own primary key
Aric Levin is correct. CRM will create its own GUID which is uses as unique identifier.
But CRM also allows you to define your own Unique Key (which can be a single field or combination of fields) using the Alternate Key Mechanism.
You can learn more on the alternate key in the below blog:
What Alex meant to say is that Dynamics doesn't provide primary keys. It provides guids as unique identifiers (pointers, if you will) and misnames them "primary key". You will use the Keys feature to create actual primary keys.
You cannot change the Entity primaryid field to some other field. CRM using GUID as the Primary key for each record. You can change the name of the Primary field name - the text field not the ID field.
If you definitely want to make some other field as Primary key, you could consider using Alternate Keys, this allows you to create up to 5 alternate keys.
See the following
"All Dynamics 365 for Customer Engagement apps records have unique identifiers defined as GUIDs. These are the primary key for each entity. When you need to integrate with an external data store, you might be able to add a column to the external database tables to contain a reference to the unique identifier in Customer Engagement apps. This allows you to have a local reference to link to the Customer Engagement apps record. However, sometimes you can’t modify the external database. With alternate keys you can now define an attribute in a Customer Engagement apps entity to correspond to a unique identifier (or unique combination of columns) used by the external data store. This alternate key can be used to uniquely identify a record in Customer Engagement apps in place of the primary key. You must be able to define which attributes represent a unique identity for your records. Once you identify the attributes that are unique to the entity, you can declare them as alternate keys through the customization user interface (UI) or in the code. This topic provides information about defining alternate keys in the data model."
Hope this helps
Again, what Kokulan meant to say is that Dynamics allows you to enter records without any primary key (hence, no PK constraint.) It does set a GUID unique identifier and mistakenly labels it Primary Key -- we all know this to be the case having read E.F. Codd's seminal document on the relational model.
If you wish to have an actual Key, primary or otherwise, you need to use the Keys feature to define it. As one would expect, you must select a field or fields that in combination are unique to the entity records. Key fields cannot be null, again, as prescribed by Codd. The example account.accountnumber in all the documentation is a good one; none of you accounts should have been given the same account# as any other. For a compound key think of apartments in your building. Floor number is not specific enough and aptletter is not unique, but the combination will be -- e.g. 4F is unique (4th floor has many apartments; there is only one 'F' on each floor.)
It is, however, a misnomer (Microsoft nonsense) that a GUID generated by the save button constitutes a primary key.
Name field can not be removed from the form.You can make this field optional and hide on the form.
Being 'Name' as primary field, if the related entity is used as a lookup on any other entity then due no value in name field ,user may find difficulty to select the correct record.
You can write a workflow to set 'Name' field such as concatenation of 2 fields from the entity or you can change the display name in case of having any other field (field type of Single line of text).
Just wanted to re-iterate this, Dynamics CRM has Primary Key field and Primary Key constraint is applied. The primary key is not an int or long type its GUID type. In fact one of the recent MVC projects I worked on we decided to go with GUID as the primary key not an int field. If we insert two records withe same GUID, CRM will throw an exception on the second one saying duplicate key.
I know GUID has some disdvantages but for Dynamics 365 and for any other systems GUID based PK is very useful, please have a look at the link below to see some Pros and Cons
The alternate key i mentioned above, is not primary key but CRM will prevent inserting more than one record with same alternate key
In some sense it is not a question of Pros and Cons, but one of definition. The only time your GUID constitutes a key is when it is exported to another system -- i.e. it is NOT the result of the creation process. The purpose of a key is to prevent duplicates. If I create a Nut entity and enter "hazelnut" save&new, "hazelnut" save&close, my database will be compromised with duplicate information EVEN THOUGH my two GUIDs are unique. That is why the Global Unique Identifier is not a key. It is a pointer.
And, the example of trying to insert the same GUID twice is exactly my point. Those are data values that existed BEFORE the save (insert) operation.
Business Applications communities