Many organisations have data spread out across different locations, and it is common that there are both intentional and unintentional duplicates. Planhat uses multiple fields to maintain data hygiene.
Planhat's Unique Identifier (UID) and/or Keyable fields:
Field | Rule | Type |
planhatID | Universally Unique | UUID and Keyable |
sourceId | Unique per Model | UID and Keyable |
externalId | Unique per Company | UID and Keyable |
- | Keyable (if unique) |
Planhat's Uniqueness rules
planhatIdis always universally uniquesourceIdmust be unique for each record on the same modelexternalIdmust be unique for each CompanyexternalIdmust be unique for each record on the same model, that is associated with the same CompanyE.g. if 2 End Users are associated with a Company, they can not have the same externalId, but if 2 End Users are associated with 2 different Companies, they are permitted to have the same externalId
emailis a field on the End User Model, that can be used as a keyable if it is unique. However, we do not enforce any uniqueness rules here as email addresses may sometimes intentionally be duplicated on the same Company, or across Companies.
Why do we allow duplicate Enduser email addresses?
This is to give you more flexibility in managing your data. You may have a setup in which you have multiple endusers per Company, spread out across different tenants or products. A good example is if you have sold several instances of the same product (possibly tracked as an Asset in Planhat) to a single company, and an email address has access to multiple tenants. Since you will be tracking user activities per Asset, we allow you to have multiple instances of the same email address on the same company, provided externalId or sourceId is unique.
You can read more about using keyables in our API docs