We have a customer that we are implementing DV for, but they have a couple of Objects in Salesforce (tables) that do not have a logical business key (and do not live in other systems). For the list of about 30 that originally fell into this category, we were able to identify suitable business keys for all but 8. The most straightforward one is below:
They have a Project Template object that follows an associated Activity Template. A Activity template can be associated with multiple Project Templates, and the Activity Template can be associated with multiple Project Templates.
Activity Template Fields:
- ID (uniquely generated by Salesforce, and is unique across all of Salesforce customers)
- Name (never unique and has high potential, with examples, of it changing over time)
- Project Template (relationship to the ID of the Project Template but not unique)
- Is Deleted (Boolean)
- CreatedBy/ModifiedBy (non-unique)
- Status (Picklist/non-unique)
- Allow Uploads
- Checklist Complete
The only unique field is the ID field. I thought about using that in the Hub, even though it feels frowned upon when stood up against DV2 standards, only because this data is never referenced in any other system (it is a part of a Salesforce Managed Package).
I also thought using a Reference Table, but after refreshing my knowledge of those from the DV2 book, that didn’t feel like the right choice either.
I still lean back to a Hub and Satellite, but then I revert to using the primary key as the business key.
This is unfortunately one table that can’t be left out, because it joins up to the related data in the information mart and is then used to create flags based on specific values. It doesn’t feel like it should live directly in the information mart, because they need to historically associate the data (what template was a project associated to in Feb 2023 vs Sept 2023, and what did that do to the flags)?