Write FEEL expressions for APD advanced rules

APD advanced rules with FEEL expressions deliver edition-aware validation and availability outcomes across fields and coverages. APD advanced rules reduce custom scripting and keep product logic in APD. Use advanced rules in APD to define complex, edition-aware validation and availability logic using FEEL expressions, enabling cross-field, cross-coverage, and collection-based rules beyond the capabilities of Basic mode. For information about FEEL, see the DMN FEEL handbook.

Note: Use advanced rules when you need logic that would previously have required custom scripting. Continue to use Basic mode for straightforward, single-field constraints. Advanced rules are disabled by default, but can be enabled on a per tenant basis. Contact Guidewire to enable advanced rules.

APD supports an advanced rules mode, allowing you to define complex validation and availability logic using FEEL expressions. In the Rules dialog, you can choose between:

Basic Conditions - A guided condition builder for simple field-level rules, such as required fields, minimum and maximum values, and availability.
Advanced Conditions - A FEEL editor for defining cross-field, cross-coverage, and collection or aggregation logic that exceeds the capabilities of Basic mode.

With advanced rules, you can:

Express rich validation rules, such as "If coverage A limit is changed, adjust or validate coverage B limit" or "Require at least one item in a schedule to meet a condition."
Implement advanced availability logic that depends on multiple coverages, terms, or risk attributes, including rules that traverse schedules and nested structures.
Use APD as the single source of truth for product rules, with FEEL-based expressions stored with editions and executed at runtime by the Guidewire rules infrastructure.

Advanced mode provides a FEEL text editor with awareness of APD product model fields. Existing rules remain fully compatible, and there is no forced migration of current configurations.

For example, you can write the following FEEL expression in APD:

(some risk in TSTLine.RulesTestCoverable satisfies
  risk.IntegerField between 1 and 7 and date(risk.DateTimeField) >= today() - duration("P6M") and 
  some childRisk in risk.RulesTestGCCoverables satisfies
    starts with(childRisk.name, "TargetName")) and count(TSTLine.ConfiguredCoverable) > 0 and 
every risk in TSTLine.ConfiguredCoverable satisfies count(risk.ConfiguredOneToOnes) = 1

APD also provides AI-powered rules authoring which enables you to:

Describe the rule intention in natural language and have AI generate the FEEL expression.
Select an existing FEEL rule to get a natural-language explanation, plus use a Rules Chat Assistant to explore, add, or modify rules.

Use FEEL expressions in APD rules examples

APD FEEL expression examples help product designers build advanced rules faster and validate policy data consistently. Examples cover validation, availability, date logic, collection conditions, and nested child traversal.

Validate coverable fields with FEEL expressions in APD

Require a reason when a deductible is unusually high:

PolicyLine.DeductibleAmount > 10000
and is blank(PolicyLine.DeductibleJustification) = false

Use this as a validation rule so that if the deductible exceeds 10,000, the justification field must be populated.

Validate cross-coverage consistency with FEEL expressions in APD

Keep UM/UIM BI limits in sync with BI:

UMUIMCoverage.Limit <= 2 * BICoverage.Limit

This works as a validation rule on the UM/UIM coverage term to enforce

UM/UIM
                    limit must be less than or equal to 2x BI limit

Check collection at-least-one conditions with FEEL expressions in APD

Require at least one scheduled item that meets a condition:

some item in TSTLine.ScheduledItems satisfies
  item.Covered = true

Used for availability or validation on a coverage that only makes sense if at least one qualifying item exists.

Validate dates with durations in FEEL expressions in APD

Require a date field within the last 6 months:

date(Risk.DateTimeField) >= today() - duration("P6M")

Attach this as a validation rule to enforce that the captured date is not older than six months.

Traverse nested child objects with FEEL expressions in APD

Check child risks under a parent risk:

some childRisk in Risk.ChildRisks satisfies
  starts with(childRisk.Name, "TargetName")

Combine with other conditions, for example:

some risk in TSTLine.RulesTestCoverable satisfies
  risk.IntegerField between 1 and 7
  and date(risk.DateTimeField) >= today() - duration("P6M")
  and some childRisk in risk.RulesTestGCCoverables satisfies
        starts with(childRisk.Name, "TargetName")

Apply every constraints to collections with FEEL expressions in APD

Ensure every configured item has exactly one child:

every risk in TSTLine.ConfiguredCoverable satisfies
  count(risk.ConfiguredOneToOnes) = 1

This is useful for enforcing structural constraints on schedules.

Control availability by job type with FEEL expressions in APD

Make a coverage unavailable for specific job types:

Job.JobType != "Renewal"
and Job.JobType != "Submission"

Attach as an availability rule so the coverage is only available on other job types, for example policy change.

Known limitations of APD advanced rules

APD advanced rules (FEEL) are designed to centralize product-centric validation and availability logic in APD. They are not a full replacement for PolicyCenter validation/underwriting rules or Guidewire Rules Service. Use APD to describe what must be enforced on the product; use PolicyCenter or Rules Service to control how those rules surface as errors, decisions, and workflows.

Data graph and scope limitations in APD advanced rules

Advanced rules operate within a constrained view of the APD product graph:

Traversal is upward only. A rule attached to a field, clause, or coverage can reference its parent risk object and ancestors (line, product), but cannot traverse down into children.
No sibling access. Rules cannot reference fields or clauses on sibling coverables or sibling risk objects. Cross-sibling logic must be implemented in PolicyCenter rules or Rules Service.
APD schema only. Advanced rules see the APD product model (products, lines, risk objects, coverages, coverage terms, some core fields). Data outside this schema – such as producer, billing type, schemes, or external partner data – must be handled in PolicyCenter validation/UW rules, Rules Service, or Functions.

If a rule requires data that is not part of the APD product schema, assume the authoritative implementation belongs outside APD, with APD providing only product-centric conditions or selectors.

Rule types for APD advanced rules

APD advanced rules are optimized for certain rule categories and intentionally avoid others.

Rule types that fit APD advanced rules:

Field usage and basic validation: requiredness, hidden/implicit default, min/max, simple value checks.
Cross-field and cross-coverage checks within the allowed APD graph (for example, relationships between terms on the same line or within a risk hierarchy).
Collection and aggregation checks, such as at-least-one, none, count, or sum.
Edition-aware product rules where conditions drive availability or behavior by jurisdiction, effective date, or other selectors.

Rule types that do not fit APD advanced rules:

Large decision tables and complex multi-outcome decisions. These are better modeled as DMN decision tables in Guidewire Rules Service or in PolicyCenter rule sets.
Procedural or side-effect-heavy logic, such as calling external services, mutating non-product state, or orchestrating workflows. These belong in PolicyCenter Gosu, Functions, or Rules Service, not in FEEL expressions.
Legacy Product Designer scripts that depend on deep policy graph traversal or external integration classes. Many of these can be partially converted (conditions in APD, effects in PolicyCenter), but not fully replaced by FEEL.

Advanced rules are the central product-rules layer. Keep underwriting, workflow, and integration logic in PolicyCenter or Rules Service.

Execution model and error-handling constraints for APD advanced rules

The way advanced rules execute and report errors has important limitations for channel and API design.

Boolean outcomes only. Advanced rules evaluate to true or false and drive validation or availability outcomes. They do not natively emit structured error codes, paths, or rich payloads.
Fail-fast evaluation. APD validations typically stop at the first failing rule, rather than accumulating all failures across a rule set.
No first-class error contract. Error messaging from APD rules is intended to be human-readable; contract-grade error structures for headless flows need to be defined in PolicyCenter validation/UW rules, Rules Service, or an error-wrapping layer.

For headless flows, omnichannel error handling, or strict API contracts, for example return all errors with codes in one response, APD must not be the only enforcement layer. Use APD to define product rules, and rely on PolicyCenter or Rules Service to generate structured errors and aggregate results.

Platform and API exposure limitations for APD advanced rules

Several aspects of advanced rules and FEEL exposure are gated or evolving.

Feature flags. Advanced rules are disabled by default and must be explicitly enabled per tenant via configuration or Helios settings.
FEEL in entity schemas. Exposing FEEL expressions via /entity-schemas (for example, using the rulesLanguage=FEEL parameter) is controlled by a configuration flag and is incomplete or experimental in previous releases. Behavior and payload shape can change across releases.

Do not treat FEEL-in-schemas and some advanced rules runtime surfaces as long-lived external contracts without confirming current release status, flags, and support posture.

Extensibility and function support in APD advanced rules

Advanced rules run on top of a curated FEEL engine and function profile.

Curated function set. Only functions explicitly exposed by the engine (for example, validation helpers and selected custom functions) are available to authors. There is no general-purpose "call any Gosu" capability from FEEL.
No self-service function authoring. You cannot define new FEEL functions from APD. Adding or changing functions is an engineering activity, not part of configuration.
External calls belong elsewhere. Service calls, data enrichment, and complex calculations that require external context must live in Functions, PolicyCenter rules, or Rules Service, potentially combined with APD conditions.

When solution designs require function-level extensibility, plan to combine APD conditions with external rule engines or function layers instead of pushing everything into FEEL.

Known gaps and edge cases in APD advanced rules

Guidewire is aware of the following gaps in APD advanced rules:

No cross-coverable ordering. APD supports priority within a coverable or line, but cannot define a single global priority list across coverables (for example, mixing line-level and dwelling coverages on one screen). UI-layer sorting or PCF overrides are still required when a single, merged list is needed.
Sibling coverable rules. Rules cannot reference sibling coverables. Patterns that rely on sibling visibility need to be redesigned or moved to PolicyCenter rules or Rules Service.
Error expectations. APD centralizes product logic but still relies on downstream layers for error contracts, aggregation, and workflow decisions.