PolicyCenter Jobs and Policy Transactions
GuidewireTraining.com faculty · Updated
Definition: In Guidewire PolicyCenter, a job is the process that carries out a policy transaction, such as a submission, policy change, renewal or cancellation. Each job works on a policy period (a version of the policy for a span of time) and moves it through quoting and binding until the change takes effect.
Jobs at a glance
| Job | What it does |
|---|---|
| Submission | Quotes and issues a new policy |
| Issuance | Issues a policy that was quoted but not yet issued (used by some lines) |
| Policy change | Changes coverage, drivers, vehicles or other details mid-term |
| Renewal | Continues the policy for a new term, usually with re-rating |
| Cancellation | Ends the policy before its expiration date |
| Reinstatement | Brings a cancelled policy back into force |
| Rewrite | Replaces a policy term with a new one, for example after a significant change |
| Audit | Calculates final premium from actual exposure (for example payroll in workers’ compensation) |
Policy, policy period and job
- Policy: the long-lived record for an insured’s policy.
- Policy period: one version of the policy for a span of time. A new term or a change produces a new period, or branch, of data.
- Job: the process that creates and moves a policy period through the transaction.
From Gosu, a job and its period are linked in both directions. For example, period.Job gives the job that owns a period.
The typical flow of a job
- Start the job (for example a submission from an account).
- Enter or change data on the job’s policy period.
- Quote: rating calculates premium, and underwriting rules may raise issues.
- Resolve underwriting issues: approvals where required.
- Bind: the transaction is accepted.
- Issue: the policy or change is put in force and downstream systems, such as BillingCenter, are notified.
Effective dating
Every job has an effective date. PolicyCenter tracks data over time, so a change effective in the middle of a term affects only the remaining part of the term, and premium is prorated. When a change is effective before a change that was already bound, it is an out-of-sequence change, and later transactions must be reconciled with it.
Why this matters on projects
Most PolicyCenter configuration (rules, PCF screens, rating and integrations) behaves differently depending on which job is running. Knowing the job types and their lifecycle is the foundation for developers, testers and business analysts alike.
Common mistakes
- Confusing Policy with PolicyPeriod. A Policy is the long-lived container; each term and each change creates or modifies a PolicyPeriod.
- Editing data on a bound policy period instead of starting a policy change job.
- Ignoring effective dates, which leads to wrong proration or out-of-sequence problems.
- Assuming a job only creates one period; quoting alternatives and preemption can create others.
Troubleshooting
- A policy period cannot be edited.
- It is probably bound or locked by its job's status. Start the appropriate job (for example a policy change) rather than editing the bound period.
- A user is warned that another job has been bound on the same policy (preemption).
- Another transaction was bound first. The open job must handle the preemption and merge or reapply its changes before it can bind.
- Premium looks wrong after a back-dated policy change.
- Check for an out-of-sequence change. Later transactions may need to be reapplied after the earlier effective date, and rating must account for both.
Related resources
Examples are simplified for learning. Check exact APIs and behaviour against the documentation for your InsuranceSuite release.