1. Rowfire
  2. Use cases

Celebrate trials that convert to paid

Post to #wins in Slack and update the customer's plan attribute in Braze when a PostgreSQL trial converts to a paid plan. Two actions, one trigger.

  • PostgreSQL
  • Slack
  • Braze
  • Sales
  • once per account

The trigger

One read-only SELECT against PostgreSQL. Rowfire polls it for new rows, and the rule fires once per account.

SELECT a.id AS account_id,
       a.name AS account,
       a.owner_name,
       p.name AS plan,
       p.monthly_price,
       a.converted_at
FROM accounts a
JOIN plans p ON p.id = a.plan_id
WHERE a.converted_at IS NOT NULL
  AND p.name <> 'Trial'
  AND a.is_internal = false

The clock is converted_at and the key is account_id, so each account is celebrated once, even if it later changes plan. Table and column names are a sketch; adapt them to your schema.

Two actions on one rule

action request
Slack send_message to #wins: the account, the owner and the plan
Braze update_attribute sets plan to {{ plan }} for external_id {{ account_id }}
{{ account }} just converted to {{ plan }} ({{ monthly_price }}/mo). Owner: {{ owner_name }}.

Every rule starts in shadow, so both requests are rendered and recorded before either is sent. For the moment a trial is at risk instead, see rescue trials that never activated.

Questions

Can one rule do both the Slack post and the Braze update?

Yes. A rule can have several bindings, and each produces its own request. Nothing is chained between them.

Why update an attribute in Braze instead of sending an event?

The plan is state, not a moment: future campaigns should treat the customer as paying. update_attribute sets the field; track_event would record that something happened.