An MGA, broker, or workbench vendor sends a submission to a carrier that runs Guidewire PolicyCenter. The account has to exist first, the producer has to check out, and then the submission goes in. Each step is its own call with its own failure point.
When a call fails halfway, the sender is left with an account and no submission, or a submission tied to the wrong producer. Someone at the carrier cleans it up by hand, and the underwriter sees the file late or incomplete.
This article explains policy submission orchestration: the sequence, why one payload can drive all of it, and how to choose between building the call sequence and using a prebuilt route. It covers the Guidewire limits that shape the design and the checks that keep a bad send away from the underwriter.
What Is Policy Submission Orchestration?
Policy submission orchestration is the ordered sequence that matches or creates an account, checks the producer, and creates a submission in the policy system from a single sender payload.
The sender supplies the data once. The sequence decides what happens in what order, and what stops the send when something is wrong.
Why the order is fixed
Guidewire's Cloud API documentation states that the account that owns a submission must exist before the submission is created. The account always comes first.
Everything else in the sequence is built around that rule. A send that skips the account step fails at the submission step, and the sender learns about it only after the earlier calls have already run.
What the sender actually sends
A submission payload carries the account holder, locations, line of business, coverage content, and producer. Each sender names these fields differently from the carrier's structure.
That gap is why the payload needs mapping before it reaches Guidewire.
Why Does One Submission Take Several Calls?
A submission takes several calls because accounts, locations, contacts, and the submission itself are separate objects, and the policy system builds each one through its own request.
What Guidewire offers to cut the call count
Guidewire's Cloud API documents three ways to reduce calls: composite requests, request inclusion, and Graph API endpoints. Composite requests chain several calls into one request.
The Graph API goes further. It builds an entire account or submission in a single call, and the documentation shows it running inside a composite request to create, quote, bind, and issue a submission.
Where the limits sit
In the base configuration, a composite request holds up to 100 subrequests. Request inclusion does not work inside a composite request.
Document uploads stay outside it too, because documents use multipart/form-data. A sender whose payload includes documents sends those separately.
Where a hand-chained sequence breaks
Three failures repeat across senders. The calls run in the wrong order, the producer code does not match the carrier's records, or a field arrives in a shape Guidewire does not expect.
Each one surfaces as an error at the end of the chain, far from where it started. The sender then reads a response code and guesses which of the earlier calls caused it.
How Does One Payload Carry the Account and the Submission?
The sender's data already holds the account holder, locations, and risk details, so one payload feeds both calls once each field is mapped to the right place.
The one-payload path
The path has four steps. Each one exists to stop a specific failure before it reaches an underwriter.
Step | What happens | What it prevents |
|---|---|---|
1. Account match | Search for the account. Create it only if no match exists. | Duplicate accounts |
2. Producer check | Confirm the producer code against the carrier's records. | A submission rejected at the last step |
3. Field mapping | Match each payload field to the field Guidewire expects. | Data landing in the wrong field |
4. Submission create and log | Create the submission under the account. Record the request, response, and any error. | Silent failures and untraceable errors |
Why mapping is the step that stalls
Payload mapping matches each field in a sender's data to the field Guidewire expects, so a submission lands in the right place on the first send.
The other three steps are short and repeat the same way every time. Mapping changes with every sender, every line of business, and every carrier setup.
Why the log matters
Whichever route a sender uses, the request log lets a carrier trace a failed send to a single field. Without it, support teams trade emails and screenshots to find the same answer.
Should You Build the Call Sequence or Use a Prebuilt Route?
Build when one carrier, one stable payload, and a dedicated engineering team describe your situation. Use a prebuilt route when you serve several carriers or your payload changes.
Hand-built call sequence | Prebuilt route with mapping review | |
|---|---|---|
Guidewire logic | Written by the sender's engineers | Already built, configured by the sender |
Mapping | Written and maintained in code | Drafted from the sender's payload, confirmed by a person |
Upkeep | Every Guidewire and carrier upgrade | Held by the route provider |
Multiple carriers | One build per carrier setup | One payload, mapped per carrier |
Best fit | One carrier, stable payload, engineers on hand | Several carriers, changing payloads, a small team |
Three questions that settle it
How many carriers on Guidewire does the sender serve?
How often does the payload change?
Who owns the call sequence after the first release?
Carriers weigh the same trade each time a new sender arrives. The case for standardized API gateways over point-to-point builds comes down to that repeated cost.
Why the receiving side cares
Clean data at intake matters most to the underwriter. Carriers adopting insurance AI for underwriting need senders to deliver complete, correctly mapped submissions in the first place.
How InsOps Helps
InsOps builds an insurance-trained AI that assists with moving submission data into Guidewire. LiLa, our insurance-trained LLM, drafts the field mapping from your payload to the Guidewire structure, and a person on your team reviews and confirms every mapping before data moves.
The InsOps Integration Gateway gives MGAs, brokers, and underwriting vendors a prebuilt route into Guidewire PolicyCenter. Senders register in a self-service portal, bring their payload, and configure it without building their own connector. The gateway runs inside your own environment, so PII and PHI stay in controlled infrastructure.
For a submission, the sender checks the producer code first, then sends. A dashboard records every request, response, and error. InsOps is a Guidewire technology partner.
If you are evaluating how to exchange submission data with Guidewire without a custom connector build, contact us to talk through what this looks like for your operation.
Frequently Asked Questions
What is policy submission orchestration?
It is the route a sender follows to get an account and a submission into the policy system: match the account, check the producer, then create the submission, all driven by one payload.
Why does the account come before the submission?
The submission belongs to an account, so the account has to exist before Guidewire accepts the submission. A send that skips that step fails.
How do composite requests help?
They chain several calls into one request, which cuts round trips between the sender and the carrier. A cap on subrequests applies, so a large account with many locations needs a plan for splitting the work.
What are the common challenges?
Field mapping is the largest, because every sender names fields differently. Producer code errors and incomplete payloads come next, and both are cheaper to catch before the send than after.
What should we measure?
Track first-send success rate, errors by field, and time from receipt to a created submission. Errors concentrated in one field point to a mapping fix, not a process problem.
How does the InsOps Integration Gateway help?
It gives senders a prebuilt route into Guidewire PolicyCenter, with LiLa drafting the field mapping from the sender's payload. A person at the sender reviews and confirms every mapping before data moves.
What does a realistic rollout look like?
Start with one line of business and one carrier setup, then confirm the mapping and run test sends. The work scales with the number of mapping decisions, not the number of calls.
Who owns the sequence after go-live?
The sender owns payload quality, and the carrier owns the Guidewire configuration. Both sides need a shared request log and a named contact for mapping changes.