This scenario requires a specialized version of an existing entity. In Guidewire InsuranceSuite, when a new " type " of an object is needed—especially one that might require its own unique fields, validation rules, or UI behavior in the future—the best practice is to use Subtyping.
By creating ABAutoGlassShop_Ext.eti as a subtype of ABCompanyVendor (Option A), the developer leverages the power of inheritance. The new entity automatically gains access to all fields defined on ABCompanyVendor, ABCompany, and ABContact. This establishes an " is-a " relationship (an Auto Glass Shop is a Company Vendor).
Other options are architecturally incorrect for this requirement:
Option B (Array): An array implies a " has-a " relationship, which would mean a single vendor has multiple glass shops, which does not fit the requirement of defining the vendor type itself.
Option C (Column): Simply adding a column doesn ' t allow for the specialized polymorphic behavior that subtyping provides. It would also clutter the base table with fields that are only relevant to one specific type of vendor.
Option D (Extension): An .etx file is used to add fields to the existing ABCompanyVendor entity for all its instances; it cannot be used to create a new, distinct entity type.
Following the subtype approach ensures that the new ABAutoGlassShop_Ext can be used in any search or assignment logic that expects a ABCompanyVendor, while still allowing for future specialization.
