Custom needs aren’t wrong. They’re just … custom.

A client called me yesterday with a membership question (paraphrased for brevity):

Can you make it so that if someone renews on June 10 this year, their membership will run through the end of the month — June 30 next year?

Right now, they’re doing it manually — editing expiration dates by hand after every renewal.

The short answer: Yes, I’m sure we can find a way to do that.

The longer answer: CiviCRM doesn’t offer such a setting out-of-the-box. It’s not an unreasonable need, but it’s uncommon enough that most orgs don’t require it. So you’ll need to think about whether it’s worth making CiviCRM handle it automatically.

Here’s the thing:

CiviCRM is built for nonprofits. It gets a lot of things right, right out of the box. But it’s probably not built exactly for all of your quirks.

That’s fine — because it’s also amazingly flexible. As an open-source tool designed for extensibility, almost anything is possible. If you decide it’s worth the investment.

If your organization has a custom policy — like how membership renewal dates should behave — you’ll need to choose how much effort, time, and expense it’s worth to you.

Manual editing is one path. Automation is another.

Neither option is wrong.
But either way, there’s a cost.

In the end, your job isn’t to find a “perfect” solution.
It’s to decide what tradeoffs you're willing to make.

All the best,
- A.

Previous
Previous

When "just CiviCRM" isn't just CiviCRM

Next
Next

SearchKit is for mortals (yes, even you)