Oversight of every campaign, custody of none of their data
Each campaign, branch or chapter is its own workspace, grouped under a network hub. From the hub you see every campaign's numbers side by side and push a shared survey or SMS template into named campaigns. The roll-up returns counts and never a member's people – not as a setting, but because the query that produces it cannot return a person.
Trusted by progressive Australian campaigns, nonprofits, and causes
Why networks choose uprise
A workspace per campaign, not a shared database
Every campaign, branch or chapter gets its own workspace with its own contacts, team, branding and settings, grouped under a network. Isolation is the starting state, so nothing has to be un-shared later.
A roll-up that cannot become a supporter list
Every campaign figure the hub reads is a count. The cross-campaign totals are grouped on a derived identity key inside the database and come back as integers, so there is no drill-down to a supporter – because there is no code path that could produce one.
Publish from the hub, install into members
Snapshot one of your own surveys or SMS templates as an immutable version and push it into named campaigns. Each install is its own transaction and its own recorded event, so you can see which campaigns took it and which did not.
Answers that line up across campaigns
A shared question set is what makes members' results comparable. Survey branch edges reference question keys rather than row ids, so the same instrument installs into each campaign's own data and still reads the same way when the answers come back.
Staff access as a grid, not one team page at a time
People who work across a network hold one membership per workspace. One screen lists everybody with access anywhere in the network and the role they hold in each place, so checking whether a leaver can still reach anything is one read rather than a tour of every team page.
The same Australian geography under every campaign
Federal divisions, state lower and upper house electorates, LGAs, council wards and ABS statistical areas ship with the product. A branch in Perth and a branch in Hobart cut turf off the same reference data instead of a spreadsheet each.
What you get on day one
Every one of these is built and shipping today. Nothing on this page is a roadmap item.
The network console
One screen per network. Per campaign: contacts, contacts added in the last seven days, door knocks in the last thirty, blasts sent, upcoming events, the heads booked into them, and the date that campaign last did anything. The network row across the top totals the same measures, with new contacts over thirty days rather than seven. Figures are computed when you open it, not read from an overnight snapshot. It renders only from the hub workspace, and we switch it on per network.
Supporter overlap, counted once
How many distinct people the network reaches, deduplicated on email or mobile inside the database, split into people known to one campaign, to two or more, and to three or more. Rows with neither an email nor a mobile are reported as unmatchable rather than quietly folded into the unique figure.
A shared asset library
Publish a survey or an SMS message template from the hub as a version. Re-publishing appends the next version instead of rewriting the last one, so a campaign keeps exactly what it installed and is told an update is available. Members can install for themselves, and detach to stop tracking updates while keeping their copy.
Network staff access
Grant or revoke one person across many workspaces at once, capped at your own rank in the hub, with a per-workspace outcome returned rather than a single yes. A member campaign's last owner cannot be demoted or removed, so no network administrator can lock a campaign out of its own settings.
The same product inside each workspace
No cut-down member edition: turf cutting and route-ordered walk lists, the installable canvasser app that queues knocks offline, SMS blasts, volunteer peer-to-peer texting, a browser softphone, events and RSVPs, and one shared inbox. Each workspace carries its own logo, colours and address at its-own-name.uprise.org.au. Your plan decides which channels are switched on and sets the contact, seat and segment allowances, and those allowances are counted per workspace rather than pooled across the network.
Oversight without custody of anybody's supporters
What stops most umbrella bodies is not reporting, it is liability. Ask your member organisations to put their supporters into your system and you have asked them to hand you a responsibility they cannot delegate, and asked yourself to hold data you have no lawful reason to read. uprise splits the two: the hub reads numbers, and the people stay with the campaign that met them.
- Every metric on the console is a count – contacts, contacts added in the last seven days, door knocks in the last thirty, blasts sent, upcoming events, heads booked into them, and the date something last happened.
- The overlap figures are produced by a query that groups on a derived identity key inside Postgres and selects integers, so no identifier, hashed or otherwise, is ever materialised in the application. There is deliberately no list of the overlapping people to click through to.
- The console is hub-only and the API enforces that independently of the menu: a member campaign calling the endpoint is refused and told where the console lives, and somebody outside the network cannot tell a network they are not in from one that does not exist.
- Unmatchable rows – no email and no mobile – are reported separately, and the dedupe key is email, else mobile, so the overlap is presented as a floor rather than an exact figure. It is easier to trust a number that admits what it does not know.
- To work a campaign's actual data you switch into its workspace, which the console links to. The action, and the audit trail for it, then sits on that campaign rather than on the hub.
- 1Every metric on the console is a count – contacts, contacts added in the last seven days, door knocks in the last thirty, blasts sent, upcoming events, heads booked into them, and the date something last happened.
- 2The overlap figures are produced by a query that groups on a derived identity key inside Postgres and selects integers, so no identifier, hashed or otherwise, is ever materialised in the application. There is deliberately no list of the overlapping people to click through to.
- 3The console is hub-only and the API enforces that independently of the menu: a member campaign calling the endpoint is refused and told where the console lives, and somebody outside the network cannot tell a network they are not in from one that does not exist.
Publish once from the hub, install into every member
The usual way a network distributes a script is a PDF and a hope. Here the hub publishes the instrument itself and it arrives in a member's workspace as a real survey their volunteers run at the door, or a real template they send from their own workspace – and the version they hold does not change under them.
- Publishing snapshots one of the hub's own rows as an immutable version. Re-publishing appends the next version rather than rewriting the old one; campaigns on the previous version are flagged as having an update waiting rather than upgraded behind their backs.
- Push into named campaigns or all of them. Each campaign gets its own transaction and its own recorded event, so a failure part-way through leaves the campaigns that already succeeded genuinely installed, and the response names which took it and which did not.
- An upgrade upserts survey questions by key and never deletes one that already has answers – a question the new version dropped is kept and moved to the end of the order. Responses cascade off their question in the schema, so a naive overwrite would have destroyed a campaign's collected fieldwork.
- Disposition codes travel as values and resolve against the receiving campaign's own catalogue on install: a code they have no definition for is dropped rather than left pointing at a definition that is not there.
- The hub's sender number is deliberately not carried across – a member sends as itself, from its own default sender. Any campaign can detach at any time, which stops update tracking and leaves its copy untouched.
- 1Publishing snapshots one of the hub's own rows as an immutable version. Re-publishing appends the next version rather than rewriting the old one; campaigns on the previous version are flagged as having an update waiting rather than upgraded behind their backs.
- 2Push into named campaigns or all of them. Each campaign gets its own transaction and its own recorded event, so a failure part-way through leaves the campaigns that already succeeded genuinely installed, and the response names which took it and which did not.
- 3An upgrade upserts survey questions by key and never deletes one that already has answers – a question the new version dropped is kept and moved to the end of the order. Responses cascade off their question in the schema, so a naive overwrite would have destroyed a campaign's collected fieldwork.
Who can reach which workspace, answered in one screen
Network staff work across campaigns, so access is a grid rather than a list: one membership per person per workspace, multiplied by every workspace you run. Auditing that by opening each campaign's team page in turn is how somebody quietly keeps access to a campaign they left last winter.
- The matrix is one read: everybody with access anywhere in the network and the role they hold in each workspace, sorted widest-access first, so a review starts with the people who can reach everything.
- Grant or revoke a person across many workspaces – or all of them – in a single call, with a per-workspace outcome and a reason for anything refused.
- Authority comes from being an owner of the hub and is capped at your rank there, so a hub organiser cannot mint owners across the network. That rank is read fresh from the database on every call rather than trusted from the session.
- The last-owner guard belongs to the campaign, not to the network: a network administrator cannot demote or remove a member campaign's only owner, however senior they are at the hub.
- It manages access, not accounts. It will not conjure a user, so bringing somebody new on still runs through a proper invitation – emailed and accepted with a password they set, or texted to their mobile and accepted with a one-time code.
- 1The matrix is one read: everybody with access anywhere in the network and the role they hold in each workspace, sorted widest-access first, so a review starts with the people who can reach everything.
- 2Grant or revoke a person across many workspaces – or all of them – in a single call, with a per-workspace outcome and a reason for anything refused.
- 3Authority comes from being an owner of the hub and is capped at your rank there, so a hub organiser cannot mint owners across the network. That rank is read fresh from the database on every call rather than trusted from the session.
Built for every network model
A national body with state branches
The hub publishes the national survey and the approved SMS wording; each branch runs its own doors, texts and events in its own workspace under its own logo and colours. You see the branches side by side. The branch keeps its supporters, its consent record and its own opt-out register.
A funder backing several campaigns
See whether each campaign you back is actually moving – doors knocked in the last thirty days, contacts added in the last seven, whether its CRM connection is still healthy – without holding one of their supporter records, and without a reporting form somebody has to remember to fill in.
A coalition of member organisations
Every member joins with its own workspace, team and branding, and installs the shared question set so the coalition's answers are comparable rather than merely collected. When a member leaves, their access comes off every workspace in one action and their data stays theirs.
Questions we get asked
The things networks ask before they switch. If yours is not here, ask us directly.
No, and it is not a permission we can switch on for you. The network endpoints return counts, and the cross-campaign figures come from a query that groups inside the database and selects integers – widening that to a person would mean rewriting the SQL, not flipping a flag. If your staff are also members of a campaign's workspace, they can switch into it and work its data there, where that campaign's own audit trail records what they did.
It is built and running for a network right now, and it is not self-serve. The flag behind it is off by default, no plan turns it on, and the surface only appears from a network's hub workspace – so it is enabled per network when we set you up. That is also why the comparison table on this site files the console under what is next: the code is shipped, the switch is not on for everybody.
Surveys and SMS message templates today. Other shareable types exist in the data model – journeys, segment definitions, blast drafts – and the service refuses them with a message naming what is supported rather than half-copying something and leaving a campaign with a broken object. Nothing about sending identity travels with a shared asset: the hub's number stays with the hub.
Not automatically. There is no public API – keys can be issued, but nothing in the product authenticates with them – and no report builder or scheduled export. What exists is the console on screen, plus two CSV exports inside a workspace: an audience's contacts and an event's RSVPs. If a machine-readable roll-up is a condition of your own reporting obligations, raise it before you buy rather than after.
No. There is nothing in uprise that collects money from a supporter, and it is a deliberate opt-out rather than a gap we are about to close – the comparison table on this site says so plainly. The only Stripe code in the product invoices your own organisation for its uprise subscription. Expect to keep whatever you already use for that, and treat uprise as the organising side.
No, and today the flow is one-way. Each workspace holds its own credentials – one NationBuilder nation, or one Action Network connection per group it administers – and pulls a list or a tag into an uprise audience with resumable checkpointed paging, then re-pulls on a schedule: daily as it comes, hourly at the finest. The console carries a connection status and last successful sync against each campaign, so you can see a credential that has stopped working before the campaign notices. Writing results back into those tools is built for both providers but is switched off, so plan on uprise reading from them for now.
No. uprise has no email campaign product of any kind – a blast is SMS, and the message channel has no email member to send on. Transactional email exists and is brand-framed per workspace: invitations, sign-in links and verification codes carry that workspace's logo and colours, as does the event-reminder mail on the occasions something triggers it, which no timer in the product does. If network-wide email is central to how you organise, keep the tool that does it and let uprise do the doors, the texts and the calls.
Bring your campaigns under one roof, not one database
Tell us how your network is shaped – a hub with branches, a funder with a portfolio, a coalition of equals – and we will walk you through the console, the shared library and the access grid against something close to it. Networks are quoted rather than listed, because the shape of the network changes the answer.