Your Guidewire instance carries fields no other carrier has. Extension columns on policy and claim entities, typelist codes from your own product catalog, and mandatory fields set by your underwriting rules all differ from the carrier next door.

When a sender integrates with two carriers, those differences usually turn into two copies of one connector. Each copy drifts, each needs its own fix after a release, and each needs its own maintainer.

This article covers where tenant differences live, why a fork costs more than it looks, three ways to handle carrier-specific fields, and how to review and test a tenant mapping so the next sender does not need a new build.

Where do tenant differences live in a Guidewire integration?

In a multi-carrier integration, a tenant is one carrier’s Guidewire instance and everything configured on it. The core data model is shared. The differences sit in three places, and each needs its own treatment.

Extension fields on core entities

Every carrier extends the data model. A carrier adds columns to PolicyPeriod, Claim, or Account for its own rating, reporting, or regulatory needs.

A sender’s standard payload has no place for those fields. The integration has to decide where each value comes from and where it lands.

Typelists and valid values

The same business meaning arrives under different codes. One carrier uses a short string for a coverage, and another extends the typelist with entries of its own.

A payload that sends the wrong code fails at the Guidewire boundary or lands with the wrong meaning.

Mandatory fields and complete submissions

Each carrier defines what makes a payload complete. A field that is optional for one tenant is mandatory for another, and the mandatory set often changes by line of business.

The sender’s side of this problem is covered in how MGAs, TPAs, and brokers send submission data into PolicyCenter.

Why does forking the integration cost more than it looks?

A fork starts as the quickest way to ship the second carrier. The cost arrives later, spread across releases, fixes, and staffing. Three costs show up first.

Every fork runs its own release clock

Guidewire ships three releases a year. Each fork needs its own regression pass, its own schema check, and its own deployment.

A connector with one fork per carrier repeats that pass once per fork, on the same calendar.

Fixes stop travelling between forks

A bug fixed in one fork stays fixed in one fork. The same defect resurfaces in another carrier’s data weeks later.

Shared logic diverges until nobody can say which branch holds the correct behavior.

Every branch needs a named owner

Each fork needs a maintainer who understands both the sender’s payload and that carrier’s extensions. What maintaining a Guidewire connector involves is a staffing question before it is a code question.

The pattern hits software vendors hardest. Look at underwriting workbench vendors getting submissions into a carrier’s Guidewire instance and you find one fork per customer unless the carrier-specific layer is separated from the core.

What are the options for handling carrier-specific fields?

Three approaches cover most integrations. The table compares what each one asks of the sender and the carrier, and where each one breaks.

Fork per carrier

A fork gets the second carrier live quickly. It leaves the sender with copies that start diverging on day one.

One oversized payload

The sender defines a superset of every carrier’s fields and sends flags to say which apply. Conflicting mandatory sets push exceptions into the sender’s code, and each new tenant widens the payload.

Shared core plus tenant mapping

The sender maps its payload once to a core. A tenant mapping then carries the carrier-specific fields, typelist translations, and mandatory sets.

Agency acquisitions follow the same shape, with many source systems consolidating into one Guidewire target.

How does a tenant mapping layer handle each kind of difference?

A tenant mapping layer sits between the sender’s core payload and one carrier’s Guidewire instance. It holds everything that is true of that carrier and nobody else.

Keep the core payload identical for every carrier

The core holds the fields every carrier needs, such as insured, effective dates, coverages, and loss details. It does not change per tenant.

The sender maps to it once, and every tenant reads from it.

Map extension fields and valid values per tenant

The tenant layer routes each value to the carrier’s extension field and translates typelist codes to the carrier’s own entries. Each translation states what happens to a value with no match.

Adding a carrier field means adding a mapping entry to that tenant. The sender’s connector stays untouched.

Reject gaps before they reach Guidewire

Each tenant lists its mandatory fields and valid values. A payload that misses one is rejected at the door with the field named.

The sender corrects the data before anything reaches PolicyCenter or ClaimCenter.

Apply the same layer to policy and claims data

The same tenant rules apply to policy updates as to new business, because an endorsement carries the same extension fields as the original submission.

On the claims side, claims intake into ClaimCenter carries extension fields of its own, such as carrier-specific loss codes. The tenant layer treats them the same way.

How do you test and review a tenant mapping before it goes live?

A tenant mapping decides where a carrier’s values land, so it gets the same discipline as code. Review comes first, then proof in a sandbox, then a re-check after every change.

Review every mapping with a person

An engineer reviews each mapping before it is used. The review checks field targets, typelist translations, and mandatory sets against the carrier’s own configuration.

A mapping drafted by a person and one drafted by a model get the same review.

Prove the mapping in a sandbox

The sender sends sample payloads to a sandbox that applies the tenant’s rules. Rejections show which field failed before any real submission arrives.

The carrier’s team signs off on the sample results, and only then does real data begin.

Re-check after a release or a payload change

A Guidewire release moves targets, and so does a change to the sender’s payload. Each tenant mapping runs against its saved test payloads after every change.

The routine for keeping integrations running when Guidewire or your own payload changes starts from those same test payloads.

How InsOps Helps

InsOps builds Yazh (Yaal), the InsOps Integration Gateway, for carriers on Guidewire. A sender maps its payload once, and Yazh translates it to your tenant’s Guidewire format, including your extension fields and valid values.

LiLa, our insurance-trained model, assists the mapping, and a person reviews every mapping before it is used. Yazh is a data exchange platform that rejects incomplete data against your mandatory fields.

Yazh sends inbound policy, claims, and billing data into PolicyCenter, ClaimCenter, and BillingCenter. Guidewire’s own Integration Gateway is a developer framework, and Yazh adds the sender-facing layer beside it: mapping, a self-service portal, and a sandbox with a test harness.

If you are evaluating how to take on carrier-specific fields without a connector fork per sender, contact us to talk through what this could look like for your operation.

Frequently Asked Questions

What is tenant-specific mapping?

Tenant-specific mapping is a set of rules, held per carrier instance, that routes a sender’s standard payload into that carrier’s extension fields, typelist codes, and mandatory sets. The sender’s payload stays the same across tenants.

Why does forking an integration for each carrier cause problems?

Each fork carries its own releases, fixes, and maintainer. Shared logic diverges, and every Guidewire release multiplies the regression work.

How do you handle carrier-specific fields without forking the integration?

Split the payload into a shared core and a mapping per tenant. The sender maps to the core once, and each carrier’s extension fields, valid values, and mandatory fields live in that carrier’s mapping. Review each mapping with an engineer and prove it in a sandbox before real data arrives.

What belongs in the core payload and what belongs in the tenant layer?

The core holds the fields every carrier needs. If only one carrier uses a field, such as an extension column, an extended typecode, or its own mandatory rule, it belongs in that carrier’s tenant layer.

What is the hardest part of mapping typelist values across carriers?

The same business meaning arrives under different codes, and extended typelists carry entries no other carrier has. Each value needs an explicit translation that a person reviews, including what happens to a value with no match.

What should you track to know the tenant mapping is working?

Track rejections by field and reason, sandbox pass rate per tenant, the number of tenant-specific mapping entries, and the mapping changes each release required. A falling rejection count per sender shows the mapping and the sender’s data are aligned.

How does InsOps assist with tenant-specific mapping?

Yazh uses LiLa to assist the mapping, and an engineer reviews every mapping before it is used. Tenant-specific mapping, a sandbox, and rejection of incomplete data are part of Yazh, and it never approves a mapping on its own.

What are realistic expectations for setting up a tenant mapping?

The timeline depends on how many extension fields and valid values are in scope. Start with one sender and one line of business, inventory the carrier’s extension fields and mandatory sets, then review and test before widening. The common pitfall is mapping every field up front instead of the fields the first sender actually sends.