FlowRunner
PricingContact
Theme
Start Free

CrowdPower

Email Marketing

Feed customer identification and behavioral data into CrowdPower through the Beacon API. Agents keep lifecycle campaigns triggered by what customers actually did rather than by a nightly export.

9 actions API key available
CrowdPower website ↗ Platform Documentation ↗ Capability data verified 2026-08-02
A migration job finishes loading two years of historical activity into the product database
Agent reads the customer records, their events and their charges from the source
Agent confirms every record carries a user ID or an email so no profile is created blind
Agent groups the events by date and finds that most of them predate the current live window
Agent posts the record count, the event date range and the event types involved to the lifecycle channel
Lifecycle owner confirms which automations are paused before the agent runs the bulk load

What This Integration Enables

CrowdPower is not a place you send from. It is a place you tell the truth about your customers, and everything downstream of that truth is CrowdPower's own automation engine. The Beacon API is write-only by design: there are no list endpoints, no read endpoints and no webhooks, so this connector ships no pickers and no triggers. That is not a limitation to work around, it is the shape of the product. Your systems know what happened. CrowdPower needs to be told.

FlowRunner's job here is the pipe, and it is a better pipe than a nightly export because it can be event-shaped. An agent can call Identify Customer the moment a profile trait changes, Create Customer Event when someone activates a feature, and Create Customer Charge when a payment settles, so segments stay accurate against what people actually did rather than against a snapshot taken at 2am. Every operation has a bulk variant for the cases where volume matters, and Track Customers folds profile, events, charges and tags into one atomic call so a full activity snapshot cannot land half-applied. The write-only shape has one consequence worth stating plainly: an agent cannot read back which automations are currently armed, which is exactly why the bulk paths need a person in front of them.

Without FlowRunner

Lifecycle data arrives on a delay Automations fire against whatever last night's export happened to contain
Four calls per customer Profile, events, charges and tags each go in separately and can land out of order
Backfills are done blind A history import goes in with no advance view of what it will set off

With FlowRunner

Behavior arrives as it happens A signup, an upgrade or a feature activation reaches CrowdPower as its own event
One atomic snapshot Profile traits, events, charges and tags land together in a single call
Backfills get reviewed first The scale and the date range of a replay are put in front of a person before the write runs

Use Case Scenarios

Product behavior as it happens

A user upgrades their plan. The payment settles in Stripe, and the agent handles the whole consequence in one flow: Identify Customer to merge the new plan tier and seat count into the profile, Create Customer Charge with the amount in the smallest currency unit so lifetime spend stays correct, and Create Customer Tag to move them out of the trial cohort. CrowdPower's revenue segments and spend-based automations react to a customer who upgraded eleven seconds ago, not to one who upgraded sometime yesterday.

Enrichment from a system CrowdPower never sees

A support conversation in Intercom is resolved with a churn-risk sentiment. The agent does not need CrowdPower to know anything about the support desk. It calls Create Customer Tag to mark the person as a churn risk and Create Customer Event to record the interaction on their timeline with the ticket reference in the properties. A save campaign built on that tag now fires on evidence that came from a system with no CrowdPower integration at all, because the agent carried it across.

A full snapshot in one call

An overnight reconciliation compares the product database in PostgreSQL against what was last sent. For each customer whose state has drifted, the agent assembles the corrected profile traits, the missed events, any unrecorded charges and the current tag set, then sends the whole thing with Track Customers. One request per customer, applied atomically, instead of four requests that can succeed in part and leave a profile describing a person who does not exist.

Human-in-Loop Highlight

The gate is on the bulk write, and the reason is specific to how CrowdPower works. Events are the primary trigger source for its lifecycle automations, and Create Customer Events In Bulk is the tool for replaying history. Put those two facts together and a data backfill becomes a mass send: import two years of upgrade events and every automation armed on an upgrade fires, retroactively, for thousands of people who upgraded in 2024 and will be extremely confused to receive a congratulations email about it this morning. The agent cannot check for this on its own, because the Beacon API is write-only and offers no way to ask which automations are live. So it stops and asks the only party who knows: "Ready to load 41,200 customers and 380,000 events dated between March 2024 and today via Identify Customers In Bulk and Create Customer Events In Bulk. Event types include upgraded, invited_teammate and activated_feature. Confirm the automations on those event types are paused, or tell me to hold." That is human-in-the-loop placed where the platform's own design makes it necessary, not bolted on for form.

Agent processes routinely
Detects exception requiring judgment
Clear match Continues automatically
Ambiguous Routes to human via email
Human decides
Agent resumes with decision

Agent Capabilities

9 actions

Customer Profiles

2
  • Identify Customer Creates a customer record in CrowdPower or updates an existing one, matching on the supplied user ID or email address. Used whenever someone signs up, changes a profile trait, or is enriched from another system. Custom attributes merge into the existing profile rather than replacing it, so a flow can send only the fields it actually knows about.
  • Identify Customers In Bulk Creates or updates many profiles in one request. Used to backfill an existing user base or to replay a sync without issuing a call per record. Every entry needs a user ID or an email address, and user ID wins when both are present.

Behavioral Events

2
  • Create Customer Event Records a behavioral event on a customer's timeline, registering the event type on the project automatically the first time it appears. Used for the meaningful moments that should drive a campaign: an upgrade, an invite, a feature activation, a plan downgrade.
  • Create Customer Events In Bulk Records several events for one customer in a single request, each keeping its own action, properties and timestamp. Used to replay historical activity or to flush a buffered queue. This is the operation that makes armed automations fire retroactively, which is why it belongs behind a review step.

Revenue

2
  • Create Customer Charge Records a payment against a customer and rolls it into their lifetime charge summary, which powers revenue segments and spend-based automations. Amounts go in the smallest currency unit, so a 49.00 USD payment is sent as 4900.
  • Create Customer Charges In Bulk Records several charges for one customer in one request, each with its own amount and optional timestamp. Used to import billing history from a payment processor or an internal ledger without one call per invoice.

Tags

2
  • Create Customer Tag Applies a tag to a customer, creating the tag on the project automatically when the name is new. Used to mark cohorts such as trial users, churn risks or webinar attendees so automations can branch on membership.
  • Create Customer Tags In Bulk Applies several tags to one customer in one request, creating any names that do not exist yet. Used when a segmentation job assigns multiple labels at once.

Combined Write

1
  • Track Customers Creates or updates customers and attaches their events, charges and tags in one combined call, so a whole activity snapshot lands atomically rather than across four separate requests. Used for reconciliation runs and for any flow where a partially applied profile would be worse than no update at all.

Frequently Asked Questions

What can FlowRunner do with CrowdPower?

FlowRunner agents can run Identify Customer, Identify Customers In Bulk, and Create Customer Event in CrowdPower, plus 6 more actions.

Does connecting CrowdPower to FlowRunner require OAuth?

No. CrowdPower connects to FlowRunner with an API key, no OAuth flow required.

Can CrowdPower trigger a FlowRunner workflow automatically?

CrowdPower doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with CrowdPower

$100 in credits. No card required. Connect in minutes.