Workflows: add MCP filter parity for account property triggers

Workflows: add MCP filter parity for account property triggers

Parent

• Parent issue: #73512
• Delivery step: Follow-up parity

Parent user story

As a workflow editor, I can open and edit an account property changed trigger created through MCP, so that visual edits never change its meaning.

Outcome of this step

The visual editor represents every valid filter shape that MCP can save for an account property changed trigger, or preserves unsupported input without rewriting it.

Starting state

The trigger editor supports the main account-property workflow:

• Each selected property is an OR branch.
• Conditions within a property branch are ANDed.
• current_value uses the selected custom property's text, numeric, boolean, date, or select type.
• Legacy top-level property filters upgrade to grouped event filters when edited.

The API remains more expressive. MCP can create duplicate branches for one property, multiple conditions per branch, global properties, non-exact property-name conditions, and additional event or action filters.

Verified against a230683347e on August 14, 2026.

Scope

• Represent every $account_custom_property_changed event entry as an ordered OR branch, including duplicate property branches.
• Allow multiple ordered AND conditions inside each branch.
• Derive the current_value editor type when a branch has one exact property_name condition.
• Use an untyped value editor when the property type cannot be determined safely.
• Expose top-level properties as conditions that apply to every branch.
• Represent additional event and action filters accepted by the workflow API in an advanced section.
• Preserve ordering, operators, filter types, and values across open, edit, save, and refresh.
• Detect malformed or unsupported input and prevent a destructive rewrite.
• Document the same logical model for MCP authors and the visual editor.

Out of scope

• Adding new filter semantics to the workflow API.
• Supporting nested logical groups that the workflow API does not accept.
• Redesigning the generic event trigger editor.
• Migrating stored workflows that already use valid filter shapes.

Additive design

Keep the current property-focused editor as the default path. Add branch controls and an advanced section only when the saved configuration needs them.

Existing simple triggers must retain their current layout and behavior.

Acceptance criteria

• The editor displays every valid filter accepted by the account property changed trigger API.
• Duplicate branches for the same property remain distinct after saving.
• A branch can contain multiple value conditions without losing or combining them.
• Top-level filters remain global after any branch edit.
• Additional event and action filters remain editable or explicitly read-only.
• Opening and saving an MCP-authored workflow without changes produces an equivalent filter expression.
• Unsupported input shows a clear warning and cannot be overwritten accidentally.
• The simple one-property experience remains concise.
• Existing project and workflow permissions continue to govern access.

Test setup

• Enable customer-analytics-roadmap and customer-analytics-csp.
• Create account custom properties covering text, numeric, boolean, date, and select types.
• Create draft workflows through MCP with simple, duplicate-branch, multi-condition, global-filter, and advanced event/action configurations.
• Use a project member who can edit workflows and view customer analytics accounts.

UI testing

User journey: edit an MCP-authored advanced trigger

1. Open a draft workflow created through MCP.
2. Select the account property changed trigger.
3. Review each OR branch and its AND conditions.
4. Edit one condition without changing the other branches.
5. Save and refresh the workflow.
6. Run matching and non-matching test events for every branch.

Expected result:

• Every MCP-authored condition is visible.
• The edited condition persists after refresh.
• Unedited conditions retain their operators, values, ordering, and scope.
• Test events follow the same branches before and after the visual edit.

User journey: protect an unsupported configuration

1. Open a workflow containing a malformed or unsupported filter shape.
2. Select the trigger and attempt an edit.

Expected result:

• The editor identifies the unsupported configuration.
• The editor does not silently normalize or remove any filter.
• The user can leave without changing the stored workflow.

Automated tests

• Pure round-trip tests for every supported logical shape.
• Component tests for duplicate branches, multiple conditions, global filters, and unsupported-state protection.
• API tests comparing compiled filter behavior before and after UI serialization.

Dependencies

• Blocked by: None
• Blocks: None
• Can run in parallel with: Other #73512 follow-ups
• Native GitHub relationships: Not applicable

Rollout and production verification

• Keep the editor behind customer-analytics-csp.
• No data migration is required.
• Verify existing simple and MCP-authored workflows before broadening access.
• Roll back the editor change without modifying stored workflow filters.

Start at the account property changed trigger editor and the workflow API serialization path, then review the existing simple property-focused flow. Use round-trip, component, and API tests for duplicate branches, multiple conditions, global filters, and unsupported-state protection; done means MCP-authored filters survive open, edit, save, and refresh without destructive rewriting.