Google Cloud Pub/Sub

Bridge your flows into Google Cloud Pub/Sub. Agents publish messages with attributes and ordering keys, manage topics and subscriptions, and pull and acknowledge messages from pull subscriptions, with payloads decoded to plain text.

11 actions Custom auth available

Google Cloud Pub/Sub website ↗ Platform Documentation ↗ Capability data verified 2026-07-27

A scheduled drain runs every five minutes against the orders-exceptions pull subscription

Pull Messages retrieves the waiting events, each with its attributes, ordering key, publish time, and payload decoded to plain text

The agent sorts events by their severity attribute, separating routine order updates from failed-payment and refund-requested events

Routine events are appended to the reporting table and re-published to the fulfillment topic with Publish Message so downstream consumers pick them up

Each failed-payment event posts to the revenue operations channel in Slack with the decoded payload and the order reference

The operations lead decides whether the flagged order proceeds to fulfillment or gets held while the payment is chased

Acknowledge Messages clears every processed event before the ack deadline so nothing is redelivered

What This Integration Enables

In a Google Cloud shop, Pub/Sub is usually where the truth of the business already flows: orders, signups, sensor readings, state changes, all published as events. The gap is that consuming those events has been an engineering job, which means the operations team that actually cares about a failed payment or a stuck shipment waits for a backlog ticket to get a consumer built. This connector closes that gap. FlowRunner agents become first-class citizens on the bus, both publishing and consuming, so the people who own the process can act on the events without asking anyone to deploy a service. - Publish single messages or batches with string attributes for filtering and ordering keys for in-sequence delivery - Provision topics with message ordering, storage policies, and retention, and subscriptions in pull or push mode - Drain pull subscriptions with the pull-process-acknowledge pattern, with payloads decoded to plain text - Inspect topics and subscriptions before writing, so flows adapt to the environment instead of assuming it Because agents on the bus wield the same delete operations an engineer would, the connector is also where FlowRunner's [human-in-the-loop](/concepts/human-in-the-loop) discipline matters: reads and publishes run at machine speed, and the operations that drop messages wait for a person.

Without FlowRunner

Events without operations The bus carries the truth of what happened, but only engineers can build consumers for it

Stuck queues found late An unmonitored subscription backs up silently until someone notices a dashboard went stale

Automation off the bus Ops tooling polls APIs on timers while the same facts already stream through Pub/Sub

With FlowRunner

Agents as consumers FlowRunner agents pull, route, and acknowledge messages without a line of consumer code

Exceptions reach people High-severity events leave the queue and land in Slack with the full decoded payload attached

Both directions covered Flows publish events back to topics, so agent work is visible to every other consumer on the bus

Use Case Scenarios

Fan out records as events

A revenue operations agent reads the day's provisioning requests from [Google Sheets](/integrations/google-sheets) and calls Publish Messages (Batch) to put each row on the customer-changes topic with attributes for region and plan tier. The billing service, the warehouse sync, and the analytics loader are already subscribed, so each row fans out to three consumers in one call. An ordering key per customer keeps upgrade and downgrade events in sequence, so no consumer ever processes a downgrade before the upgrade that preceded it.

The queue drain that files its own paperwork

On a schedule, an agent calls Pull Messages on the audit-events subscription with Return Immediately set, so an empty queue costs nothing. Each decoded payload is written to [BigQuery](/integrations/bigquery) for the compliance team's retention window, and Acknowledge Messages runs only after the insert succeeds, so a failed write leaves the message on the subscription for redelivery instead of losing it. Events that fail parsing twice are posted to [Slack](/integrations/slack) with their raw base64 payload rather than looping through redelivery forever.

Provisioning a new event stream

When a new vendor integration goes live, a setup flow calls Create Topic with message ordering enabled and a seven-day retention duration, then Create Subscription twice: a push subscription that delivers to the vendor's HTTPS endpoint, and a pull subscription the monitoring agent drains. Get Topic confirms the storage policy matches the data residency requirement before the first message is published, and the whole configuration is posted to the platform channel as a record of what was built and why.

Human-in-Loop Highlight

Delete Subscription drops every message retained in the subscription, permanently, and Delete Topic leaves existing subscriptions pointed at a topic named _deleted-topic_ that will never speak again. So the cleanup agent that tidies a project never deletes on its own judgment. It inventories with List Subscriptions, identifies candidates that look abandoned, and posts the evidence: "Subscription legacy-orders-sync has had no consumer connected in weeks and its topic still receives events. Deleting it discards everything it has retained. Confirm?" A platform owner answers, and only then does the agent call Delete Subscription. The inventory ran at machine speed. The operation that discards messages belonged to a person.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

11 actions

Topics

Publish Message Publishes a message to a Pub/Sub topic and returns the server-assigned message IDs. Provide the message as plain text (automatically base64-encoded for the API), optional string attributes for filtering and routing, and an optional ordering key to deliver related messages in order (the topic must have message ordering enabled).
Publish Messages (Batch) Publishes multiple messages to a topic in a single request and returns the server-assigned message IDs in the same order as the input. Each message accepts a plain-text data field, optional attributes, and an optional ordering key. Used to reduce round-trips when fanning out many events at once.
Create Topic Creates a new Pub/Sub topic in the configured project. Optionally enable message ordering support, restrict which regions store message data with a message storage policy, and set a message retention duration so subscriptions can seek to past messages. Fails if a topic with the same name already exists.
List Topics Lists the Pub/Sub topics in the configured project, paginated with a page size and page token. The inventory step behind provisioning checks and cleanup sweeps.
Get Topic Retrieves the configuration of a single topic, including its labels, message storage policy, message retention duration, and schema settings. Used to confirm a topic exists and inspect its settings before publishing.
Delete Topic Permanently deletes a topic. Existing subscriptions are not deleted but can no longer receive new messages from it. The operation this page's human gate exists for, alongside Delete Subscription.

Subscriptions

Create Subscription Creates a subscription that receives messages published to a topic. Pull by default, or push to an HTTPS endpoint when a push endpoint URL is provided. Optionally set the acknowledgement deadline, message retention, and whether acknowledged messages are retained for replay.
List Subscriptions Lists the subscriptions in the configured project, each with its topic, push config, and ack deadline. Paginated with a page size and page token.
Delete Subscription Permanently deletes a subscription. All messages retained in it are dropped and future messages published to its topic will not be delivered to it. Never called in FlowRunner workflows without a named person confirming first.
Pull Messages Pulls messages from a pull subscription. Each message includes its ack ID, attributes, ordering key, publish time, and a decoded plain-text data field alongside the raw base64 payload. Set Return Immediately to avoid waiting on an empty subscription.
Acknowledge Messages Acknowledges one or more pulled messages by ack ID so they are removed from the subscription and never redelivered. Called after processing succeeds and before the ack deadline expires, which is what makes the drain pattern safe to retry.

Frequently Asked Questions

What can FlowRunner do with Google Cloud Pub/Sub?

FlowRunner agents can run Publish Message, Publish Messages (Batch), and Create Topic in Google Cloud Pub/Sub, plus 8 more actions.

Does connecting Google Cloud Pub/Sub to FlowRunner require OAuth?

Google Cloud Pub/Sub uses a custom authentication method to connect to FlowRunner.

Can Google Cloud Pub/Sub trigger a FlowRunner workflow automatically?

Google Cloud Pub/Sub doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Google Cloud Pub/Sub

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

Start Building Free Talk to us