We're an eMembership publication, and we know our own platform best. This guide is written to be useful to a fire local that keeps its current setup. The one product section near the end is labeled.

What firefighter union software actually covers

Firefighter union software is any system an IAFF local uses to run its business: the public website, member logins, mass email and text, the membership roster, dues and payroll deduction, per capita, grievances and elections. In practice, fire locals tend to use one of two kinds of product.

A website and communications platform is built to publish and to reach people. It runs the public site, posts news and events, gives members a login, and sends broadcast email, text and push messages. Some add a member list and a payment form.

A membership system of record is built to be the authoritative answer to a short list of questions. Who is a member, and in what status? What does each member owe? What did the city send this pay period, and does it match? What per capita is due? Which grievances are open, and when is the next step deadline?

Both are legitimate tools. They're built for different jobs, and the difference matters most on the day someone asks the treasurer to prove a number.

What a fire local has to keep track of

Strip away the software and a fire local is still responsible for the same records. Writing them down is the first step toward knowing whether your current system holds them.

Members, by where and how they work. Rank, station and shift all affect who gets a message, who is covered by which contract language and who an officer needs to reach on a given day. Retirees stay on the books in a different status, and many locals want them in the same database.

Dues by payroll deduction. For many IAFF locals, dues arrive by payroll deduction: a municipal or county employer deducts dues from each paycheck and sends the money to the local. The local's job is to know what should have come in and to catch it when the city's check doesn't match.

Per capita. According to the IAFF, per capita is a separate payment a local makes to the IAFF for each active member, and it is not a direct charge to individual members (IAFF Help Center). It is assessed on each active member under the IAFF Constitution and By-Laws (IAFF Help Center). Locals may also owe per capita to a state or provincial association.

Grievances under the collective bargaining agreement. Each grievance has steps, deadlines and documents, and the contract decides the clock.

Dues authorizations. When the city deducts dues from a paycheck, there is usually a signed form behind it. For public-sector locals, that form carries extra weight. In Janus v. American Federation of State, County, and Municipal Employees, Council 31 (2018), the Supreme Court held that a public-sector employer may not deduct agency fees or any other payment to the union from a nonmember's wages unless the employee affirmatively consents. If a member disputes a deduction or the city asks for proof, the local needs to produce that signed form and the date it was signed.

Elections. Officer elections and ratification votes need an eligibility list that matches the roster on the day of the vote.

What website platforms for firefighter unions do well

One of the most visible vendors in this category is UnionActive, which markets to fire locals through its ProFirefighter brand.

Here's what UnionActive and ProFirefighter list on their websites as of this writing:

• A website system with a content management system, responsive design and member-only areas.
• Broadcast email, text messaging and push notifications.
• Custom mobile apps that include shift trades, group messaging and an integrated member login.
• An IAFF database sync and single sign-on integration.
• A member database (Data Manager), online dues payment and a grievance tracking product called GrievTrac.

Several of these are strong fits for fire. Shift trades are a firefighter-specific need. A sync with the IAFF's database speaks directly to the gap between the local's roster and the international's roster, which this guide comes back to below. And a fire local that mainly needs a good public site and a fast way to reach every member on every shift is well served by a platform built for exactly that.

Where a firefighter union website platform runs out

None of what follows is a criticism of any vendor's competence. These are the jobs a records system does and a publishing system usually isn't designed around. Where we refer to UnionActive, we mean what is not listed on its websites as of this writing, which is different from what it can or cannot do. Ask in a demo.

Remittance reconciliation. Taking a credit card payment and reconciling a city's payroll remittance are different jobs. Reconciliation means importing the employer's file, matching each line to a member, comparing what arrived against what should have arrived, and flagging the difference. A payment form records money that came in. It doesn't tell you about money that didn't. UnionActive's sites don't list remittance reconciliation as of this writing.

Per capita that follows the roster. The IAFF says membership changes approved through its Local Dashboard are reflected in per capita reporting. So per capita follows the IAFF's view of who is active. If the local's own roster, the city's deduction list and the IAFF's list drift apart, the local can end up owing per capita on a member whose dues stopped, or collecting dues from someone the IAFF doesn't show as active. Keeping the three in line is a reconciliation job. Per capita reporting isn't listed on UnionActive's sites as of this writing.

Financial depth where federal reporting applies. Many fire locals don't file LM reports at all. The Department of Labor says a union that represents only state, county or municipal government employees is not subject to the LMRDA (DOL OLMS FAQ). Locals with federal or private-sector members should check their own status. Where reporting does apply, the records behind it need more than a payment history (what the LM-2 and LM-3 forms ask for).

Audit trails. When a member disputes a balance, the useful answer is a log: who changed the record, when, and what it said before. Audit trails aren't listed on UnionActive's sites as of this writing.

Access by role. A secretary-treasurer, a grievance chair and a station rep need different views of the same data. Role-based access isn't listed on UnionActive's sites as of this writing.

The Record Owner Map: which system owns each record in your local?

Most advice about firefighter union software asks which product to buy. A more useful first question is which system owns each record you already have.

Two words do the work here. The owner of a record is the one place where it is created and corrected. When the record is wrong, this is where somebody fixes it. A reader is any system that displays, sends or uses a copy. Your website reading the roster to build an email list is a reader. Your website holding its own roster that the treasurer also keeps in a spreadsheet makes two owners.

The rule is simple: every record gets exactly one owner, and any number of readers.

Fill this in with your officers. For each record, write down where it is owned today. The third column lists who else already holds a version of it, because those outside copies are where most disagreements start.

How to read your map

A record with one owner is healthy, whatever product it lives in. If your website platform owns the contact list and reads everything else, that's a reasonable setup.

A record with two owners is where errors breed. In a fire local, the likely candidate is the roster: one version in the website platform, another in the treasurer's spreadsheet, and a third at the IAFF. Each gets corrected separately, and they drift.

A record with no owner is the quiet risk. It usually means the answer lives in an email thread, a paper folder or one officer's memory.

Look hardest at the four money rows: dues owed, remittance received, per capita owed and authorizations. If any of them has two owners or none, that's usually where a local has outgrown its website platform.

What most fire locals get wrong about firefighter union software

Treating the member login as the membership record. A login proves a member can reach a page. It says nothing about whether the status, balance or authorization behind it is right. Members being able to log in and pay is no evidence that anyone is maintaining the records behind the login. Check the map instead.

Counting the payment form as dues management. Online dues collection is convenient for members who pay directly. For a local paid mostly through city payroll deduction, the hard work is on the remittance side, and a payment form doesn't touch it.

Assuming the IAFF's roster and the local's roster agree. Per capita follows the IAFF's records. If nobody owns the job of keeping the local's roster in line with the international's, it falls to whoever reads the per capita statement and notices a number that looks off. The IAFF lets authorized officers see up to 24 months of statements in the Local Dashboard. That's a good place to start a check.

Replacing the website to fix a records problem. When the dues process is frustrating, it's tempting to conclude the whole platform has to go, including a website members like. The map usually shows the trouble sits in two or three rows. Fix the ownership of those and the website can stay.

You don't have to replace your website

Running two systems is a cost, and we argue elsewhere that it hurts. That argument is about two systems of record: two rosters, or two sets of dues data, each edited separately. A website that only publishes and sends messages doesn't count as a second system of record.

The healthy setup for most fire locals looks like this. One membership system owns the roster, dues, remittances, per capita and authorizations. The website is a channel. It publishes news and events, gives members a front door, and sends messages, reading from the system of record or linking to it. When the two are connected, the website stays current without becoming a second roster.

Keeping your current website vendor is one valid way to get there. So is moving everything to a single vendor. The deciding question is the same either way: after the change, does every row on your map have exactly one owner?

One practical point for locals that use an IAFF database sync. Ask which system the sync writes to. If the local moves its roster to a new system of record and the sync still points at the website platform's member list, you have two owners again. The question to put to any vendor, including us: which system talks to the IAFF, and is it the one that owns our roster?

Has your local outgrown its website platform?

Use the map to decide, rather than a feature list.

If every row has one owner and the money rows are clean, your current setup is doing its job. Spend your time elsewhere.

If one or two non-money rows have no owner, such as grievance deadlines kept in a notebook, you may only need a better process or one added tool.

If any of the four money rows has two owners or none, the local has a records problem. A website platform can keep its role as the channel; the money rows need an owner built for them.

A practical way to work through it:

How eMembership fits for public-safety unions

This section describes our own product.

eMembership is a cloud-based membership system built for labor unions, public-safety unions among them. It's designed to own the records on the map: member status and history, work site and chapter assignments, dues assessment, employer remittances, signed authorizations and grievances, all in one database. Station and rank can be tracked through fields configured during the Discovery Process for each local.

The member portal is the members' front door. The eMembership Member Web Portal lets members log in from any browser to check their dues balance and payment history, update their contact details, see grievance status and register for events. Every action writes directly to the eMembership database. Many locals start with the portal and add the Member Mobile App later, with no data migration.

On the money side, eMembership imports employer remittance files, matches each line to a member and flags exceptions such as missing deductions, unexpected contributions and amounts outside the expected range. Per capita can be set as a flat amount or a percentage at the lodge, contract, employer or member level. Every change to a dues record is logged with the user, the timestamp and the old and new values. Dues deduction authorizations can be signed electronically and are stored on the member's profile.

On security, eMembership runs on infrastructure that Winmill owns and operates, inside a SOC 1 (SSAE 18) and SOC 2 audited, ISO 27001 certified colocation facility, and Winmill maintains HIPAA Security Rule and PCI DSS compliance for the eMembership environment.

For locals that want one vendor for both, eMembership also designs union websites as an additional service.

A public-safety example. Three NYPD organizations, the Lieutenants Benevolent Association, the Captains Endowment Association and the Superior Officers Council, consolidated three separate desktop databases onto one eMembership platform. Data from all three was cleansed and reconciled during migration, paper processes were moved into the system, and role-based permissions control what each group can see. Reporting across all three groups became possible for the first time.