When I started this series, my intention was to create a series of videos to guide a user in the fundamentals of the Power Platform, starting with Entities and working my way through each of the parts.
The trouble with video is that it takes a long while to edit and prepare. Each video was taking 4-6 hours to produce. This, I am well aware, is most likely down to my lack of skill, but it was definitely not a great use of my time. The time I dedicated to this was cutting into the time I spent with my family and other side projects.
So, to keep the series going, I am going to switch to writing the articles, but still keeping to the remit of 3 minutes. The average person reads 200-250 words a minute, so my limit is 750 words. Not for the intro, but for the article itself. I hope the articles are informative and enough to get you going on the topic. Let me know any feedback.
Episode 10: Keys
Keys are used to denote unique fields or sets of fields for an entity. Each entity will have one primary key, the GUID of the record and a developer can
add up to 5 secondary keys.
Typical usage is to denote a key from another system - if you are integrating and the source has a unique identifier, it makes sense to create this as a key in your entity.
Keys are unique. If someone tries to create a record, through the interface or via the API with the same unique value in a key as an existing record, it
will fail and the user will be notified. This is the only way you can fully ensure duplicate data is not created. De-duplication rules check for matches,
but the user can easily bypass this.
There are only a few fields that can be part of keys
- Decimal Number
- Whole Number
- Strings
- Date\Times
- Lookup
- Picklist
Also, when the key is populated, any fields with certain characters in the data it (<,>,*,%,&,:,/,\) you will struggle with upserts and patches. This is fine if you are doing uniqueness checking only, but not if you are using this for an integration. Keys are limited to 16 fields each as well as 900 bytes per key (the fields concatenated together, not the data).
Creating Keys
So let’s create a key for our new entity. In the Keys tab, select Add Key,
You are presented with a selection of the fields that you can add to your key, you must choose one. Also, give it a name. Hit Save entity. The key will be added to the database in the back end. In the maker experience, you can not tell the progress of this step, but you must check this progress, as without the process completing, your key is redundant.
Hit the Classic Interface button, drill down to keys and you can see the status of the job, drilling down again to see the detail.
Depending on how much data you have, depends on how long this process takes. As you move up the systems, from Dev to Test and Production, be aware of this. The time it takes to import a solution and publish it will be affected. Millions of records will take time.
My key doesn’t work, the system process failed. This is because the field I used, Name, has duplicates in it. This means that the key is not in position to be used & duplicate detection will not work.
Duplicate Detection
In the interface, if I try to create a thing with the same name as already exists, I will get an error and be stopped from progressing. This names the key and prompts the user where to look. Ensure the name of the key drives the user to the right field to change.
Combining fields to form a key is great here. You could prevent leads being created which have the same first and last name as well as postcode or company name for example.
So simple, useful & essential to build up your requirements.