Why We Rebuilt the Siren Admin in 3.0
The 3.0 admin ships with flow diagrams on every lifecycle, activity feeds on every record, and contextual help where decisions get made. Operators can see what Siren is doing and why, without hunting.
The 3.0 admin is the version of Siren where operators can see what the system is doing at any time, understand why, and find the evidence without hunting. When a commission pays out, the reason is on the record. When an obligation moves from draft to pending, the trigger is on the record. When a refund cascades through a sale with two obligations attached, the cascade is visible on every feed it touched.
The 3.0 admin touches every screen. Programs, collaborators, conversions, obligations, fulfillments, transactions, distributors, program groups. All of it, rebuilt around one goal: giving operators a view into the system they’re running.
The system shows you its reasoning
We wanted operators to be able to see lifecycle at a glance. Detail views in the 3.0 admin ship with visual flow diagrams. Picture a new program owner at a course platform opening an obligation for the first time. Its draft-pending-fulfilled path is rendered as a diagram, with the current state highlighted. Open a fulfillment or an engagement and the same thing happens with their lifecycles. The record shows you where it is and what’s around it, without needing to consult docs or hold the state machine in your head.
The help system works the same way. Tooltips sit next to settings that have real consequences. Slide-out drawers expand on decision points without knocking you out of context. Every frontend string is translatable, which matters less for English-first operators and a lot for anyone running a program in a language that wasn’t an afterthought. None of this removes ambiguity by accident. Each piece was placed because operators shouldn’t have to guess about things the system already knows.
Everyday friction, gone
The daily wins are less philosophical and more tactical. Picture a marketplace operator running roughly 14,000 obligations a month, closing payouts on the 28th, wanting to review the last 400 unusual-amount entries before fulfillments run. In 3.0, data tables filter, sort, and bulk-action on the server, so she scrolls once and acts once at scale.
The rest of this layer is supporting cast. CSV export for fulfillment payouts exists because a surprising share of payout work still ends up in a spreadsheet somewhere, and a one-click bulk export saves her an hour at the end of every cycle. Dark and light themes exist because people stare at this software for hours. The sidebar collapses because two rows of chrome on a narrow screen is one row too many.
These aren’t headline features. They’re the friction you stop noticing because it’s gone.
Activity feeds turn records into stories
Picture a partnerships lead at a mid-sized WooCommerce store. On Wednesday morning a creator emails her about a $42 commission from an order the Tuesday before. In 3.0, every major record carries an activity feed. She opens the obligation first, reads the chronological log, sees the refund entry from Monday 11:47am, the conversion-reversal at 11:47am with “refund received” as the reason, and the transaction rollback three seconds later. Same timestamps, same reason, on every feed the refund touched. Walk in from the obligation, the conversion, or the transaction and she lands in the same story.
She replies to the creator in two minutes, with a specific answer rather than a guess. Partial refunds and multi-line orders work the same way. The cascade writes proportional reversals across each obligation the original transaction touched, with the same timestamp and reason on every feed, so a $30 refund on a $100 three-line order doesn’t leave you wondering which obligation moved and by how much. The activity feeds post covers what that does for disputes and weekly review in more depth. The short version here is that it’s where all the flow-diagram and help-system work converges, and it’s where most of the confidence thesis gets paid off.
Manual attribution keeps the confidence thesis honest
Automation that you can override is automation you can trust.
Sometimes the automated attribution isn’t the right call. A customer emails saying “I came through this partner, not that one.” A misfiring integration credits the wrong collaborator. A sales conversation closes a deal the referral link never saw. The manual attribution path lets you credit a collaborator against a specific transaction, and the action gets written into the transaction’s activity feed alongside every other event on that record.
The point is what that feed looks like three months later. An agency owner running B2B referrals gets questioned by a partner about a payout from March. She opens the transaction, scrolls the feed, and finds the manual-attribution entry: who credited whom, when, and in response to what. The partner gets an answer the same afternoon instead of a week of spreadsheet archaeology. That’s the feature that keeps the rest of the rebuild honest. A system that showed you its reasoning without giving you a way to legitimately override it would still be untrustworthy, because every system occasionally needs a human judgment call. The audit trail is what makes the judgment call safe.
You shouldn’t fight the software you pay people through
The whole point of building Siren the way we’ve built it is that a website should be able to track what it owes other people automatically, and the operator running that system shouldn’t be fighting the software to find out what it did. The 3.0 admin closes that gap. You can read programs, audit payouts, resolve disputes, and stack new incentive structures on top of existing ones without first having to reconstruct how everything connects.
The attribution and payout math under the admin is the same math that’s been running in production for years. What’s new is that you can watch it work without hunting.
You shouldn’t have to fight the software you pay people through. That’s what this rebuild is for.