Romulus. BY NORTH JERSEY RESEARCH Request a demo

DOCS / OPERATIONS

Events, roles & access

The general-purpose events calendar with public RSVPs, and the role system that decides exactly who can see and do what.

Events & RSVPs

The Events calendar handles everything that isn't a fundraiser (ticketing + P&L) or a canvass (turfs + rosters): town halls, rallies, house parties, debate watches, visibility events, and virtual meetings. Each event carries a type, time zone-aware schedule, geocoded location with directions, an optional named host (linked to their voter record when possible), and — for virtual events — a platform and join link.

RSVPs track invited / confirmed / tentative / declined / waitlist, roll up into going-maybe-declined bars, and become a turnout count once attendees are checked in at the door — and each check-in writes back to that person's voter and volunteer record, so "came to three events" is something you can filter and target on later, not just a number on the night. Turn on reminders and every RSVP gets an email ~24 hours out — once per event, in the event's own time zone.

Mark an event public and it publishes to the campaign's event portal, where supporters RSVP without an account — with a capacity, an iCal feed, and embeddable flows for your own website. Attach tasks to any event to build a prep checklist with owners and due dates.

PERMISSIONS

Events run on manage_operations with the events feature; the public portal additionally needs the portal setting enabled by an admin.

Roles & permissions

Every user has exactly one role, and a role is a checklist built from roughly 30 granular permissions — grouped across Voters & Field, GOTV, Operations & Tasks, Finance & Volunteers, Communications, Website, Analytics, and AI. Roles are defined per campaign, so yours can have a tailored set — Field Director, Press Officer, Call-time Caller, Intern — rather than a fixed list. Per-user overrides handle the exceptions without inventing a new role.

Typical bundles:

Field Director view_voters · log_contacts · edit_engagement · export_voters · manage_turfs · review_canvass_data · manage_volunteers · view_analytics
Press Officer view_voters · manage_comms · approve_comms · view_analytics
Finance Director manage_fundraising · approve_expenses · view_analytics
Call-time Caller view_voters · log_contacts — no export or admin rights
Intern / Read-only view_voters only

Permissions decide who can do what; feature flags decide what the campaign has at all. If the Finance feature is off, no role — however privileged — can touch fundraising tools, and that's enforced on the server, not just tidied out of the menu: a disabled module's whole API is switched off, so there's no back-door endpoint to poke at. Manage campaign is the master admin flag that sits above the granular set. Roles that can manage users, manage the campaign, or export data are commonly required to enable two-factor authentication.

Anyone with manage_users can browse the campaign audit log — every meaningful action recorded with actor, IP, category, and detail, retained 90 days by default. Permission changes take effect on the next request; no logout needed.

Audit log, backups & integrations

A few systems sit underneath the daily work mostly so you never have to think about them until you need them. The audit log above is append-only — staff add to it just by doing their jobs, but nobody edits or quietly prunes it — and it captures the sensitive stuff specifically: creating, changing, deleting, and exporting data. AI requests are logged on a separate track, so a review of "who exported the donor list" isn't buried under model chatter, and a superadmin can read the whole trail after the fact.

Full database backups run on a schedule, each one checksummed so a silently corrupt archive can't pass for a good one, downloadable, and kept as long as your retention setting says to keep it.

CAREFUL — RESTORES

Restoring a backup replaces the live database wholesale — the one operation that can undo real work — so it's deliberately an operator-run, out-of-band step, never something the app fires on its own. That's the guardrail: a restore can't accidentally run against the database people are using right now.

Outside services — SMTP and Mailgun for email, Twilio for text, your AI provider, Stripe, and WinRed and ActBlue for online money — are all wired up inside the app, and their credentials live in the database, not scattered through config files on a server nobody remembers the password to. Inbound webhooks from those services are signature-verified before Romulus trusts a byte of them, and every one is logged — so "did that donation actually come through?" has an answer you can look up.

← Analytics Next — Rosie

Reading the manual before the demo? Sensible.

Request a demo