feat(growth): real-time signup enrichment workflow

[MattBro]

Problem

The enrichment core (PR A) has no caller. This adds the real-time seam: a fire-and-forget Temporal workflow started right after signup, so onboarding can route on firmographic data. It must never block or fail signup.

Changes

• posthog/temporal/signup_enrichment/workflow.py — SignupEnrichmentWorkflow + enrich_signup_organization_activity. The activity awaits the PR A core (enrich_organization), builds and emits the write-once snapshot, and captures a signup_enrichment_completed signal (success + which fields filled). Hard 90s per-attempt timeout, a couple of retries then it gives up quietly.
• posthog/temporal/signup_enrichment/trigger.py — start_signup_enrichment_workflow, the single guarded entry point. Kill switch, US-only for v0, requires a Harmonic key, dispatches via sync_connect inside transaction.on_commit, and never raises. Records the work_email signal (via PR A's record_signup_work_email, savepoint-guarded) for every signup; personal-email domains skip only the provider lookup, so the work-vs-personal bit is still available to consumers for them.
• posthog/api/signup.py — one call after report_user_signed_up. No request/response or validation change.
• Worker registration on GENERAL_PURPOSE_TASK_QUEUE (where the other enrichment activities already live).
• GROWTH_SIGNUP_ENRICHMENT_ENABLED — the kill switch, off by default.

Warning

Launch observability is a ship gate. The signup_enrichment_completed event (property success, and fields_filled on success) is the fill-rate/failure signal. An alert on its failure rate, routed to #alerts-growth, must exist before GROWTH_SIGNUP_ENRICHMENT_ENABLED is turned on anywhere. The switch stays off in this PR. I could not create that alert from here (it's runtime config in a growth-owned project with the Slack routing), so it's an explicit pre-enable step, not code.

Snapshot wiring decision (resolving #69411's two open questions)

• Claim-then-emit, at-most-once: kept as-is. The org-keyed guard row is claimed before capture(), so retries of this fire-and-forget activity never double-emit.
• Guard row org-keyed, survives person deletion: kept as-is. The activity emits after enrichment completes, building the snapshot from the enriched fields with a fallback to the deterministic company type, threading the signing-up user's distinct_id through the workflow inputs.

Timing / safe default

The work_email signal is written synchronously in-request, so it's always present for onboarding's first read. The Harmonic write is async and often lands after that first read, so any consumer must treat enrichment as best-effort and degrade to a safe default when the record is missing or partial.

Note

No ALTER on the organization table. The only new model is EnrichmentSignupSnapshot (a CreateModel extension table), and it comes from #69411, not this PR.

How did you test this code?

Automated tests, all run locally (the full signup-enrichment + growth-enrichment suite, 201 passing including the DB-backed cases):

• test_trigger.py — dispatches for a US work-email signup and records work_email=True; personal-email domains record work_email=False without a provider dispatch; never dispatches (or writes) when the kill switch is off; never dispatches when the Harmonic key is missing or the region isn't US; a work_email write failure is captured and does not block dispatch.
• test_activity.py — success emits the signal + snapshot built from enriched fields; a provider miss falls back to the deterministic company type; a failure emits a failure signal and re-raises. Uses ActivityEnvironment with the DB/provider boundaries mocked.

ruff and tach check pass.

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Authored by Claude via PostHog Code, driven by @MattBro from a Slack thread. Invoked the /improving-drf-endpoints skill before touching the signup serializer (confirmed the change is a side effect, not a schema change, so no new annotations were needed).

Decisions for review:

• Guards centralized in trigger.py so the serializer stays a one-line call and the fire-and-forget contract lives in one place. Modeled on products/slack_app/backend/signals.py and enrich_view_semantics.py.
• General-purpose task queue rather than a new dedicated queue, to avoid deploy-time worker plumbing for a low-volume, best-effort workflow.
• Alert as a documented pre-enable gate rather than code, since it's runtime config with Slack routing.

Note

Stacking. This PR is based on PR A and also depends on #69411 (snapshot helper). Because #69411 isn't merged yet, its files (snapshot.py, EnrichmentSignupSnapshot + migration 0003, test_snapshot.py, idor coverage) are cherry-picked in as a separate commit so this branch builds and tests standalone. Review those in #69411, not here; they collapse out on rebase once it merges.

Merge order: #69411 → PR A → PR B (this). The routing-fallback PR (former PR C) was cancelled along with the classifier PR; company type now arrives as enrichment data instead of a maintained list.

FYI @abhischekt.

---

Created with PostHog from a Slack thread

[trunk-io]

     

View Full Report ↗︎ ⋅ Docs

[greptile-apps]

_{Reviews (1): Last reviewed commit: "feat(growth): record work_email for ever..." | Re-trigger Greptile}

[veria-ai]

Medium: Untrusted signup work uses a shared task queue

A successful unauthenticated signup can enqueue an enrichment activity that holds a worker slot for up to 90 seconds, while this queue also processes unrelated operational workflows. An attacker can create accounts with arbitrary unverified work-domain emails from rotating IPs to consume shared worker capacity; route this workflow to a dedicated queue with bounded concurrency or add a separate dispatch quota before enabling it.

[rafaeelaudibert]

This is probably fine for now, but we need a TODO to eventually move away from this and into our own specific enrichment queue

[MattBro]

Added the TODO in 8ef676c.

[MattBro]

Routed to a configurable queue in 94f98f9: dispatch reads SIGNUP_ENRICHMENT_TASK_QUEUE and the worker registers these workflows under a dedicated landing-zone queue. Default stays on the general-purpose fleet so dispatch always has a live worker; at enable time the env flips this to a dedicated, separately-scalable queue once a charts worker consumes it.

[MattBro]

Turned this into a config seam in 94f98f9: SIGNUP_ENRICHMENT_TASK_QUEUE env flips dispatch onto a dedicated queue once a worker exists, defaulting to general-purpose until then.

[veria-ai]

PR overview

This pull request adds a Temporal-based real-time signup enrichment workflow for growth, triggering organization enrichment around signup and performing a delayed recheck. The changed code wires signup events into the enrichment workflow and persists or emits enrichment-related results.

There are still two open security concerns. The main risk is that unauthenticated signups can dispatch enrichment work onto a shared Temporal task queue, allowing an attacker to consume worker capacity used by other operational workflows. A second issue remains around delayed rechecks writing enrichment data or analytics after an organization has been deleted. One issue has already been addressed, but the remaining items should be resolved before rollout.

Open issues (2)

• Medium: Untrusted signup work uses a shared task queue — posthog/temporal/signup_enrichment/trigger.py:82
• Medium: Recheck writes data after organization deletion — posthog/temporal/signup_enrichment/workflow.py:159

Fixed/addressed: 1 · PR risk: 6/10

[github-actions]

🤖 CI report

✅ Playwright — all passed

All tests passed.

View test results →

ℹ️ ClickHouse migration SQL — 1 migration(s)

ClickHouse migration SQL per cloud environment

• unset
  • all

    DROP TABLE IF EXISTS property_values_mv

    CREATE MATERIALIZED VIEW IF NOT EXISTS property_values_mv
    TO property_values
    AS SELECT
        team_id,
        property_type,
        property_key,
        property_value,
        property_count,
        coalesce(_timestamp, now()) as last_seen
    FROM posthog_test.kafka_property_values

• US, EU
  • aux

    DROP TABLE IF EXISTS property_values_mv

    CREATE MATERIALIZED VIEW IF NOT EXISTS property_values_mv
    TO property_values
    AS SELECT
        team_id,
        property_type,
        property_key,
        property_value,
        property_count,
        coalesce(_timestamp, now()) as last_seen
    FROM posthog_test.kafka_property_values

• DEV
  • data

    DROP TABLE IF EXISTS property_values_mv

    CREATE MATERIALIZED VIEW IF NOT EXISTS property_values_mv
    TO property_values
    AS SELECT
        team_id,
        property_type,
        property_key,
        property_value,
        property_count,
        coalesce(_timestamp, now()) as last_seen
    FROM posthog_test.kafka_property_values

[MattBro]

Two additions since the approval, both from review threads: 94f98f9 makes the task queue configurable (veria's shared-queue finding; dispatch defaults to general-purpose, one env var flips dispatch + worker registration to a dedicated queue), and 1e885fa adds a one-shot delayed recheck when Harmonic doesn't match at signup (from Mine's review on the core PR): the workflow sleeps 4h on a durable timer and looks once more, since the enrich mutation seeds Harmonic's async enrichment for unknown companies. The launch signal still reads only the first attempt; the recheck emits its own signup_enrichment_recheck event. Tests cover both.

[veria-ai]

Medium: Recheck writes data after organization deletion

An organization owner can delete the organization during this four-hour delay, but the recheck still calls enrich_organization and emits an event without revalidating that the organization exists. Because OrganizationEnrichment.organization has db_constraint=False, a successful lookup can also create an orphaned enrichment row after deletion. Cancel this workflow as part of organization deletion, or verify that the organization exists and is not pending deletion immediately before each persistence and analytics write.

[MattBro]

Fixed in ca80350: the recheck verifies the org still exists before doing anything; a deleted org gets a logged skip, no writes, no events.

[greptile-apps]

_{Reviews (2): Last reviewed commit: "Merge remote-tracking branch 'origin/pos..." | Re-trigger Greptile}

[deployment-status-posthog]

Deploy status

Environment	Status	Deployed At	Workflow
dev	✅ Deployed	2026-07-14 19:18 UTC	Run
prod-us	✅ Deployed	2026-07-14 20:14 UTC	Run
prod-eu	✅ Deployed	2026-07-14 20:17 UTC	Run