# Let marketing push fresh CRM data without asking the data team

> A one-screen console where marketing and sales ops refresh lead scores and audiences in your CRM themselves, on approved data pushes only.

- Workflow type: app
- Services: Census, Slack Bot
- Categories: Operations, Marketing
- Published: 2026-08-16

## What it does

- Shows a board of approved data pushes in plain English: what each one sends, where it lands, when it last ran, and how many records went through
- Gives each card one Push now button that kicks off the refresh and reports live progress, ending in a clear result like "finished, 4,812 records updated, 12 rejected"
- Records every push in an in-app history log with who ran it and when, and posts a short note to your data ops Slack channel so the data team keeps passive visibility
- Keeps a separate admin screen where a data engineer picks exactly which pushes business users can see and run, and nothing else is editable from the app

## What you'll need

- A Census account (now part of Fivetran Activations) with the syncs your data team already maintains
- A Slack workspace and a channel where data ops updates should land
- One person on the data side to choose which pushes show up on the board

## Prompt

Build me a self-serve data push console that my marketing and sales ops team can open themselves, so they stop pinging our data team in Slack every time an audience or a lead score needs to be refreshed in the CRM before a campaign. The audience is non-technical, so nothing in the interface should use warehouse jargon, expose sync configuration, or dump raw API output on screen.

The main screen is a board of cards, one per allowlisted Census sync. Build the cards from Census List Syncs, and use List Sources and List Destinations to label each card in plain English, like "Lead scores to Salesforce" or "Trial signups to HubSpot". Each card shows what it pushes, where it lands, when it last ran, and how many records went through, pulling the most recent run for that sync from List Sync Runs. Use Fetch Sync when a card needs the full configuration for a single sync. Cards must never expose field mappings, schedules, or connection settings.

Each card has one action: a "Push now" button. Pressing it calls Trigger Sync Run and then polls Fetch Sync Run on the returned sync run id every few seconds, replacing the button with a live status such as "queued", then "running", then a finished state like "Finished. 4,812 records updated, 12 rejected." Census returns 200 from the trigger when the run is only queued, not when it succeeds, so the real outcome always comes from polling the sync run. A run that started and then failed comes back as status "failed" with error_code, error_message and error_detail rather than as an HTTP error, so treat that as a failure and surface it.

The button for a sync must stay disabled while a run of that sync is already in flight, including runs somebody else started from the app and runs Census kicked off on its own schedule. Census explicitly asks clients to deduplicate trigger calls, so check the current run state before enabling the button and lock it the instant a run is triggered.

When a run fails, translate the raw error detail into one plain sentence a marketer can understand, plus a "Tell the data team" action that sends the sync name, the run id, and the underlying error to our data ops Slack channel. Never show a stack trace or a raw error payload to a business user.

Keep an in-app history log of every push: which sync, who pressed the button, when they pressed it, how the run finished, and the record counts. Show it as a history view anyone using the app can read, newest first, filterable by sync and by person. This audit trail is the trust mechanism that makes the data team willing to hand the button out, so it should be complete and never editable from the app.

Every push also posts a short note to our data ops channel in Slack using the Slack Bot Send a Message operation, so the data team gets passive visibility without being asked. Post one line when a push starts saying who pushed which sync, and a follow-up when it finishes with the outcome and record counts. Keep it brief, no dumps of the API response.

There is a separate admin view for a data engineer. It lists every sync in the workspace using List Syncs and lets the admin choose which ones appear on the business board, storing that allowlist in the app. Business users must only ever see and run allowlisted syncs. Nobody using the app, admin included, should be able to pause a sync, edit its mappings, or change its schedule, so the app never calls any Census create or update operation. The only write it ever makes is triggering a run.

A few Census API details to respect: responses are wrapped as {status, data, pagination}, so always read from data; sync, source, destination and sync run ids are integers; list endpoints default to 25 per page and cap per_page at 100, so page through pagination.next_page when loading the admin list of syncs.

## How to customize

- Change which pushes appear on the board at any time from the admin screen, without touching anything in Census
- Rename the cards so they read the way your team talks, like "Trial signups to HubSpot" instead of a warehouse table name
- Point the Slack notes at a different channel, or keep them only for the higher stakes pushes

## FAQ

### Can business users break something by pressing the button?

No. They only ever see the pushes a data engineer added to the board, and the only thing they can do is run one. The app gives them no way to pause a push, change what fields it writes, or move its schedule.

### Do our marketing people need their own Census logins?

No. They open this app, not Census. The connection to Census lives in the app, so the data team does not have to hand out seats or admin access to run a refresh.

### How do we know the push actually worked?

The card tracks the run from queued to running to finished and then shows the real outcome with record counts. If the run fails, you get one plain sentence explaining what happened plus a button to tell the data team, not a wall of technical output.

### What happens if someone clicks Push now twice?

The button locks as soon as a run starts and stays locked until that push finishes, including runs someone else started or ones that fired on their normal schedule. You cannot stack duplicate runs on the same push.

### Can we see who pushed what?

Yes. Every push is written to a history log inside the app with the person, the time, and how the run finished. That audit trail is what usually makes a data team comfortable handing the button out.

Use this prompt in General Input: https://www.generalinput.com/prompts/let-marketing-push-fresh-crm-data-without-asking-the-data-team