[Silthus]

Problem

• The Workflows team counts workflow creation with the user event hog_flow_created. Only the API create view and premade data-suggestion saves (#119724) emit it.
• Workflows created any other way never count: generated data-suggestion drafts that a Celery task saves for PostHog AI, transactional email workflows (#122019), and plain ORM writes.
• So a per-team or per-organization creation count misses every creation that skips those two code paths.

Impact

Closes a gap in two Grow Workflows leading metrics: Started orgs (organizations whose first workflow creation falls in the month) and activation rate (the share of started orgs whose first billed action comes within 30 days of that creation). Both are defined on the first hog_flow_created, so an organization whose first workflow came from an accepted data-suggestion draft or a transactional email workflow is counted late or never. Once these metrics read workflows workflow created, they count every creation path. Expected move: no change in product usage; Started orgs stops undercounting, and activation rate is measured from the real first creation.

Merge Danger

Note

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

• Every committed workflow creation now runs one narrow team lookup and one analytics capture after commit, on a dedicated client that flushes before returning.
• The capture sits in a try/except behind on_commit, so it never fails or rolls back a creation. Reverting removes the event and nothing else; events already sent stay sent.

Changes

Kind	Files	Lines
Production	1	+30 −1
Tests	1	+63 −2

• Analysts can count each committed workflow creation with the team event workflows workflow created, whatever path created it.
  • Properties: workflow_id, origin_product, actions_count. The event carries the project and organization groups.
  • API and premade creations emit both events. Count teams and organizations with workflows workflow created; keep hog_flow_created for user and channel attribution.
• The HogFlow post_save receiver queues the capture with transaction.on_commit on the signal's own connection.
  • Updates emit nothing. A rolled-back creation emits nothing.
• The capture goes through ph_scoped_capture, which flushes on exit. The global client can lose events in a Celery worker (AGENTS.md forbids it there), and the generated data-suggestion save runs in one.
  • The scoped client sends only in cloud run modes, so self-hosted and plain local dev emit nothing. Local E2E mode counts as cloud and sends events tagged region: E2E to the US project, so per-team counts should filter region to US and EU.
  • The event carries the instance region (US or EU) as its region property, like events from the global client.
• A failed team lookup or capture logs an exception and never fails the creation.
• Nothing user-visible changes.

Recreates Silthus/posthog#358, originally #111727 (closed).

How did you test this code?

Test rationale: four cases in the existing TestHogFlow model tests, at the model seam every creation path passes.
They catch a duplicate event on update, a capture before commit, wrong groups or properties, a wrong region, a capture after rollback, and an analytics failure that breaks creation.
The existing receiver tests cover only worker reloads. The tests patch ph_scoped_capture, as the repo's other scoped-capture callers do.
The first version of these tests failed before the receiver existed and passed after it. Swapping event_region= for region= fails the region case.

Live run at b170c9c, through the real DRF API with a logged-in Django test client against an isolated local database. posthog.ph_client.is_cloud was forced to True, and Posthog.capture was replaced by a recorder, so nothing reached PostHog Cloud:

Step	Events
PATCH a workflow written before this change	0
POST a new workflow (origin_product: broadcasts, one action)	1
PATCH the new workflow	0
ORM create outside the API	1

Both events carried the team's UUID as distinct_id, the project and organization groups, the right properties, and went to the scoped client for us.i.posthog.com. The global client saw no creation event.

Lane gate, run locally on b170c9c: ruff, ty check, mypy on the two changed files, products/workflows/backend/test/test_hog_flow.py (10 passed), the repo guard tests in posthog/test/repo_invariants (289 passed), lint-imports, and hogli ci:preflight --strict (0 failures).

Gaps:

• CI has not run: every GitHub Actions workflow waits for a maintainer to approve this fork PR, and Depot's Django job refuses fork PRs.
• Not run: repo-wide mypy and the full backend suite.
• Delivery to PostHog analytics is unverified; the live run stops at the SDK client.
• The Celery data-suggestion save was not live-run; it reaches the same receiver as the ORM create above.
• Production shape is unmeasured until read-only production access arrives on 2026-11-02: the share of creations per path and the spread of origin_product and actions_count.

Release status

• No feature flag controls this change

Docs update

None. No existing doc covers Workflows analytics events.

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Agent: T3 Code with Claude Code, Claude Opus 5.5 (claude-opus-5-5). An earlier Codex worker (GPT-6.1 Sol) recreated the change test-first before its session dropped.

Question	Answer	Who	Where
Keep this PR after closing the creation-intent PR?	Keep it: product intents feed neither the Workflows funnel nor the goal tree, while Started orgs and activation rate need every creation counted; #115350 closed	👤 Human	this description
Which client sends the creation event?	ph_scoped_capture at the model receiver, so Celery-side creations deliver too; replaces flushing the global client in the data-suggestion task only	🤖 Agent	this description
Second event on API creations, or extend hog_flow_created to every path?	A separate team event below every path; hog_flow_created stays for user and channel attribution	🤖 Agent	this description
Run without production-shape data?	Yes, until read-only production access on 2026-11-02, by standing rule	👤 Human	this description

Involvement: rebased onto master on 2026-10-20 and 2026-10-26, no conflicts; two QA panel rounds (GPT-6.1 Sol: correctness, risk, design, systems, author perspective; Claude Opus 5.5: fresh eyes) and two final reads; no review bot ran; live run proof captured.

• Skills: modernize-pr, qa-swarm, tdd, pr-description, writing-voice, running-ci-preflight.
• Duplicate search: no merged or open upstream PR adds a team-level creation event.
• Public artifact: nothing from the session beyond this repository went into the diff or this description.

🤖 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

[scheduled-actions-posthog]

This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, please remove the stale label – otherwise this will be closed in another week. If you want to permanently keep it open, use the waiting label.