Union leaders are hearing "just use Salesforce" more often. Sometimes it comes from a consultant, sometimes from a board member who used it at a nonprofit, and sometimes from their international. This guide explains what that decision actually commits a local to. It draws on Salesforce's, Microsoft's, and HubSpot's own published pricing, security, and program pages, Department of Labor recordkeeping guidance, and what unions tell us about the systems they run now. We make eMembership, and the one section about our platform is labeled as ours.

Can a union use Salesforce as its CRM?

Technically, yes. Salesforce, Microsoft Dynamics 365, and HubSpot are mature platforms, and a capable team can configure any of them to hold member records and track union activity. A few unions run on these platforms.

What matters is what that takes. A CRM arrives knowing about contacts, accounts, opportunities, and campaigns. It doesn't know what a dues rate is, that an employer owes a remittance by a certain date, that a local owes per capita to its international, or that a grievance has a contractual clock running on it. Each of those has to be designed, built, tested, secured, and then maintained by someone, for as long as the union runs on it.

So the real question isn't whether Salesforce can do it. It's whether your local wants to become a software engineering team and software owner: paying to build the union-specific functionality, then paying again to keep it working through every ratified contract, every bylaw change, and every Salesforce release.

What doesn't a CRM know about unions?

A CRM can be taught each of the items below. None of them ship in the core product, so each one has to be custom built, and everything custom built becomes something your union maintains.

Dues calculation and arrears. Union dues are rarely one number. Rates vary by employer, contract, classification, and sometimes hours or a percentage of pay, and they change on dates the contract sets. A member can owe for back months because an employer stopped deducting, through no choice of the member's. Purpose-built software models this directly: in eMembership's member billing, rates can be set by employer, region, contract, or classification, with effective date ranges so a scheduled increase takes effect on its own. In a CRM, the rate table, the assessment logic, the balance by period, and the late-fee and suspension rules are all custom objects and automation someone has to write.

Employer remittance reconciliation. Checkoff dues arrive as an employer file and a payment, often separately, often in the employer's own format. Someone has to match each row to a member, flag what's missing, and allocate the money across dues, COPE (Committee on Political Education) contributions, and other deductions. Employer payment processing built for unions handles CSV and fixed-width files, member matching, exception flags, and checks that pay several remittances at once. A CRM has a contact and an account. Everything between the employer's file and the posted balance is yours to design.

Per capita reporting. What a local owes its international depends on rules in the constitution: flat or percentage, by member type, split across levels. A CRM has no concept of an affiliate structure owing money upward, so the calculation and the transmittal report are custom.

Grievances tied to the contract. A CRM case object can track a grievance as a ticket. It doesn't know that the case belongs to a specific collective bargaining agreement, that the agreement sets the step deadlines, or that an older agreement may govern a grievance filed under it. Linking the case to the contract and its deadlines is configuration.

Federal record retention. Under the Labor-Management Reporting and Disclosure Act (LMRDA), unions must keep the records that verify their filed reports for at least five years after the report is filed. The Department of Labor's Office of Labor-Management Standards (OLMS) publishes a list of standards for electronic recordkeeping: records that can be retrieved, protected from unauthorized change or deletion, indexed, legible, documented, and tested before any paper originals are destroyed. A configured CRM carries that full obligation. Whether your custom dues objects meet it, and whether you can show OLMS that they do, depends entirely on how they were built.

Officer elections and ratification votes. LMRDA officer elections carry requirements for ballot secrecy, observers, and preserving election records. CRMs have survey tools, and third-party voting apps exist in their marketplaces. Neither is designed around union election rules by default, so evaluating whether a given tool meets them, including the OLMS guidance on remote electronic voting systems, is your work, ideally with counsel.

A functional inventory: which parts of your operation a CRM handles out of the box

Every record your local keeps falls into one of two groups, and the difference decides how much of your system a CRM can handle without custom work.

Engagement records track outreach and activity: organizing contacts, call lists, event sign-ups, and email and text campaigns. They end in a response (a worker signs a card, a member shows up, an email gets opened), nobody outside the union audits them, and they change when people change. A CRM handles these out of the box, and it does them well.

Obligation records track what your union owes, is owed, or has to prove: dues and arrears, employer remittance, per capita, grievances under a contract, and everything that feeds your annual LM report (the LM-2, LM-3, or LM-4 financial report a union files with OLMS). They end in a balance, a deadline, or a filing, someone outside the union can hold you to them, and their rules change when a contract, constitution, or filing requirement changes. In a CRM, every one of them has to be custom built.

To see where your local falls, take a functional inventory. It takes an afternoon with the people who run membership, finance, and representation, and it's worth doing whether you end up with a CRM, union software, or both. List every kind of record your local maintains, then ask three questions about each one.

1. How does it end?

Engagement ends in a response: the worker signs a card or doesn't, the member comes to the meeting or doesn't. An obligation ends in a balance, a deadline, or a filing that has to reconcile. Dues end in a balance. A grievance ends at a step deadline or a resolution. A remittance ends when the money that arrived matches the money the contract says should have arrived.

2. Who outside the union can hold you to it?

If an employer, your international, a member, an arbitrator, or OLMS can ask you to prove it, it's an obligation. Nobody audits whether a member opened last month's newsletter. Someone can audit whether that member's dues were posted correctly.

3. What changes it?

If the rules for a record change when a contract is ratified, a constitution is amended, or a filing requirement moves, it's an obligation, and its logic runs on someone else's schedule. Engagement records change when people change.

Most locals that take this inventory find that organizing contacts, outreach lists, event attendance, and communications are engagement records. Dues, remittance, per capita, grievances, and anything feeding an LM report are obligations. For a local, the obligation list is usually the longer one, and it's the part you'd be paying to build and maintain yourself.

The configuration debt of a CRM for labor unions

Every obligation on your inventory becomes a line in a ledger. The ledger is the part a CRM proposal usually doesn't price. It's the same pattern we described in build vs. buy union software: a heavily customized CRM is custom software your union owns. You've just changed who sells you the foundation.

The configuration debt ledger

Five costs sit on top of that ledger.

Custom objects and edition requirements. Union data needs its own objects, and the ability to build them is often tied to the higher editions. HubSpot's own documentation lists custom objects as available on Enterprise subscriptions. Microsoft describes its Dynamics 365 Sales Professional plan as having limited customization and automation, with full customization in Enterprise, and notes that custom apps require additional Power Apps licenses.

Per-seat licensing as staff grows. Salesforce, Dynamics 365, and HubSpot all license primarily per user. Salesforce describes its model as a per-user, per-month subscription, with most editions billed annually. Dynamics 365 Sales plans are priced per user per month, paid yearly. Every business agent, organizer, and steward with a login is a line on the renewal. Check current figures on Salesforce's pricing page, Microsoft's Dynamics 365 Sales pricing page, and HubSpot's pricing page.

Price increases you don't negotiate. List prices move on the vendor's schedule. Salesforce raised list prices by an average of 6% on the Enterprise and Unlimited Editions of Sales Cloud, Service Cloud, and other products, effective August 1, 2025. A union's dues don't rise on Salesforce's calendar, but its renewal can.

Upgrades and customizations. CRM vendors ship on their own schedule. Salesforce delivers three major releases a year, and its own training material advises admins to test new features in a sandbox and check whether they conflict with customizations already in the org. That check is a recurring task for whoever owns your union objects, three times a year, indefinitely.

Consultant dependency. The size of the CRM partner market is an advantage when you're building. It becomes a dependency when the only person who understands your dues objects is an outside consultant billing by the hour, or a staff administrator who could leave.

Security becomes your job

Salesforce invests heavily in securing its platform. What it doesn't secure is how your union configures it. Salesforce's own shared responsibility model says customers are responsible for protecting their own data, configurations, and access rights.

That line matters more for a union than for most CRM customers. A union's records include home addresses, phone numbers, employers, dues history, and grievance files, and in some contracts the last digits of a Social Security number. Every custom object you build for dues or grievances arrives with sharing rules and permissions someone on your side has to get right, and has to recheck every time a new object, role, or integration is added.

The risk isn't theoretical. In March 2026, Salesforce confirmed a campaign in which attackers pulled data from customers' public Experience Cloud sites, the kind of portal a union might build for members, by exploiting guest user settings that were more permissive than they needed to be. Salesforce said the platform itself wasn't breached. The exposure came from customer configuration, which is exactly the part a union inherits when it builds on a CRM.

Union apps built on Salesforce: two vendors, one stack you don't control

Some vendors sell union or membership apps that run inside Salesforce. That can shorten the custom work. It changes less than it seems.

• You're usually paying for two layers. The app runs on Salesforce, so the Salesforce licenses underneath it still have to be paid for, by you or folded into the app vendor's price. Both layers are typically priced per user, and both can change at renewal.
• The app inherits Salesforce's calendar. Three Salesforce releases a year means three rounds of testing for the app vendor, and three more for anything your local customized on top.
• Your customizations are still yours. Whatever the app doesn't do for your contracts, your dues rules, or your employers gets built in your org, on your budget.
• The exit is harder. If the app vendor raises prices, gets acquired, or leaves the union market, your records sit in Salesforce objects someone else designed.

Even a union that made Salesforce work describes a heavy lift. Three years after PCS, the UK civil service union, moved to Salesforce, its head of technology services wrote that ongoing licenses are the largest cost of running a modern CRM. PCS dropped the membership app it started with after prototyping, built its own tools with an outside development partner, and advises other unions to hire staff who understand both CRM and organizing. That's what success on a CRM looks like: a funded technology team, several outside partners, and custom development that never really ends.

When your international offers the CRM

Some internationals roll out a shared CRM or member app to their affiliates, sometimes at a pilot or introductory price. For the international, that can make sense. Its own work is mostly campaigns, communications, and a view across affiliates, which is engagement work a CRM handles well.

A local's work is different. The local collects the dues, reconciles the employer files, enforces the contract, and files its own LM report. Its officers sign that report, not the international's. A platform designed around the international's needs can leave the local's obligations as someone else's custom project, on someone else's platform.

Before your local moves its records, get written answers to these questions:

A CRM can be the right tool for an international and still be the wrong system of record for its locals. Those aren't competing positions. For many locals, the answer is to keep the obligations in union software and connect it to whatever the international runs, which is the hybrid approach below.

CRM vs. union management software, line by line

This table shows, capability by capability, what comes included with each option and what your union would have to pay to have custom built and then maintain itself. "Included" means it works out of the box. "Custom development" means your union funds the build and owns the upkeep. A CRM comes out ahead on marketing and on the size of its ecosystem. Union software comes out ahead on everything a union is held accountable for.

Where does a CRM help a union?

A CRM is very good at the question "who should we talk to next?" Contact segmentation, email and marketing automation, and stage-based campaign tracking are what these products do every day for millions of users. HubSpot grew out of marketing software, Salesforce and Dynamics sell mature marketing products, and all three have large marketplaces and consultant pools.

That's why a CRM can fit an organization whose functional inventory is mostly engagement records: a campaign-focused team, or an international whose dues and remittance are handled by its affiliates. If you're in that position, a CRM is a defensible choice, provided four things are true:

For a local whose daily work is mostly dues, remittance, contracts, and grievances, those conditions rarely hold.

The hybrid option: a union system of record and a CRM

For many organizations the strongest answer is both. The union system of record holds the obligations: members, employers, dues, remittance, contracts, grievances. A CRM or marketing tool, including one your international provides, sits alongside it for campaigns and outreach, reading from the system of record through an integration.

Three rules keep a hybrid from turning into two systems that disagree:

• Decide which system owns each field. Dues status, membership standing, and employer belong to the system of record. The CRM can display them. It shouldn't be the place anyone edits them.
• Sync in one direction for obligations. Contact preferences can flow back to the system of record. Balances and standing flow out, never in.
• Keep the integration documented and owned. An integration is a small piece of custom software, and it carries the same continuity question as any other.

eMembership's integrations page describes how this works on our side: a secure REST application programming interface (API), documented with Swagger, for connecting outside systems, plus bulk data pipelines and exports.

What most unions get wrong about CRMs

They ask whether the CRM can do it, instead of who maintains it after. The answer to "can Salesforce track dues?" is yes. The useful question is who updates the dues logic the next time a contract is ratified, and what that costs per year.

They treat a pilot price as the price. Introductory pricing covers the first term. Ask for year two and year three in writing, at your expected staff count, for every layer you'll be paying for.

They assume nonprofit pricing applies. It often doesn't. As of this writing, Microsoft's nonprofit eligibility page lists political, labor, and fraternal organizations as ineligible, and HubSpot's nonprofit criteria do the same. Salesforce's Power of Us program asks U.S. applicants for a 501(c)(3) or 501(c)(4) determination letter, and unions are generally 501(c)(5) organizations. Confirm eligibility directly with the vendor before the budget depends on it.

They price the seats for today's staff. A per-user license looks modest at a handful of users. Add every organizer, business agent, and steward who will need access, then move to the edition your custom objects require, and the number is different.

They don't define a system of record. The fastest way to lose trust in your data is two systems that each hold a member's status and disagree about it. Decide the owner before the first sync runs.

How eMembership fits

This section is about our own platform. Everything above applies to whatever a union decides.

eMembership was built for labor unions, has been in continuous development since 2008, and is used by 55+ labor unions. The obligation records in your inventory are what it models directly. Member payments and billing assesses dues on demand or on a schedule, with rates by employer, region, contract, or classification and effective dates for scheduled changes. Employer payments imports remittance files in CSV or fixed-width formats, matches rows to members, flags exceptions, and allocates across dues, COPE, and agency fees. Contract management sets dues rates at the contract level, and grievances link back to the relevant contract. For the mechanics of the dues side, our guide on how automated union dues billing works walks through it.

Voting is one of the clearest places a CRM needs outside help and a union platform doesn't. eMembership's Surveys and Votes module supports anonymous ballots for ratifications and officer elections, and its electronic voting for officer elections is designed around the OLMS guidance on remote electronic voting. For ratification and strike votes, confirm your constitution's and bylaws' requirements with your own counsel. SEIU Local 500, which represents about 20,000 workers in Washington, DC and Maryland, runs contract ratification votes in eMembership, and its ratifications now close in days rather than weeks. You can read how Local 500 runs ratification votes.

The security and maintenance burden in the sections above doesn't land on your staff. 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 our team maintains the union data model through every platform release. You can read more about how eMembership approaches union data security.

There are 18 configurable modules, and the Discovery Process determines which ones a given union needs. The Member Web Portal and the Member Mobile App are separate additions. eMembership is a flat-fee annual subscription with no per-seat fees, so adding an organizer or a steward doesn't change the bill.

eMembership doesn't try to be a marketing automation platform. If your local, or your international, wants a CRM or marketing tool for campaigns, eMembership connects to it through its open API, and the hybrid rules above apply.