A proposed “vendors” entity type points at a random spreadsheet import table full of duplicate vendor names. What source choice is better?
Select an answer to reveal the explanation.
Short Explanation
Feeding vendor entities from a messy import sheet is like building a phone book from coffee-stained napkins—you get three “Acme”s and no owner. Aim the entity type at a governed vendor or company table. Clean source data beats heroic dedupe later.
Full Explanation
A vendors entity type should point at a governed vendor or company source table with cleaner unique records rather than a random spreadsheet import full of duplicate names. Entity types inherit source quality; coffee-stained import sheets produce three “Acme”s and no clear owner. Clean source data beats heroic dedupe after bad generation. This remains entity-framework sourcing guidance—not a full Third-Party Risk Management product implementation. Keeping the duplicate import table because generation supposedly deduplicates any source automatically is wishful thinking. Using the incident table as the vendor master for GRC entities confuses tickets with party master data. Creating vendor entities only as attachments on Knowledge articles abandons the entity model. Exam caveat: prefer authoritative vendor/company tables for vendor entity types. Operational check for the proposed type: identify the governed vendor/company table, assess uniqueness and ownership fields, point the entity type there with active filters, generate a pilot set, and reject the staging import table as the ongoing source. Keep civic stakeholders aligned on the operating model, and verify platform records after each change before reporting posture to leadership. Revisit the design when CMDB classes, org structures, or program charters change.