Views:

GOsupport Logo

 

 

Revised 08/13/2026

 

These release notes highlight the enhancements and fixes planned for this release. As final testing and validation are completed, this living document may be updated prior to the release date. 
 

Important: The notes reflect product functionality as of the release date and will not be updated afterward to capture future enhancements, changes, or newly published Knowledge Articles. Documentation links will be added when available. For the most up-to-date product information, tips, and documentation, please visit GOsupport.

  akoyaGO

Bug Fixes

Administration & Security

Integration Settings and Mailbox Approval
DevOps Work Item: 16283
Product Suggestion: 000000000005454

Release Note

Some administrators previously encountered security errors when approving mailboxes or running certain Power Automate flows because the system unnecessarily checked access to the Integration Settings table.

This behavior has been corrected. Mailbox approval now relies only on the permissions required to approve mailboxes and is no longer blocked by unrelated Integration Settings access requirements.

What Changed / What to Watch

  • Mailbox approvals no longer depend on access toakoya_integrationsettings.
  • Delegated mailbox approver permissions are sufficient for mailbox approval scenarios.
  • Most organizations should not require additional CRM security role changes.
  • If you continue receiving errors referencing akoya_integrationsettings, provide the full error details to GOsupport.

User Experience

Knowledge Article Table Appearing in Grants Management Navigation
DevOps Work Item: 16180
Product Suggestion: 000000000005448

Release Note

In some environments, the Knowledge Article table appeared unexpectedly within the Grants Management navigation area.

This navigation issue has been corrected so users only see the intended grants-related navigation options.

What Changed / What to Watch

  • Knowledge Articles should no longer appear in Grants Management navigation.
  • No action is required from administrators.
  • If unexpected navigation items still appear, clear your browser cache and contact GOsupport.

akoyaGO Enhancements

Communication & Correspondence

Bulk Email Functionality
DevOps Work Item: 14867
Product Suggestion: 000000000003773

Release Note

akoyaGO now supports sending the same email to multiple records at once directly from list views.

Users can select multiple records, choose Send Email, select the recipient source (such as a Primary Contact or another email-enabled lookup field), choose a sender, and select an Email Template. akoyaGO sends the emails and automatically tracks each message back to the related record timeline, making it easy to review outbound communication history. For more information, please see Bulk Email Feature (Send Email Button)

This functionality is available for supported record types that use Activities and email tracking.

What Changed / What to Watch

  • Bulk email can now be initiated directly from supported list views.
  • Each email is tracked back to the originating record's timeline.
  • Records without valid recipient email addresses may be skipped.
  • If emails do not appear on timelines, verify the record supports Activities and that the correct recipient option was selected.
  • Support staff can review the record timeline to validate email delivery activity.

Email Option for Letter Templates
DevOps Work Item: 11565

Release Note

Letter Templates can now be emailed directly from akoyaGO.

When generating a letter, users can choose Send as Email, select the recipient, choose the sending user, and decide whether the letter should appear in the email body or be sent as an attachment. For more information, please see Generating Letters Using Letter Templates - Send Email.

The email is automatically linked back to the source record so staff can easily see what was sent, when it was sent, and by whom.

What Changed / What to Watch

  • Letter Templates can now be delivered by email without generating PDFs first.
  • Emails can include the letter as the body content or as an attachment.
  • Batch sends only process records with valid email addresses.
  • Records without email addresses may require PDF-based follow-up communication.
  • Large attachment-based mailings may increase Dataverse storage consumption.
  • If using Email Templates, verify that the selected template matches the appropriate record type so merge fields populate correctly.


Legacy Letter Template Lookup Fields Removed
DevOps Work Item: 14889
Product Suggestion: 000000000004988

Release Note

Legacy Letter Template lookup fields have been removed from Request, Gift, and Payment records.

These fields supported an earlier custom letter-generation framework that relied on Power Automate and are no longer used by the current communication tools available in akoyaGO.

This change simplifies forms and removes fields that no longer provide business value.

What Changed / What to Watch

  • Legacy Letter Template lookup fields have been removed from Requests, Gifts, and Payments.
  • Related form references have been removed.
  • Current letter generation and email functionality are not affected.
  • Organizations with custom reports, integrations, exports, or documentation referencing these legacy fields should review those resources and update them as needed.

Scholarships Eligible Field Renaming
DevOps Work Item: 16517

Release Note

The legacy Scholarships Eligible field has been renamed and documented to make it clear that it is no longer used by current GOapply automatching functionality.

This helps reduce confusion and encourages organizations to use the current scholarship matching tools rather than older custom automation approaches.

What Changed / What to Watch

  • The field now clearly indicates that it is deprecated.
  • Descriptions have been updated to explain its historical purpose.
  • New automation should use current GOapply matching features rather than this field.

Administration & System Configuration

Document Management Settings – Prevent "Based on Entity"
DevOps Work Item: 15520
Product Suggestion: 000000000005208

Release Note

akoyaGO now proactively detects use of the unsupported Based on Entity document management structure and alerts administrators when it is found.

This configuration is not supported because it can interfere with document-related functionality, including Letter Templates and other document management features.

Organizations using this structure will receive guidance directing them to GOsupport for remediation.

What Changed / What to Watch

  • Unsupported document management configurations are now detected automatically.
  • Warning messages help administrators identify affected environments.
  • Organizations currently using Based on Entity should work with GOsupport to transition to a supported configuration.
  • Correcting this configuration can improve compatibility with current and future document management enhancements.

Request Management

Allow Clearing Special Request Status via Bulk Update
DevOps Work Item: 15791

Release Note

Managing large numbers of Requests is now easier with a new None option on the Special Request Status field.

Users can now clear Special Request Status values across multiple Requests using Bulk Update instead of opening and updating records individually. When the special status is removed, akoyaGO automatically re-evaluates the Request using the standard Request Status logic.

What Changed / What to Watch

  • A newNoneoption is available for Special Request Status.
  • Special Request Status can now be removed using Bulk Update.
  • Request Status values are recalculated automatically after the special status is cleared.
  • Users should review resulting Request Status values after bulk updates to confirm they match organizational expectations.

  akoyaGO with Accounting

akoyaGO with Accounting Bug Fixes

Donor & Contact Management

Donor Email and Address Updates After Contact Merges
DevOps Work Item: 16076

Release Note

When Contacts were merged, the related Donor record did not always refresh its email address and contact information correctly. In some situations, the Donor continued displaying outdated information even though the primary Contact had changed.

This issue has been corrected. Donor records now refresh email and address information from the preserved primary Contact when Contact merges occur or when the primary Contact relationship changes.

What Changed / What to Watch

  • Donor records now refresh email and address information after Contact merges.
  • Future merges should correctly reflect information from the surviving Contact record.
  • Previously affected Donors may require a manual update to refresh existing values.
  • If donor information still appears incorrect after a merge, review the Contact relationship and contact GOsupport.

Pledges

Recalculating Scheduled Pledge Payments
DevOps Work Item: 16079
Product Suggestion: 000000000005405

Release Note

Some team users were unable to recalculate pledge payment schedules because the underlying process attempted to delete and recreate Gift Payment records. Since Team users typically do not have delete permissions, the recalculation would fail.

This issue has been corrected. Team users can now recalculate pledge schedules successfully without requiring additional security permissions.

What Changed / What to Watch

  • Team users can now recalculate pledge schedules successfully.
  • Updated payment schedules are recreated correctly.
  • No security role changes should be required.
  • If recalculation still fails, review the resulting error details for unrelated validation issues.

Payment Processing & Adjustments

Refund Reversal Error on Parent Payments
DevOps Work Item: 15795
Product Suggestion: 000000000005301

Release Note

Previously, if a refund or adjustment was voided, the original parent payment could continue to be treated as adjusted. This prevented staff from making additional corrections and could generate an incorrect "previously adjusted" error message.

This behavior has been corrected. Once a refund or adjustment child payment is voided, the original parent payment can again be adjusted or voided as needed.

What Changed / What to Watch

  • Voided refund and adjustment records no longer block parent payment corrections.
  • Parent payments can be adjusted or voided after all related child records are voided.
  • Active refund and adjustment records continue to prevent changes.
  • Finance teams should continue following established approval procedures before processing adjustments.

Lock Payment Status When Reversed (Request Payments)
DevOps Work Item: 16357
Product Suggestion: 000000000005478

Release Note

When a Request Payment has been reversed, the Payment Status field is now read-only.

This prevents accidental status changes after reversals have been processed and helps maintain consistency between akoyaGO and Business Central.

What Changed / What to Watch

  • Users can no longer manually edit Payment Status on reversed Request Payments.
  • Corrections should follow standard adjustment and reversal procedures.
  • Organizations should review any imports or integrations that update Payment Status values.

Pledge Payments with Gift Fees – Adjustment Support
DevOps Work Item: 16305
Product Suggestion: 000000000005465

Release Note

Staff can now adjust pledge-related payments that include gift fees. Previously, Business Central rejected these adjustments when fee information changed, even when the adjustment was otherwise valid.

The system now supports updating both payment amounts and gift fee amounts while maintaining existing accounting controls.

What Changed / What to Watch

  • Pledge payment adjustments now support gift fee updates.
  • Updated fee information is transferred correctly to Business Central.
  • Existing restrictions on unsupported accounting changes remain in place.
  • If an adjustment still fails, review the error details for other restricted fields or validation issues.

Gift Processing & Fees

Gift Quick Create – Commitment vs Amount Mismatch
DevOps Work Item: 16409
Product Suggestion: 000000000005496

Release Note

When creating a non-split gift using Quick Create, Amount 1 is now always visible. This makes it easier to keep Commitment and Amount 1 aligned and helps prevent Total Amount Mismatch errors during save.

What Changed / What to Watch

  • Amount 1 is now visible for single-fund gifts.
  • Users should review Amount 1 after modifying Commitment.
  • Training materials referencing previous Quick Create behavior may need updating.

Gift Fees: Automatic Fee Amount Calculation from Workflows
DevOps Work Item: 16064
Product Suggestion: 000000000005402

Release Note

Gift Payment Fee Amounts now recalculate automatically when Gift Fees are assigned or changed through workflows, business rules, integrations, APIs, or other background processes.

This ensures fee amounts stay synchronized regardless of how the fee is applied.

What Changed / What to Watch

  • Fee Amounts automatically recalculate when Gift Fee selections change.
  • Workflow and API-driven updates now behave consistently with manual form updates.
  • Manual fee overrides continue to be respected.
  • Unchanged values no longer trigger unnecessary recalculation activity.

Interfund Grants

Interfund Quick Create – Function Not Required
DevOps Work Item: 15945
Product Suggestion: 000000000005371

Release Note

Gift Function and Grant Function are no longer required when creating Interfund Grants through Quick Create. These fields remain optional, and the system will continue applying default values from Accounting Settings when appropriate.

What Changed / What to Watch

  • Gift Function and Grant Function are no longer required fields.
  • Default accounting settings continue to populate values where appropriate.
  • Additional field guidance and tooltips are available to assist users.

Interfund Defaults vs Processed Records
DevOps Work Item: 16317
Product Suggestion: 000000000005469

Release Note

Previously, Interfund Grants that had already been processed could be updated with newer accounting defaults when opened, potentially preventing reversals or causing save errors.

Processed Interfund Grants now retain the values that existed when they were originally sent to accounting.

What Changed / What to Watch

  • Processed Interfund Grants no longer inherit newly configured default values.
  • Existing accounting information remains stable after processing.
  • Interfund reversals should complete more reliably.
  • Organizations can safely modify Accounting Settings without affecting previously processed grants.

Configuration & Data Integrity

Prevent Duplicate Fund-to-Formula Assignments
DevOps Work Item: 16370

Release Note

The system now prevents the same Fund from being assigned to the same Fund Fee Formula more than once.

This helps prevent duplicate fee calculations, unexpected charges, and configuration inconsistencies.

What Changed / What to Watch

  • Duplicate Fund-to-Formula relationships can no longer be created.
  • Users receive an error when attempting to add a duplicate assignment.
  • Existing duplicate records should be reviewed and cleaned up if present.

akoyaGO with Accounting Enhancements

Payment Processing & Controls

Send to Accounting for Error Records
DevOps Work Item: 10942
Product Suggestion: 000000000003795

Release Note

Finance users can now resend Gift Payments and Request Payments that previously failed to send to Business Central without opening each record individually.

When a payment has a Payment Status of Error, users can now select one or more corrected payments from a list view and use Send to Accounting to resubmit them in bulk. This brings bulk processing behavior in line with the functionality already available from individual payment records.

This enhancement makes it much easier to recover from accounting-related errors, particularly when multiple payments require correction and resubmission.

What Changed / What to Watch

  • Error Request Payments and Gift Payments can now be resent from list views.
  • Bulk Send to Accounting behaves consistently with the individual form action.
  • Payment Status and Payment Status Details update correctly during reprocessing.
  • If a payment still fails to send, verify that all required accounting information has been corrected before retrying.

Prevent Bulk Send to Accounting When Exceeding Available to Spend
DevOps Work Item: 16482

Release Note

When multiple Request Payments are sent to accounting at the same time, akoyaGO now validates each payment against the Fund's available spendable balance before sending it to Business Central.

If a payment would cause the Fund to exceed its available spendable amount, the payment is excluded from bulk processing and marked as Error. Other eligible payments in the same batch continue processing normally.

This provides an additional safeguard against accidental overspending while still allowing organizations to use bulk accounting workflows efficiently.

What Changed / What to Watch

  • Bulk Send to Accounting now validates spendable balance before processing payments.
  • Payments that exceed the available balance are moved to Error status.
  • Eligible payments in the same batch continue processing normally.
  • Organizations can still intentionally override the check by sending an individual payment from the Request Payment record if foundation policy allows.
  • Finance teams should review Error records and linked error messages before resubmitting payments.

Payment Adjustments & Accounting Detail

Memo Editing on Payment Adjustments and Reversals
DevOps Work Item: 16502

Release Note

Request Payment and Gift Payment adjustment forms now include a Memo field, making it easier to update the accounting description during an adjustment.

This is especially helpful when changing a payee, correcting transaction details, or making other adjustments where the description that appears in Business Central should also be updated.

If a new memo is provided during the adjustment process, that memo is carried through to the resulting adjusted payment and the related journal entries created in Business Central.

What Changed / What to Watch

  • A Memo field is now available on Request Payment and Gift Payment adjustment forms.
  • Updated memos flow through to the adjusted payment record and related Business Central journal entries.
  • If no memo is entered, the existing memo is retained.
  • Memo changes cannot be processed as stand-alone adjustments and must be part of a valid payment adjustment.
  • Memo fields do not appear on refund and void processes.

Fund Management

Age of Fund and Anniversary Date
DevOps Work Item: 15793

Release Note

Two new calculated fields have been added to the Fund record to help organizations monitor the age and anniversaries of their funds.

Age of Fund calculates how long the Fund has existed based on its Established Date, while Anniversary Date identifies the fund's anniversary in the current calendar year.

These fields make it easier to identify milestone anniversaries, support stewardship efforts, and build anniversary-based dashboards and reports.

What Changed / What to Watch

  • Age of Fund and Anniversary Date are now available on the Fund Detail tab.
  • Both fields can be used in views, dashboards, and reporting.
  • Values update automatically over time.
  • Development and donor engagement teams can use these fields to identify upcoming milestone anniversaries.

Fund-Level Gift Fees
DevOps Work Item: 15558
Product Suggestion: 000000000005065

Release Note

Funds can now define a default administrative Gift Fee directly on the Fund record.

When gifts or Gift Payments are created for that Fund, akoyaGO automatically applies the configured Gift Fee instead of requiring organizations to rely on workflows or manual selection.

This helps ensure administrative fees are applied consistently and reduces the amount of maintenance required to support fee-related business processes.

What Changed / What to Watch

  • A new Default Gift Fee lookup is available on the Fund record.
  • Default Gift Fees are automatically applied when the Fund is selected.
  • If all available Gift Fee slots are already populated, users will be prompted before replacing existing fees.
  • The feature supports pledge scenarios and GOdonate transactions.
  • Finance teams should review existing workflows that previously assigned Gift Fees and determine whether those automations are still needed.

New Funds by Year Chart Based on Established Date
DevOps Work Item: 16399

Release Note

The New Funds by Year chart now uses the Fund's Established Date instead of the record creation date.

For many organizations, especially those that migrated historical fund data into akoyaGO, this provides a much more accurate representation of when funds were actually established rather than when they were imported into the system.

This change improves reporting, anniversary tracking, and year-over-year trend analysis.

What Changed / What to Watch

  • The chart now groups funds using the Established Date fiscal year.
  • Historical funds imported during conversions will no longer appear as "new" in the migration year.
  • Fund trends and anniversary reporting should align more closely with actual fund history.
  • Organizations that reference this chart in dashboards or reports should review the updated results.

Number of GOfund Users on Fund
DevOps Work Item: 15792

Release Note

Funds now include a calculated field showing the number of active GOfund users who currently have Donor Portal Access to the Fund.

The count automatically considers security role assignments, active connections, and effective dates, providing staff with a quick way to understand Fund-level GOfund engagement.

What Changed / What to Watch

  • A new calculated field displays the number of active GOfund users associated with the Fund.
  • The value updates automatically as connections are created, modified, or deactivated.
  • The field can be used in views, dashboards, and reporting.
  • Development and engagement teams can use this information to monitor portal adoption.

Interfund Grants

Custom Description Fields for Interfund Grants
DevOps Work Item: 15806

Release Note

Interfund Grants now support custom accounting descriptions that flow into Business Central.

Two new optional fields, Gift Description and Grant Description, allow staff to provide more meaningful transaction descriptions for accounting and reporting purposes.

If no custom description is entered, the existing behavior remains unchanged and Business Central continues using the default description of Interfund Grant.

This enhancement improves General Ledger visibility and provides more context for users who review accounting activity directly in Business Central.

What Changed / What to Watch

  • New Gift Description and Grant Description fields are available on Interfund Grants.
  • Descriptions are transferred to Business Central and appear on related accounting entries.
  • If no description is entered, the default description remains Interfund Grant.
  • Finance teams should consider establishing standards for how custom descriptions are used.
  • Reports and GL reviews may now display more detailed transaction descriptions.

  Business Central

Business Central Bug Fixes

Fund Accounting & Dimensions

Multi-Dimension Support – Clearing Dimensions When Fund Is Cleared
DevOps Work Item: 15261

Release Note

When a Fund was changed or removed on a General Journal line, related Fund Dimensions such as Department, Class, Type, and Endowed were not always cleared correctly. This could leave outdated values on transactions and create inconsistent accounting records.

The system now removes and reapplies Fund Dimensions appropriately whenever the Fund changes, helping ensure transactions reflect the current Fund selection.

What Changed / What to Watch

  • Fund Dimensions are now cleared when a Fund is removed.
  • Dimension values are refreshed when switching between Funds.
  • Old Class, Type, and Endowed values no longer remain on journal lines after a Fund change.
  • Finance teams should continue reviewing journal entries after significant Fund configuration changes.

Fund Default Dimensions Not Populated During Payment Process
DevOps Work Item: 15799

Release Note

Fund default dimensions such as Class and Type were not always carried from the original payable transaction to the final payment entry. This sometimes resulted in incomplete reporting and additional reconciliation work.

Payments now inherit Fund default dimensions consistently throughout the payment process.

What Changed / What to Watch

  • Class and Type dimensions now flow correctly to payment entries.
  • General Ledger reporting should be more consistent between invoices and payments.
  • Finance teams may wish to spot-check several recent payments after deployment.

Purchase Invoice Posting with Multiple Dimensions
DevOps Work Item: 16320
Product Suggestion: 000000000005473

Release Note

Certain invoices containing multiple dimensions could fail to post correctly when Vendor Invoice Number values approached system length limits.

The system now validates these conditions correctly and prevents incomplete posting scenarios.

What Changed / What to Watch

  • Invoice posting is more reliable when multiple dimensions are present.
  • Users receive clearer feedback when invoice number limitations are encountered.
  • Finance teams should continue reviewing posting exceptions when vendor invoice numbers are unusually long.

Deposits & Reconciliation

Undeposited Funds – Auto-Correcting Dimensions and Better Visibility
DevOps Work Item: 16531

Release Note

When transferring Undeposited Funds into Bank Deposits, dimension information was previously copied from the source entries, even if those dimensions were outdated or incorrect.

The process now automatically applies the correct Fund Dimensions based on Fund configuration before posting. Additional visibility tools have also been added to simplify reconciliation and troubleshooting.

What Changed / What to Watch

  • Fund Dimensions are corrected automatically during transfer.
  • Additional columns and FactBoxes are available for reconciliation.
  • Manual correction of Undeposited Fund dimensions is generally no longer required.
  • Support and finance teams can use the added visibility tools to investigate variances more easily.

Payment Processing

Payroll Check Stubs – Fund Name and Document Date
DevOps Work Item: 16411

Release Note

In some payroll and manual check scenarios, Fund Name and Document Date values did not always print correctly on check stub layouts.

This issue has been corrected so these values display consistently across supported layouts.

What Changed / What to Watch

  • Fund Name now displays correctly on applicable payroll and manual checks.
  • Document Date now prints consistently across supported layouts.
  • If a check still displays unexpected information, provide the check layout and scenario to GOsupport.

Payment Reversals Using Incorrect Bank Account
DevOps Work Item: 16163

Release Note

Certain reversals could incorrectly select the first available bank account rather than the bank account used on the original transaction.

Reversals now use the appropriate originating bank account, improving accounting accuracy and reducing corrective work.

What Changed / What to Watch

  • Reversals now reference the correct source bank account.
  • Bank account selections should remain consistent with the original transaction.
  • Finance teams should review reversal activity during the first release cycle after deployment.

Vendor & Constituent Synchronization

Vendor Block and Privacy Blocked Behavior
DevOps Work Item: 15928
Product Suggestion: 000000000005364

Release Note

Changes to Vendor Blocked status in Business Central did not always synchronize correctly with related records in akoyaGO.

Synchronization logic has been improved so blocked and unblocked statuses remain aligned between Business Central and CRM while better handling complex Vendor, Customer, and Contact relationships.

What Changed / What to Watch

  • Vendor Blocked changes now synchronize more reliably.
  • Organizations receive clearer prompts when multiple related records are involved.
  • CRM records remain aligned with Business Central status changes.
  • Administrators should monitor unusual Vendor/Customer relationship scenarios after deployment.

Fund Fee Processing

Fund Fee Calculation Accuracy
DevOps Work Item: 16708
Product Suggestion: 000000000005552

Release Note

A defect in Average Daily Balance calculations could cause certain monthly Fund Fee calculations to use an incorrect number of days.

The calculation now uses the proper date range when determining Average Daily Balance Fund Fees.

What Changed / What to Watch

  • Average Daily Balance calculations now use the correct day count.
  • Future fee runs will calculate more accurately.
  • If an affected fee run was already processed, recreate the batch after deployment.

Fund Fee Job Queue and Error Logging Improvements
DevOps Work Items: 16420, 16421, 16604, 16582

Release Note

Several issues made Fund Fee and Spendable calculations difficult to troubleshoot, particularly when jobs failed or calculations encountered tier-related errors.

Error handling and calculation logging have been improved to provide clearer diagnostics, more detailed batch-level visibility, and more accurate timestamps.

What Changed / What to Watch

  • Tier-related calculation failures are easier to identify.
  • Calculation logs now display accurate timestamps.
  • Error details appear closer to the affected records.
  • Finance teams can more confidently troubleshoot and rerun failed calculations.

Business Central Enhancements

Fund Fee Administration

Account Filter Validation on Fund Fee Formulas
DevOps Work Item: 16036

Release Note

Custom Account Filters used for Fund Fee and Spendable calculations are now validated before they can be saved.

This prevents invalid filter syntax from reaching Business Central and causing calculation failures later in the process.

What Changed / What to Watch

  • Invalid account filter syntax is detected immediately.
  • Users receive clearer error messages when configuration issues exist.
  • Fund Fee and Spendable calculations should fail less frequently due to configuration problems.

Vendor Banking

Vendor Bank Account Import
DevOps Work Item: 15472
Product Suggestion: 000000000005190

Release Note

Finance staff can now import Vendor Bank Accounts directly into Business Central using spreadsheets and upload tools.

The import process includes validation, staging, error reporting, and retry capabilities, making it significantly easier to onboard or update large numbers of vendor banking records.

What Changed / What to Watch

  • Vendor Bank Accounts can be imported in bulk.
  • Validation occurs before import.
  • Invalid rows remain available for correction and resubmission.
  • Finance teams should review template requirements before importing large datasets.

Vendor Bank Account Bulk Edit List
DevOps Work Item: 16139

Release Note

A new Vendor Bank Account List page provides a centralized place to review, edit, and maintain vendor bank accounts.

The list supports direct editing of common fields while still providing access to full Vendor Bank Account records when additional detail is needed.

What Changed / What to Watch

  • Vendor Bank Accounts can be managed from a centralized list page.
  • Common fields can be edited more efficiently.
  • Finance teams can review banking information without opening individual records.

Fund Management

Separate Net Asset Sweep Flag
DevOps Work Item: 15815

Release Note

Net Asset Sweep eligibility can now be managed independently from the Endowed setting on a Fund.

This provides greater flexibility for organizations that manage quasi-endowed or special-case Funds with treatment that differs from traditional endowed Funds.

What Changed / What to Watch

  • Net Asset Sweep is now controlled by its own field.
  • Endowed status no longer automatically determines sweep participation.
  • Existing data has been aligned to preserve current behavior.
  • Finance teams should review sweep settings on Funds with special handling requirements.

Financial Controls & Reporting

Show Only Active Accounts by Default
DevOps Work Item: 15473

Release Note

Business Central now shows active Chart of Accounts records by default in key accounting screens.

This reduces clutter, helps prevent accidental selection of inactive accounts, and simplifies navigation for day-to-day accounting tasks.

What Changed / What to Watch

  • Blocked accounts are hidden by default in major accounting views.
  • Historical accounts remain available when needed.
  • Users may need to adjust filters if they need to review inactive accounts.

MICR Font Support on akoyaGO Check Layouts
DevOps Work Item: 15475

Release Note

akoyaGO check layouts now support MICR-formatted fields for routing numbers, account numbers, and check numbers.

This allows organizations using MICR-compatible printers to configure bank-readable checks without custom development.

What Changed / What to Watch

  • MICR fields are available on supported check layouts.
  • Fields are hidden by default until configured.
  • MICR positioning should be tested and aligned during implementation.
  • Organizations using MICR printing should validate layouts before production use.

  GOapply

GOapply Bug Fixes

User Invitations & Account Access

Verification Links for Older Pending Users
DevOps Work Item: 15808
Product Suggestion: 000000000005305

Release Note

GOapply Users who remained in Pending Email Verification for extended periods could encounter invalid verification links when staff resent their verification email.

Verification emails now generate the correct security scope and allow users to successfully verify their account, even if the account was created months earlier.

What Changed / What to Watch

  • The Diagnostics tool can now safely resend verification emails for older pending users.
  • Resent verification links should complete successfully.
  • If verification still fails, confirm the user is using the most recent verification email.
  • Check browser behavior or email scanning tools if users continue experiencing issues.

Invited GOapply Users Incorrectly Requiring Approval
DevOps Work Item: 15861
Product Suggestion: 000000000005325

Release Note

Some invited GOapply users could not sign in because their account remained in a Pending Approval state even after administrators invited them through the Add GOapply Users process.

The invitation process now creates the correct activation records and moves invited users through the appropriate status workflow based on GOapply settings.

This ensures invited users follow the intended onboarding process rather than being treated like self-registered applicants.

What Changed / What to Watch

  • Invited users now receive proper activation records.
  • Status changes occur correctly after invitation and email verification.
  • Foundation staff should see fewer invitation-related sign-in issues.
  • Support staff should monitor newly invited users during the initial rollout period.

Invalid Email Validation When Adding GOapply Users
DevOps Work Item: 16293
Product Suggestion: 000000000005462

Release Note

Previously, improperly formatted email addresses could partially create GOapply User records before the process failed.

Email addresses are now validated before any GOapply User, identity record, or invitation is created.

This helps prevent incomplete user records and makes support and administration easier.

What Changed / What to Watch

  • Email validation occurs during both individual and bulk processing.
  • Only valid email addresses proceed to user creation.
  • Invalid records remain available for correction and resubmission.
  • Error messages now clearly identify invalid email address scenarios.

Duplicate Email – User Already Exists
DevOps Work Item: 16363
Product Suggestion: 000000000005480

Release Note

When an Add GOapply Users record references an email address that already belongs to an existing GOapply User, the system now provides clearer feedback.

Instead of giving the appearance that a new account was created, the system explains that the user already exists and prevents duplicate account creation.

What Changed / What to Watch

  • Administrators receive clearer duplicate-user messages.
  • Duplicate identity records are prevented.
  • Bulk imports report which users were created and which already existed.
  • Support staff should verify existing GOapply Users before creating new accounts for the same individual.

Scholarships & Awards

Scholarship Lookup Populates Payment Records
DevOps Work Item: 16125
Product Suggestion: 000000000005425

Release Note

When staff approved a Requested Scholarship, the resulting Payment record did not always populate the related Scholarship lookup.

The approval process now consistently carries Scholarship information to associated Payment records, improving reporting and making it easier for staff to understand which scholarship generated a payment.

What Changed / What to Watch

  • Payment records now populate the Scholarship field during the Requested Scholarship approval process.
  • Scholarship reporting should be more accurate and complete moving forward.
  • Older Payment records created before this fix may still contain blank Scholarship values.
  • If Scholarship values are still missing, confirm the approval path used and verify that the Payment record was created successfully.

GOapply Enhancements

Forms & Data Collection

Add Currency Unmapped Question Type in Simple Form Builder
DevOps Work Item: 15963
Product Suggestion: 000000000005347

Release Note

Simple Form Builder now includes a new Currency question option in the Unmapped section. This makes it easier to collect dollar-amount answers in a consistent, familiar currency format—so amounts display with commas and two decimal places, just like other currency fields. This helps foundation staff and applicants enter and review financial information more clearly and with fewer formatting workarounds.

What changed / what to monitor:

  • When building forms, staff can now choose Currency for unmapped questions instead of using a generic Number field.
  • After publishing a form, confirm that currency answers display with two decimal places (for example,10,000.00) in previews and in GOapply pages where applicants enter responses.

Forms & Data Collection

Advanced Form Builder – Currency, Email, and Phone Mapping
DevOps Work Item: 16152
Product Suggestion: 000000000005436

Release Note

Currency, Email, and Phone question types can now be mapped consistently to CRM fields in Advanced Form Builder.

Previously, some field types did not behave consistently with standard text questions and could make field mapping appear unavailable or broken.

The mapping experience now behaves consistently across supported field types.

What Changed / What to Watch

  • Currency questions can now be mapped directly to Money fields.
  • Email questions can be mapped directly to Email fields.
  • Phone questions can be mapped directly to Phone fields.
  • The Target View option only appears when relevant, reducing confusion during form configuration.
  • Existing mappings continue to function normally.

Scholarship Administration & Automatch

Opt In Enabled Renamed to Auto Match Enabled

DevOps Work Item: 16518

Release Note

The Scholarship field previously labeled Opt In Enabled has been renamed to Auto Match Enabled.

The new name more accurately reflects the field's purpose and reduces confusion about how scholarship automatching is configured.

What Changed / What to Watch

  • The field now displays as Auto Match Enabled throughout GOapply.
  • Existing behavior remains unchanged.
  • Staff should review documentation and training materials that reference the previous name.

Automatch Enabled Scholarships View
DevOps Work Item: 16519

Release Note

A new system view called Automatch Enabled Scholarships is now available.

This view provides a quick way to identify active scholarships currently participating in GOapply automatching.

Program staff can use it to review scholarship availability and verify configuration before opening application cycles.

What Changed / What to Watch

  • The new view filters for active scholarships with Auto Match Enabled set to Yes.
  • Important scholarship information is available in a single location.
  • Program staff should periodically review the view to ensure scholarships are configured appropriately.

Review Management

Publish Date for Review Groups
DevOps Work Item: 15967

Release Note

Review Groups can now be configured in advance and scheduled to become visible on a future date.

The new Publish Date field allows administrators to prepare review groups, assign reviewers, and control exactly when those groups become available.

This provides more flexibility when planning review cycles and coordinating reviewer communications.

What Changed / What to Watch

  • A Publish Date field has been added to Review Group Settings.
  • Review Groups remain hidden until the configured Publish Date is reached.
  • If no Publish Date is specified, behavior remains unchanged and groups are visible immediately.
  • Programs should align Publish Dates with reviewer communications and application timelines.

  GOfund

GOfund Bug Fixes

Invitations & Account Access

Resend Invitation Now Regenerates and Successfully Resends Invitations
DevOps Work Item: 16107
Product Suggestion: 000000000005420

Release Note

The Resend Invitation capability has been fixed. Previously, staff could encounter situations where resending a GOfund invitation did not successfully generate a usable invitation for the recipient.

When an invitation is resent, GOfund now generates a fresh invitation and sends a new access link to the user. This makes it easier to reconnect fundholders who missed their original invitation or whose previous invitation has expired.

What Changed / What to Watch

  • Resent invitations now generate new invitation links.
  • Expired or unusable invitations can be replaced with a fresh invitation.
  • If staff cannot resend an invitation, verify the Connection is in an eligible status.
  • Users should allow time for delivery and check spam or junk folders if needed.
  • If the email sends successfully but is not associated to the expected record, investigate email tracking separately.

Grant Recommendations

Repeat Grant Requests No Longer Default to Anonymous
DevOps Work Item: 15920
Product Suggestion: 000000000005353

Release Note

When fundholders used Repeat this Grant Request, new recommendations could sometimes be marked anonymous even when the original recommendation was not anonymous.

Repeated grant recommendations now inherit the anonymity setting from the original recommendation. This reduces the risk of unintentionally submitting anonymous grants.

What Changed / What to Watch

  • Repeated grant requests now respect the anonymity setting from the original recommendation.
  • Grant recommendations should no longer unexpectedly default to anonymous.
  • Fundholders should continue reviewing anonymity selections before submitting recommendations.
  • Organizations may wish to verify anonymity behavior on several repeated recommendations after deployment.

Pending Recommendations Sort Correctly by Amount
DevOps Work Item: 16523
Product Suggestion: 000000000005509

Release Note

Pending Grant Recommendations and Pending Interfund Recommendations now sort correctly by Amount.

Previously, Amount values could be evaluated as text instead of numbers, causing records to appear in unexpected order. Amounts are now treated as numeric values, allowing accurate ascending and descending sorting.

What Changed / What to Watch

  • Amount fields now sort numerically rather than alphabetically.
  • Sorting should behave consistently across pending recommendation views and tables.
  • Support teams should spot-check unusual values, such as negative amounts, if clients use them.
  • If sorting still appears incorrect, capture example records and displayed values for troubleshooting.

Profile & Contact Management

Approved Change Requests Now Apply Data Removals
DevOps Work Item: 16017
Product Suggestion: 000000000005393

Release Note

When fundholders submitted Change Requests to remove information such as phone numbers or addresses, approving the request did not always remove the information from the related CRM Contact record.

Approved Change Requests now correctly apply both additions and removals, ensuring Contact records accurately reflect the information requested by the fundholder.

What Changed / What to Watch

  • Approved Change Requests now support removal of profile information.
  • Optional fields such as phone numbers and addresses can be cleared when approved.
  • Staff should carefully review removal requests before approving them.
  • Required fields such as Name and Email remain protected and cannot be removed.

Donations & Receipts

Duplicate GOfund Donation Receipt Emails
DevOps Work Item: 16644

Release Note

In certain situations, donors could receive multiple receipt confirmation emails for the same GOfund donation.

The receipt generation process has been updated to reserve the transaction before generating the email. This prevents multiple requests from sending duplicate receipt confirmations for the same donation.

The change improves donor experience and reduces confusion caused by duplicate acknowledgements.

What Changed / What to Watch

  • Receipt emails should only be generated once per donation.
  • Refreshing or revisiting confirmation pages should no longer create duplicate receipts.
  • The system can safely retry email delivery when known failures occur.
  • Support staff should continue using transaction history and email logs when investigating receipt-related questions.

GOfund Enhancements

Grant Recommendations

Submit All Now Processes Eligible Items Even When Some Items Contain Errors
DevOps Work Item: 16063
Product Suggestion: 000000000005398

Release Note

The Submit All functionality has been enhanced so fundholders can continue submitting eligible recommendations even when some items in the cart contain errors.

Instead of blocking the entire submission, GOfund now processes recommendations that are ready for submission while leaving items with errors in the cart for later review and correction.

This allows fundholders to continue working without being blocked by a single issue.

What Changed / What to Watch

  • Submit All may process only a portion of the items currently in the cart.
  • Items that contain errors remain available for correction and resubmission.
  • If users think items were skipped, verify which recommendations were eligible when Submit All was selected.

Support teams should confirm whether excluded records were intentionally held back because they were in an error state.

Profile & Contact Management

Change Requests Now Display Current and Proposed Values
DevOps Work Item: 16187

Release Note

Staff reviewing GOfund Change Requests can now see both the current value and the proposed value for information being updated.

This provides greater visibility during the approval process and makes it easier to understand exactly what will change before approving a request.

The enhancement also clearly identifies when a fundholder is requesting the removal of information rather than an update.

What Changed / What to Watch

  • Change Requests now display current values alongside proposed values.
  • Removal requests are clearly identified.
  • Reviewers can more easily verify requested changes before approval.
  • Required fields remain protected from being cleared.
  • Support and administrative staff should use the additional context when reviewing requests.

Fund Information & Reporting

GOfund Connections by Fund Report
DevOps Work Item: 16382

Release Note

A new out-of-the-box report called GOfund Connections by Fund is now available.

The report groups GOfund Connections by Fund, making it easier to see which Contacts currently have Donor Portal Access to each Fund. Organizations can use this report to better understand portal participation, review fundholder access, and identify Funds where additional portal onboarding or engagement efforts may be beneficial.

Previously, many organizations relied on custom views or manually grouped reports to obtain this information. This enhancement provides a standardized reporting option that is available out of the box.

What Changed / What to Watch

  • A new GOfund Connections by Fund report is available.
  • The report groups Donor Portal Access (GOfund) Connections by Fund.
  • Staff can more easily review which Contacts have access to specific Funds.
  • The report can be launched from the Fund record or from reporting areas, depending on environment configuration.
  • Organizations that previously maintained custom reports or manually grouped views for this purpose may be able to retire those processes.
  • Development, donor services, and engagement teams may find this report useful for monitoring GOfund adoption and fundholder access.

 

Number of GOfund Users on Fund
DevOps Work Item: 15792
Product Suggestion: 000000000005142

Release Note

Funds now include a calculated field called No. of GOfund Users that displays the number of active users currently connected to the Fund through the Donor Portal Access (GOfund) relationship.

The calculation automatically evaluates active Connections, effective dates, Connection status, and Donor Portal Access roles to provide an up-to-date count without requiring manual maintenance.

This enhancement gives staff a quick way to understand portal usage at the Fund level and can be incorporated into views, dashboards, reporting, and stewardship activities.

What Changed / What to Watch

  • A new calculated field called No. of GOfund Users is available on the Fund record.
  • The count is maintained automatically as Connections are added, changed, activated, or deactivated.
  • Only active Donor Portal Access (GOfund) Connections are included in the count.
  • Connections outside of their effective date range are excluded automatically.
  • The field can be used in views, dashboards, charts, and reports.
  • Development, donor services, and engagement teams can use this metric to monitor portal adoption and identify Funds where additional outreach may be beneficial.

Scheduled Distributions View and Section Updates
DevOps Work Items: 16361, 16746

Release Note

The Scheduled Distributions area on the Fund Summary page has been updated to provide a more consistent and user-friendly experience for fundholders.

GOfund now uses a dedicated system view specifically designed for Scheduled Distributions rather than relying on a generic view that could be modified or configured differently between environments. In addition, the section heading now displays as Scheduled Distributions instead of exposing the underlying technical view name.

Together, these changes provide a cleaner portal experience and help ensure fundholders see distribution information consistently across environments.

What Changed / What to Watch

  • The Fund Summary page now uses a dedicated system view for Scheduled Distributions.
  • The section title displayed to fundholders has been simplified toScheduled Distributions.
  • Portal users should see more consistent distribution information across Funds.
  • Administrators should verify that the requiredGOfund Scheduled Distributions system view exists in their environment.
  • If customizations were made to previous distribution-related views, review those customizations after deployment to ensure the desired information is still displayed.

Invitations & Account Access

Resend Invitation Now Regenerates and Successfully Resends Invitations
DevOps Work Item: 16107
Product Suggestion: 000000000005420

Release Note

The Resend Invitation capability has been fixed. Previously, staff could encounter situations where resending a GOfund invitation did not successfully generate a usable invitation for the recipient.

When an invitation is resent, GOfund now generates a fresh invitation and sends a new access link to the user. This makes it easier to reconnect fundholders who missed their original invitation or whose previous invitation has expired.

What Changed / What to Watch

  • Resent invitations now generate new invitation links.
  • Expired or unusable invitations can be replaced with a fresh invitation.
  • If staff cannot resend an invitation, verify the Connection is in an eligible status.
  • Users should allow time for delivery and check spam or junk folders if needed.
  • If the email sends successfully but is not associated to the expected record, investigate email tracking separately.

Grant Recommendations

Repeat Grant Requests No Longer Default to Anonymous
DevOps Work Item: 15920
Product Suggestion: 000000000005353

Release Note

When fundholders used Repeat this Grant Request, new recommendations could sometimes be marked anonymous even when the original recommendation was not anonymous.

Repeated grant recommendations now inherit the anonymity setting from the original recommendation. This reduces the risk of unintentionally submitting anonymous grants.

What Changed / What to Watch

  • Repeated grant requests now respect the anonymity setting from the original recommendation.
  • Grant recommendations should no longer unexpectedly default to anonymous.
  • Fundholders should continue reviewing anonymity selections before submitting recommendations.
  • Organizations may wish to verify anonymity behavior on several repeated recommendations after deployment.

Pending Recommendations Sort Correctly by Amount
DevOps Work Item: 16523
Product Suggestion: 000000000005509

Release Note

Pending Grant Recommendations and Pending Interfund Recommendations now sort correctly by Amount.

Previously, Amount values could be evaluated as text instead of numbers, causing records to appear in unexpected order. Amounts are now treated as numeric values, allowing accurate ascending and descending sorting.

What Changed / What to Watch

  • Amount fields now sort numerically rather than alphabetically.
  • Sorting should behave consistently across pending recommendation views and tables.
  • Support teams should spot-check unusual values, such as negative amounts, if clients use them.
  • If sorting still appears incorrect, capture example records and displayed values for troubleshooting.

Profile & Contact Management

Approved Change Requests Now Apply Data Removals
DevOps Work Item: 16017
Product Suggestion: 000000000005393

Release Note

When fundholders submitted Change Requests to remove information such as phone numbers or addresses, approving the request did not always remove the information from the related CRM Contact record.

Approved Change Requests now correctly apply both additions and removals, ensuring Contact records accurately reflect the information requested by the fundholder.

What Changed / What to Watch

  • Approved Change Requests now support removal of profile information.
  • Optional fields such as phone numbers and addresses can be cleared when approved.
  • Staff should carefully review removal requests before approving them.
  • Required fields such as Name and Email remain protected and cannot be removed.

Donations & Receipts

Duplicate GOfund Donation Receipt Emails
DevOps Work Item: 16644

Release Note

In certain situations, donors could receive multiple receipt confirmation emails for the same GOfund donation.

The receipt generation process has been updated to reserve the transaction before generating the email. This prevents multiple requests from sending duplicate receipt confirmations for the same donation.

The change improves donor experience and reduces confusion caused by duplicate acknowledgements.

What Changed / What to Watch

  • Receipt emails should only be generated once per donation.
  • Refreshing or revisiting confirmation pages should no longer create duplicate receipts.
  • The system can safely retry email delivery when known failures occur.
  • Support staff should continue using transaction history and email logs when investigating receipt-related questions.

GOfund Enhancements

Grant Recommendations

Submit All Now Processes Eligible Items Even When Some Items Contain Errors
DevOps Work Item: 16063
Product Suggestion: 000000000005398

Release Note

The Submit All functionality has been enhanced so fundholders can continue submitting eligible recommendations even when some items in the cart contain errors.

Instead of blocking the entire submission, GOfund now processes recommendations that are ready for submission while leaving items with errors in the cart for later review and correction.

This allows fundholders to continue working without being blocked by a single issue.

What Changed / What to Watch

  • Submit All may process only a portion of the items currently in the cart.
  • Items that contain errors remain available for correction and resubmission.
  • If users think items were skipped, verify which recommendations were eligible when Submit All was selected.
  • Support teams should confirm whether excluded records were intentionally held back because they were in an error state.

Profile & Contact Management

Change Requests Now Display Current and Proposed Values
DevOps Work Item: 16187

Release Note

Staff reviewing GOfund Change Requests can now see both the current value and the proposed value for information being updated.

This provides greater visibility during the approval process and makes it easier to understand exactly what will change before approving a request.

The enhancement also clearly identifies when a fundholder is requesting the removal of information rather than an update.

What Changed / What to Watch

  • Change Requests now display current values alongside proposed values.
  • Removal requests are clearly identified.
  • Reviewers can more easily verify requested changes before approval.
  • Required fields remain protected from being cleared.
  • Support and administrative staff should use the additional context when reviewing requests.

Fund Information & Reporting

Scheduled Distributions View and Section Updates
DevOps Work Items: 16361, 16746

Release Note

The Scheduled Distributions area on the Fund Summary page has been updated to provide a more consistent and user-friendly experience for fundholders.

GOfund now uses a dedicated system view specifically designed for Scheduled Distributions rather than relying on a generic view that could be modified or configured differently between environments. In addition, the section heading now displays as Scheduled Distributions instead of exposing the underlying technical view name.

Together, these changes provide a cleaner portal experience and help ensure fundholders see distribution information consistently across environments.

What Changed / What to Watch

  • The Fund Summary page now uses a dedicated system view for Scheduled Distributions.
  • The section title displayed to fundholders has been simplified to Scheduled Distributions.
  • Portal users should see more consistent distribution information across Funds.
  • Administrators should verify that the required GOfund Scheduled Distributions system view exists in their environment.
  • If customizations were made to previous distribution-related views, review those customizations after

GOfund Connections by Fund Report
DevOps Work Item: 16382

Release Note

A new out-of-the-box report called GOfund Connections by Fund is now available.

The report groups GOfund Connections by Fund, making it easier to see which Contacts currently have Donor Portal Access to each Fund. Organizations can use this report to better understand portal participation, review fundholder access, and identify Funds where additional portal onboarding or engagement efforts may be beneficial.

Previously, many organizations relied on custom views or manually grouped reports to obtain this information. This enhancement provides a standardized reporting option that is available out of the box.

What Changed / What to Watch

  • A new GOfund Connections by Fund report is available.
  • The report groups Donor Portal Access (GOfund) Connections by Fund.
  • Staff can more easily review which Contacts have access to specific Funds.
  • The report can be launched from the Fund record or from reporting areas, depending on environment configuration.
  • Organizations that previously maintained custom reports or manually grouped views for this purpose may be able to retire those processes.
  • Development, donor services, and engagement teams may find this report useful for monitoring GOfund adoption and fundholder access.

Number of GOfund Users on Fund
DevOps Work Item: 15792
Product Suggestion: 000000000005142

Release Note

Funds now include a calculated field called No. of GOfund Users that displays the number of active users currently connected to the Fund through the Donor Portal Access (GOfund) relationship.

The calculation automatically evaluates active Connections, effective dates, Connection status, and Donor Portal Access roles to provide an up-to-date count without requiring manual maintenance.

This enhancement gives staff a quick way to understand portal usage at the Fund level and can be incorporated into views, dashboards, reporting, and stewardship activities.

What Changed / What to Watch

  • A new calculated field called No. of GOfund Users is available on the Fund record.
  • The count is maintained automatically as Connections are added, changed, activated, or deactivated.
  • Only active Donor Portal Access (GOfund) Connections are included in the count.
  • Connections outside of their effective date range are excluded automatically.
  • The field can be used in views, dashboards, charts, and reports.
  • Development, donor services, and engagement teams can use this metric to monitor portal adoption and identify Funds where additional outreach may be beneficial.

  GOdonate

GOdonate Bug Fixes

Receipts & Donor Communications

Duplicate GOdonate Receipt Confirmation Emails
DevOps Work Item: 16554

Release Note

In certain situations, donors could receive multiple receipt confirmation emails for the same donation transaction. This could occur when a donor refreshed the confirmation page, a browser submitted multiple completion requests, or overlapping processes attempted to generate a receipt at the same time.

The receipt generation process has been updated to reserve the transaction before an email is queued for delivery. This ensures only one receipt confirmation email is generated for a donation while still allowing the system to recover appropriately from known delivery failures.

This change improves the donor experience by eliminating duplicate acknowledgements and reducing confusion about whether a donation was submitted more than once.

What Changed / What to Watch

  • Receipt confirmation emails should only be generated once per donation transaction.
  • Refreshing or revisiting the confirmation page should no longer trigger duplicate receipts.
  • If a known email delivery failure occurs, the system can safely retry the email.
  • In rare situations where delivery status cannot be confirmed, the transaction remains protected from duplicate sends and details are logged for review.
  • Support staff should continue using transaction history and email logs when investigating receipt-related questions.

Recurring Gift Confirmation and Reminder Email Salutations
DevOps Work Item: 16077
Product Suggestion: 000000000005384

Release Note

Recurring gift confirmation and reminder emails now consistently include a donor greeting.

Previously, some recurring donation emails could be delivered with a blank salutation when donor records had not yet been fully created or linked at the time the recurring gift was established.

GOdonate now captures and stores a salutation when the recurring gift is created. When possible, the donor's name is used. If donor information is not yet available, the system uses information captured during the donation process and falls back to a generic greeting only when necessary.

This creates a more polished donor experience and helps ensure recurring communications remain personalized.

What Changed / What to Watch

  • New recurring gift confirmation and reminder emails should include a salutation.
  • Donor names are used whenever available.
  • Transaction information is used as a fallback when a donor record is not yet available.
  • Previously sent emails are not modified retroactively.
  • Support staff should review unusual salutation values if donors report unexpected greetings.

Payment Processing

Stripe Webhook Reliability Improvements
DevOps Work Item: 16437
Product Suggestion: 000000000005500

Release Note

The GOdonate Stripe webhook process has been improved to better handle payment events that are missing expected metadata values.

Previously, certain Stripe events could generate technical errors even when the payment itself was successful. GOdonate now performs additional validation and matching logic to identify the correct donation transaction whenever possible.

If a matching transaction cannot be identified, the event is logged with additional diagnostic details without causing unnecessary webhook failures or Stripe retry attempts.

This improvement increases payment processing reliability and provides better information when troubleshooting payment-related issues.

What Changed / What to Watch

  • Stripe webhook processing now handles missing metadata more gracefully.
  • Valid payments are less likely to generate technical processing errors.
  • Unmatched events are logged with additional information for troubleshooting.
  • Organizations should see fewer Stripe webhook failures related to missing transaction metadata.
  • Support staff should review logged unmatched events and determine whether manual follow-up is required.

Donation Experience

Clearer Checkout Validation for Tax Credit Recipients
DevOps Work Item: 15971
Product Suggestion: 000000000005378

Release Note

Donors must now explicitly choose who should receive tax credit for a donation before continuing through the checkout process.

Previously, donors could encounter confusing validation messages later in the donation workflow if no selection had been made. GOdonate now performs this validation earlier and displays a clear message next to the Tax Credit Recipient question so donors know exactly what action is required.

The updated experience helps donors complete checkout more successfully and reduces confusion caused by generic validation messages.

What Changed / What to Watch

  • GOdonate validates Tax Credit Recipient selection before checkout continues.
  • Validation messages now appear next to the relevant question.
  • The behavior is consistent for both one-time and recurring donations.
  • No configuration changes are required.
  • If donors report being unable to continue, verify that a Tax Credit Recipient option has been selected before proceeding.