Data model extensions

The metadata files

When the server starts with changed metadata, it compares the definitions with the database and runs a database upgrade: adding tables, columns, indexes and typelist rows as needed. Generated Gosu types pick up the new fields immediately in Studio.

Extending an entity

Say ClaimCenter needs a fraud score from an external engine and the channel the loss was reported through:

<!-- Claim.etx -->
<extension xmlns="http://guidewire.com/datamodel" entityName="Claim">
  <column
    name="FraudScore_Ext"
    type="integer"
    nullok="true"
    desc="Score 0-100 returned by the fraud engine at FNOL"/>
  <typekey
    name="ReportingChannel_Ext"
    typelist="ReportingChannel_Ext"
    nullok="true"
    desc="How the loss was first reported"/>
</extension>

<!-- ReportingChannel_Ext.tti -->
<typelist xmlns="http://guidewire.com/typelists" name="ReportingChannel_Ext" desc="Loss reporting channel">
  <typecode code="phone"  name="Phone"          priority="10"/>
  <typecode code="portal" name="Customer portal" priority="20"/>
  <typecode code="agent"  name="Agent"          priority="30"/>
  <typecode code="email"  name="Email"          priority="40"/>
</typelist>

After a restart, claim.FraudScore_Ext and ReportingChannel_Ext.TC_PORTAL are available in Gosu and PCF.

Adding a new entity

When you need a new kind of record — say, a log of every fraud check performed on a claim — create an entity with a foreign key back to its parent, and an array on the parent:

<!-- FraudCheck_Ext.eti -->
<entity xmlns="http://guidewire.com/datamodel"
        entity="FraudCheck_Ext" table="fraudcheck_ext" type="retireable"
        desc="One call to the fraud engine for a claim">
  <foreignkey name="Claim" fkentity="Claim" nullok="false"/>
  <column name="CheckedAt" type="datetime" nullok="false"/>
  <column name="Score" type="integer" nullok="true"/>
  <column name="RulesTriggered" type="varchar" nullok="true">
    <columnParam name="size" value="1000"/>
  </column>
</entity>

<!-- in Claim.etx -->
<array name="FraudChecks_Ext" arrayentity="FraudCheck_Ext" arrayfield="Claim"/>

• The type (e.g. retireable, editable, versionable) decides which platform columns and behaviours the entity gets — see module 02.
• The array on Claim makes claim.FraudChecks_Ext usable everywhere, including PCF list views.
• Child entities like this usually travel in the same bundle as their parent.

PolicyCenter specifics

PolicyCenter adds rules because of effective dating and branching:

• Data that changes during the term must live on effective-dated entities so each slice keeps its own value.
• New coverables and their children are typically created as effective-dated, branch-aware entities, linked to the PolicyPeriod or line.
• Product model elements (coverages, terms) are defined through the product model tools rather than hand-written entity files.

Rules that keep upgrades cheap

1. Never edit base metadata. Extend with .etx/.ttx.
2. Suffix everything you add (_Ext), including columns, entities, typelists and typecodes where your standards require it.
3. Don't repurpose an existing base field for a different meaning — reports, integrations and future features will assume the base meaning.
4. Avoid destructive changes after go-live: dropping or renaming columns and changing types need data migration scripts and careful planning.
5. Retire typecodes, don't delete them, when old data uses them.
6. Index deliberately — add indexes for fields used in searches and batch queries, and agree them with your DBA or the cloud platform rules.
7. Document each extension's purpose in desc; it shows up in generated data dictionaries.

The data dictionary

Studio and the build can generate a data dictionary: browsable documentation of every entity, field, typelist and relationship, including your extensions. It's the single most useful document for BAs, testers and integration teams — publish it with every release.