Week of June 22, 20262 updates

Text contacts, reusable lists, and public program sign-up

Texting just got a lot more flexible.

Contacts. You can now text people who aren't full client records — event attendees, volunteers, community members. Add a contact with just a name and a phone number under SMS → Contacts.

Reusable lists. Build named lists (like "Fall ESL Class") from your contacts and clients, then send a campaign to the whole list at once. Manage them under SMS → Lists.

Public program sign-up. Turn on public sign-up for any list to get a shareable link. People can enroll themselves, agree to receive texts, and join the list automatically — no manual data entry. Perfect for letting students or program participants opt in on their own.

Everyone you text is still protected by the same consent rules: people can reply STOP at any time to opt out across every list and number.

Address autocomplete when entering addresses

Entering an address is now faster and more accurate. As you type a street address, real address suggestions appear — pick one and the city, state, and ZIP fill in automatically, so you spend less time typing and stop storing typos.

It works across the app wherever you enter an address: the client form and the client data grid, organization sign-up and settings, events, volunteer opportunities, and public intake forms.

If an address can't be looked up for any reason, the field simply works as a normal text box, so you can always enter an address by hand.

Week of June 15, 20265 updates

Birth year fills in automatically from date of birth

When you enter a client's date of birth, their birth year now fills in automatically, so you don't have to type it twice and the two always agree.

  • Entering or changing a date of birth in the client form or the clients table updates the birth year to match.
  • Changing the date of birth later updates the birth year too.
  • You can still enter a birth year on its own when you only know the year and not a full date of birth.

This applies everywhere clients are added — manual entry, spreadsheet imports, and public intake forms — so birth year stays consistent no matter how a client comes in.

Fixed PDF exports failing

We fixed a bug that caused PDF downloads to fail with a generic error.

This affected the client resume export, board meeting minutes export, and the board giving report export. All three now generate and download reliably. No action needed — just try the export again.

Quick-start links on an empty Reports page

The Reports page no longer shows a blank "no reports yet" message when you're just getting started. Instead, it now offers quick links to create each kind of report:

  • Client report, Service report, Event report, and Volunteer reports — each takes you straight to where that report is created.
  • Choosing Client report opens the report builder for you right away.

Once you have reports, the page looks and works exactly as before.

Fixed the form builder failing to load

We fixed a bug that could cause the Create form page to show an "Oops! Something went wrong" error instead of loading the builder.

The page now opens reliably so you can build client, service, event, and feedback forms without interruption. No action is needed on your part — if you hit this error before, just reload and you're good to go.

Offer an event at multiple timeslots

A single event can now run at several timeslots, and you can track who is registered and who showed up for each one.

  • Add multiple timeslots to an event (for example a recurring class or a multi-track program), each with its own time, location, and capacity.
  • When adding an attendee, choose which timeslot they're registering for — or leave them event-wide if timeslots don't apply.
  • Each timeslot shows its own registered count and capacity, and warns you when a slot is full so you can waitlist.
  • Check-in is recorded against the attendee's timeslot, so attended counts are accurate per session.
  • Removing a timeslot keeps its attendees — they simply move back to event-wide rather than being deleted.

Events with a single time keep working exactly as before — timeslots are optional.

Week of June 8, 20263 updates

Confirm data-sharing consent when linking a funding partner

Linking your organization to a funding partner now asks for your explicit agreement, not just an acknowledgement.

  • When you enter a partner code — during registration or from your settings — you'll now check a box confirming you've read the Funding Partner Data Sharing terms and consent to sharing your organization's anonymized, aggregate data and contact details with that partner.
  • You can't complete the link until the box is checked, and we record the consent (who agreed, and when) so there's a clear, durable record for your organization.

If you don't use a partner code, nothing changes — there's no extra step.

Split a grant's share of each GL account

Grant burn-rate now reflects exactly how much of each account belongs to a grant.

  • When you map a grant to its General Ledger accounts, you can now set a percentage of each account's actuals that counts toward that grant : so a shared account like Salaries can be split (say 60% to one grant, 40% to another) instead of counting in full toward both.
  • You can also set an optional dollar cap per account, for funders who only cover a fixed amount of a category.
  • Existing mappings are unchanged : they continue to count the full account until you set a split.

This makes the By-Grant view and burn-rate accurate for organizations that share cost accounts across multiple grants.

Clearer disclosure of funding partner data sharing

We've made it clearer what linking your organization to a funding partner means for your data.

  • Our Terms of Service now include a dedicated Funding Partner Data Sharing section that spells out exactly what a funding partner can see when your organization is linked: anonymized, aggregate information about your clients and services (like total counts and demographic summaries) and your organization's own contact details. Individual client information — names, contact details, addresses, dates of birth, or case notes — is never shared.
  • When you enter a partner code, either during registration or from your settings, you'll now see this disclosure right next to the code field, with a link to the full terms.

Nothing about how funding partners see your data has changed — this update makes the existing behavior transparent at the moments it matters.

Week of June 1, 20261 update

Map grants to GL accounts and scope per-user access

The QuickBooks Budget views can now be set up entirely from the app — no more asking us to wire things up behind the scenes.

A few highlights:

  • Map grants to GL accounts. Open any grant and pick its General Ledger accounts from a searchable list. Once a grant is mapped, its budget-vs-actuals and burn-rate fill in automatically.
  • Jump straight to the fix. On the Budget page's By Grant tab, the "Not mapped to GL accounts" note is now a link that takes you right to that grant's GL accounts.
  • Per-user GL access. Owners and admins can choose exactly which GL accounts each team member can see on the Budget page, so program staff see their program's spending without the org's full financial picture.
  • A cleaner Budget page. We tightened up the spacing and tables so everything is easier to scan, including on smaller screens.

You'll find the new GL accounts section on each grant, and per-user access under Settings → Integrations → QuickBooks.

All months