[Silthus]

Problem

A Workflows follow-up email for people who pick Workflows during onboarding links to the Workflows empty state, where suggested workflows are built from the project's events.
Those suggestions only appear when the organization approves AI data processing.
The user showed product intent event does not say whether the org approved it, so the email cannot leave out orgs that opted out, and those orgs would land on an empty state with no suggestions.

Impact

Pays into Grow Workflows through Started orgs (first hog_flow_created per org). Expected move: medium, up, through the onboarding follow-up workflow this property gates.

Note

🔵 Merge risk: low · two-way door (merge-risk rubric)

• Adds one boolean property to an internal analytics event. Events already captured keep it after a revert, which is harmless.
• No API, schema, or customer-facing change. Focused API and model tests cover approved and opted-out orgs.

Changes

• user showed product intent now carries is_ai_data_processing_approved: true only when the organization's setting is True, false for opted-out or unset orgs.
• Nothing a user sees changes. The property exists so workflows and insights can filter on it.
• The property records consent, not full eligibility for suggestions. Suggestions also need the workflows-data-suggestions flag, a configured suggestion model, and an org outside PostHog AI privacy mode. Recording consent alone keeps the property accurate for other uses.
• The value is a snapshot from the moment of the intent. An org that opts out later, for example by signing a BAA, still carries true on that event.
• Events captured before this change, or after a revert, have no such key. Filters should match = true, so a missing key counts as not approved.

How did you test this code?

• Test seam: the add_product_intent API endpoint and ProductIntent.register, observed through the captured event properties.
• Extended test_can_add_product_intent with approved, opted-out, and unset (NULL) orgs. Watched the first two fail before the change and pass after. The unset case fails when the raw field is passed through and passes with the is True mapping.
• Added the new key to the exact-match property assertions in test_product_intent.py and test_can_update_product_intent_if_already_exists.
• Live run on the rebased commit: started the Django dev server with self-capture pointed at a local sink, then called PATCH /api/environments/:id/add_product_intent/ with a personal API key for three test orgs. The captured user showed product intent events carried is_ai_data_processing_approved: true for the approved org (an intent that already existed before the call), and false for the opted-out org and the org that never answered (both new intents).
• Rebased onto master on 2026-10-20. Ran the 79 product intent tests in posthog/api/test/test_team.py and posthog/models/test/test_product_intent.py on the rebased branch: all pass. ruff check, ruff format --check and mypy on the touched files are clean.

Test rationale: if the property is dropped or computed from the wrong source, the follow-up workflow would email opted-out orgs. The closest existing test, test_can_add_product_intent, already asserted the full property set, so it gained three parameterized cases (approved, opted-out, unset) rather than a new test.

Gaps:

• Backend CI: Backend CI on Depot / Django Tests Pass on Depot fails by design for this fork PR. Its first step refuses fork pull requests, and no backend tests run. Per the fork pull request handbook, a PostHog engineer re-creates the change on an in-repo branch after review to get the required run.
• Prod shape: not measured. The share of orgs with consent False or NULL in production needs read-only Metabase access, which is not available yet.

Release status

• No feature flag controls this change

Docs update

None.

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Agent: Claude Code, Claude Opus 5.5

• Skills: impact, tdd, /writing-tests, merge-risk, pr-description, writing-voice.
• No duplicate: an open-PR search for the property and product intent found nothing related.
• No session material beyond public repository context is in this PR.

Question	Answer	Who	Where
Which orgs get the follow-up	Only orgs that approved AI data processing, the main gate for suggestions	👤 Human	pending approval
Privacy mode as a second gate	Left out: a hand-picked per-org flag new onboarding orgs rarely carry, tracked as a known gap	🤖 Agent	pending approval
Where the consent signal lives	A property on the intent event, a snapshot at intent time, rather than an org group property that needs a sync and a backfill	🤖 Agent	pending approval
Cross-version proof	Not owed: the event gains one key in a schemaless property bag, and nothing in the repo parses it	🤖 Agent	pending approval

Open: should the follow-up re-check consent when it sends, so orgs that opt out after picking Workflows are left out? Recommendation: not in this PR. It needs consent synced to the organization group properties first. Keep the intent-time snapshot and revisit it if the follow-up delay grows beyond a few days.

Involvement: no grilling rounds, no prototypes. One cross-model review round before the rebase (GPT-6.1 Sol, nothing blocking). Rebased onto master on 2026-10-20 with no code changes. QA swarm round 1: Correctness, Risk, Design, Systems and three Team perspectives on GPT-6.1 Sol, and Fresh eyes on Opus 5.5. It added the unset-consent test and these description fixes. Round 2 (Fresh eyes on Opus 5.5, on the fix) found one description nit, fixed. Parameter Sentinel found nothing. stamphog stayed silent, and CodeRabbit is not active on this repository. A live run was captured.

🤖 Generated with Claude Code

[trunk-io]

Merging to master in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

[parameterai]

Risk: No findings

The increment since the last review only extends the test_can_add_product_intent parameterization with an unset-consent case (None → False); the production change (one boolean property on the internal user showed product intent analytics event) is unchanged and carries no security impact.

_{Sentinel reviewed ad5e6b6 · Review settings}