Summary:
Enable algorithms to reference/call the Proposal Type field in Proposal Properties, so users can tailor logic based on the type of proposal being processed.
Problem Statement:
Users who need algorithm behavior to vary by proposal type—such as Services (Rate Builder) versus another proposal type—must create and maintain a separate manual flag. This adds unnecessary setup, introduces the risk of inconsistent configuration, and can cause algorithm logic to be applied incorrectly.
Proposed Solution:
Allow algorithm conditions and expressions to reference the Proposal Type field from Proposal Properties.
Support conditional logic based on the selected proposal type (for example, IF Proposal Type = Services/Rate Builder).
Use the existing Proposal Type value as the source of truth so no additional manual flag is required.
Ensure the field is available wherever algorithm logic currently supports proposal-level property references.
Benefits:
Reduces manual configuration and maintenance for proposal-specific algorithms.
Improves consistency by using an existing proposal property as the source of truth.
Enables more flexible, accurate algorithm behavior across different proposal types.
