Updated: 6.11.2026

 

June 2026 Comprehensive Release Notes Release Date: 6.26.2026 This document provides an overview of items scheduled for our upcoming product update. As with previous releases, full release notes will be included in our official documentation. We are sharing this information early to help akoyaGO staff prepare for the upcoming changes. Anyone involved in product demonstrations or client training is required to review this material.

 

Bug Fixes

This release includes bug fixes across akoyaGO, GOapply, GOfund, GOdonate, and Business Central. Overall, the fixes improve calculation accuracy, reduce duplicate or blocked actions, make workflows more reliable, and improve emails, portal behavior, and PDF output.

Here are the main types of improvements in this release:

• More accurate data: financial totals, balances, calculations, and record values now reflect the correct information more consistently.

• More dependable workflows: approvals, submissions, status changes, and accounting-related actions are less likely to get stuck, fail, or create duplicate results.

• Improved portal and document experience: emails, reviewer screens, and generated PDFs now behave more consistently and display information more clearly.

• Fix-forward with some follow-up needs: most updates prevent the issue going forward, but some older records or documents may still need review, recalculation, regeneration, or manual cleanup.

---

 

Fiscal year fields in akoyaGO app matched calendar year instead of fiscal year start month (15631)

Area Path: akoyaGO

Problem(s)

For clients who do not use Business Central accounting, the system sometimes used January as the start of the fiscal year when no Accounting Settings record was in place. That caused fund totals and counts for the fiscal year to match the calendar year instead of the client’s actual fiscal year.

Potentially affected users

• Internal: Staff who set up accounting options or review fund totals.

• External: No direct impact. This issue mainly affected internal reporting and setup.

Solution

The fix allows non-Business Central clients to create and use a simpler Accounting Settings record without filling in fields that only apply to Business Central.

• Fields that only apply to Business Central are no longer required for clients who do not use it.

• Those fields are only required when the accounting system is set to something other than None.

• Users can now set the Accounting System value to None when Business Central is not being used.

• The system now handles blank Business Central fields correctly instead of treating them like an error.

• The system now prevents duplicate Accounting Settings records from being created.

• Related accounting logic was also updated so non-Business Central clients are not blocked by missing values they do not use.

In plain terms: non-BC clients can now set just the fiscal year start month using a “None” accounting settings record without being blocked by unrelated BC fields.

How the solution affects potentially affected users

• Non-Business Central clients can now get correct fiscal-year totals and counts based on their actual fiscal year start month.

• This fix works going forward, but the needed setup must be deployed first before users start creating these records.

What to look out for with this change

• Make sure the required setup changes are in place in every environment before users begin entering Accounting Settings.

• After setup is complete, test that users can choose None for Accounting System and save the record with just the fiscal year start month filled in.

CRA sanction data displayed as numeric code instead of text (15697)

Area Path: akoyaGO, akoyaGO with Accounting

Problem(s)

When staff checked an organization with sanctions, the system sometimes showed an internal code such as 0002 instead of a clear label such as Suspended.

Potentially affected users

• Internal: Staff who review compliance or sanction information.

• External: Organization records viewed by users.

Solution

• The system now saves a readable sanction label whenever one is available.

• It first checks the main sanction list for the best value to display.

• If that list is empty, the system uses the backup sanction text only when it is readable.

• Numeric-only codes are no longer shown as the displayed value.

In plain terms: sanction displays now show meaningful labels instead of internal codes.

How the solution affects potentially affected users

• New and updated records will now show a clear sanction label instead of a numeric code.

• Older records that already saved numeric codes may still need follow-up work, such as running the verification again.

What to look out for with this change

• Review any existing organization records that still show numeric sanction values and plan cleanup if needed.

Fund Total Giving Last Year excluded History payments (10677)

Area Path: akoyaGO with Accounting

Problem(s)

The Fund record did not include some older payments marked as History when showing last year’s total giving. Because of that, the total could look lower than it should.

Potentially affected users

• Internal: Staff who use Fund totals for reporting, review, or decision-making.

• External: No direct impact. This affects internal totals and reporting.

Solution

• The system now includes History payments when calculating these Fund totals:

• Fund Total Giving This Year, Total Giving Last Year, and Total Giving This Fiscal Year. Donor giving totals were not changed.

In plain terms: the system now counts History payments when calculating what the fund received last year.

How the solution affects potentially affected users

• Fund totals will now be more accurate because they include History payments.

• No separate cleanup is expected because the totals are calculated from the current data when viewed.

What to look out for with this change

• If users are used to the old totals, some numbers may now appear higher. Review reports or dashboards where those totals are important.

Auto-create next gift workflow creating two payments after waiting period (15131)

Area Path: akoyaGO with Accounting

Problem(s)

In some cases, the automatic “create next gift” process created two payment records instead of one after the waiting period.

Potentially affected users

• Internal: Staff who use the automatic next-gift feature.

• External: Donors may be indirectly affected if duplicate payment records are created.

Solution

• The workflow was updated so it now creates only one payment in normal cases. It will still create more than one only when that is expected, such as for a split recurring gift.

In plain terms: the next-gift auto generator no longer makes duplicates after the waiting period.

How the solution affects potentially affected users

• This helps prevent duplicate payment records and reduces confusion in reporting and accounting.

• If duplicate payments were created before this fix, staff may still need to review and clean up those older records manually.

What to look out for with this change

• For split recurring gifts, make sure the workflow still creates the correct number of payments.

Gift payment hidden Primary Contact pulled from Payor instead of Donor (15474)

Area Path: akoyaGO with Accounting

Problem(s)

When the donor and payor were different people or organizations, the gift payment record sometimes showed the payor’s Primary Contact instead of the donor’s Primary Contact. This could cause letters and saved views to show the wrong contact information.

Potentially affected users

• Internal: Staff who create letters or use views that show contact details.

• External: Donors or payors could be affected if communications show the wrong contact person.

Solution

• The system now uses the donor’s Primary Contact when filling in the hidden Primary Contact field on gift payments.

In plain terms: letters and views on gift payments now show the contact information belonging to the donor, not the payor.

How the solution affects potentially affected users

• Letters and views should now show the correct donor-related contact information.

• If older gift payment records already saved the wrong contact, they may still need to be reviewed or corrected.

What to look out for with this change

• If the donor is changed after the payment is created, check whether the contact information also updates. That follow-up scenario is not included in this fix.

Cannot adjust individual request payment in Received status without void/recreate (15489)

akoyaGO with Accounting

Problem(s)

Users could not adjust a request payment for an individual once the payment was marked as Received. The adjustment form expected a Payee, but individual payments may not have a payee account, so the adjustment could not be completed.

Potentially affected users

• Internal: Users who correct, reverse, or update payment records.

• External: Individuals whose payment records may need to be corrected.

Solution

• The adjustment process now supports individual payments by using Request Contact when a Payee account is not present.

• The relevant Dataverse fields and the adjustment quick-create form were updated to include Action Contact.

• The web resource logic now fills in and requires the correct contact field only for individual payments, so users see the right field at the right time.

• The plugin logic now copies Action Contact to the adjusted payment so the corrected record keeps the right contact information.

In plain terms: when adjusting an individual payment, the form now uses the correct contact information instead of requiring a Payee account that may not exist. Important field names to recognize are Request Contact, Action Contact, and Payee.

How the solution affects potentially affected users

• Users can now adjust individual payments directly instead of having to void and recreate them.

• If an adjustment failed before this fix, users may be able to retry it successfully now.

What to look out for with this change

• Confirm that organization-based payment adjustments still work the same way and still require a Payee.

• Verify that the adjusted payment saves and keeps the correct Action Contact information.

Donor merge fails when gift payments sent to accounting (15820)

Area Path: akoyaGO with Accounting

Problem(s)

The donor merge tool could fail when one of the donor records had gift payments that were already sent to accounting. In those cases, the system blocked the lookup updates needed to complete the merge.

Potentially affected users

• Internal: Data managers or staff who merge donor records.

• External: Donors whose records are being combined through a merge.

Solution

• A donor merge reparent custom action was added, along with a server-side plugin path that can reparent related gifts and gift payments during the merge.

• The web resource now calls that custom action when a donor merge uses a transfer path.

• The plugin now sets donor-merge reparenting context so accounting-field validation allows protected donor/payor lookup changes only when the update is happening as part of a valid donor merge.

• Additional trace output was added to help with troubleshooting if a merge still fails.

In plain terms: donor merges can now update donor and payor lookups on accounting-protected records when the change is being made through the approved donor merge process.

How the solution affects potentially affected users

• Users should now be able to merge donor records even when related gift payments were already sent to accounting.

• If a donor merge failed before this fix, it may need to be run again.

What to look out for with this change

• After testing, confirm that the donor merge still deactivates the merged record and shows the expected merged banner.

Error saving new payment when not using quick create form (15836)

Area Path: akoyaGO with Accounting

Problem(s)

When users created a payment or requirement from the full form instead of Quick Create, saving could fail with a Business Central message saying the system could not verify whether the payment already existed.

Potentially affected users

• Internal: Users creating payment and requirements records.

Solution

• The system removed a Create-mode guard that was stopping the Business Central existence check from running correctly while the form was loading.

• The logic was also updated so blank/null payment numbers and unsaved records are treated as not existing before any Business Central lookup happens.

• The fix also includes Jest regression coverage to help confirm this scenario keeps working correctly in future updates.

In plain terms: new payments created from the full form should no longer be blocked by a false Business Central verification message. Important technical terms to recognize are Quick Create, full form, Create-mode guard, blank/null payment numbers, and edit mode.

How the solution affects potentially affected users

• Users creating new payments from the full form should now be able to save successfully.

What to look out for with this change

• After deployment, validate that Business Central checks still work correctly for records with real payment numbers and in edit mode, not just during new record creation.

 “History” gift payments on pledges not reducing pledge accrual balance (15859)

Area Path: akoyaGO with Accounting

Problem(s)

Some gift payments tied to a Pledge were not lowering the Pledge Accrual Balance when the payment’s Payment Status was set to History. Because of that, the balance on the related gift payment record could look higher than it should.

Potentially affected users

• Internal: Finance staff and project managers who review or reconcile Pledge Accrual Balance values.

• External: No direct impact. This issue affects system-calculated balances used by internal staff.

Solution

• The calculation query was updated so History folios are now included when the system adds up pledge receipt amounts.

• An admin recalculation task to be run by akoyaGO was also added so previously imported pledge accrual records affected by the old logic can be updated. No action is required on the foundation’s part for these to be fixed. This will deploy alongside the release.

In plain terms: gift payments with Payment Status = History now reduce the Pledge Accrual Balance correctly.

How the solution affects potentially affected users

• Pledge Accrual Balance values should now reflect History payments correctly.

• For older imported records, the admin recalculation (run by akoyaGO) is intended to repair balances that were already affected before this fix.

What to look out for with this change

• Review a few sample records to confirm the Pledge Accrual Balance updated as expected.

Unable to void pledge accrual when no linked payments exist (blank CRM balance) (15690)

Area Path: akoyaGO with Accounting

Problem(s)

Users were unable to void (cancel) a pledge accrual because the system mistakenly thought a payment had already been applied. This issue happened even if the CRM pledge accrual balance was blank/null (meaning nothing was recorded), no payment records were linked in CRM , and Business Central still showed there was an amount left that should have appeared in CRM.

• The CRM pledge accrual balance was blank (it was never filled in before)
• No payment records were linked in CRM
• Business Central still showed a remaining amount that should have matched CRM

Who was affected?

• Internal : CRM users who need to void, adjust, or troubleshoot pledge accrual records.

• External : No direct impact—this mainly affects internal staff and accounting work.

Solution

• The system now includes null/blank guards in client-side validation. This means if the CRM pledge accrual balance is missing, the system treats it as unknown—not as proof that payment(s) were already applied.

• The server-side pledge accrual recalculation has also been improved. Now, the pledge accrual balance will update not just when the payment amount changes, but also when the payment type changes.

• There is also a fix that refreshes any records that currently have a null (blank) balance.

In simple terms: The system will no longer stop you from voiding a pledge accrual just because the CRM pledge accrual balance is blank.

How does this help users?

• Users can now void or adjust pledge accruals correctly when no payments have actually been applied.

• For older records that still have a null-balance, a special recalculation is still needed.

What should you watch for with this change?

• Until the recalculation is run for all records, you may need to use a temporary workaround: open the record and save it with any amount change so the recalculation can update the balance.

Payment fields autofilling on load for already processed History payments (15701)

Area Path: akoyaGO with Accounting

Problem(s)

When you opened a payment record with a payment status of History, the system would sometimes automatically fill in the receivable or payable account fields if they were blank (null). This unexpected autofill caused unsaved changes and triggered errors when you tried to save. It also blocked you from voiding the payment because the form was considered "dirty" (had unsaved changes).

Potentially affected users

• Internal: Users who need to reverse or adjust payments that have already been processed.

Solution

• The system now prevents autofilling account fields for payments that are already processed and have an accounting history or folio attached. This guard stops the form from making unwanted changes automatically.
• Checks have also been added to background jobs so that related server-side defaulting will not try to fill these fields on processed payments.

In plain language: once a payment's status is History, the system will not auto-fill fields later on that could cause errors or block actions like voiding or adjusting.

How the solution affects potentially affected users

• Now, users can open processed payments (payments with History status) without the system making unwanted changes to the form.
• Actions such as voids and adjustments for processed payments are now possible and no longer blocked.
• The fix applies going forward; it does not change previously affected records, but should prevent issues with new actions.

What to look out for with this change

• Make sure that new payments (those not yet processed or sent) still have the receivable and payable account fields filled automatically as expected.

Exclude Scheduled pledge payment from Gift Payments to Send to Accounting system view (15814)

Area Path: akoyaGO with Accounting

Problem(s)

The system view Gift payments to Send to Accounting incorrectly included gift payments with payment type Scheduled pledge payment.

Potentially affected users

• Internal: Users sending gift payments to accounting.

Solution

• Updated view criteria to exclude payment type Scheduled pledge payments.

In plain terms: users won’t accidentally select scheduled pledge payments for accounting sending.

How the solution affects potentially affected users

• Prevents incorrect/early accounting submission for scheduled pledge payments.

• Retroactive action is not described; the change applies to view filtering.

What to look out for with this change

• If clients customized the system view, they may need to manually add an equivalent payment-type filter.

Voiding payment from bank/vendor ledger restored to paid too early (15533)

Area Path: Business Central

Problem(s)

After voiding/unapplying payment from the bank/vendor ledger, CRM payment status briefly updated to Received but later reverted to Paid. Business Central still listed the request payments in Open Payables.

Potentially affected users

• Internal: Finance/bank reconciliation users.

Solution

• Updated application logic to ignore applied vendor ledger entries that have been reversed.

In plain terms: reversed ledger entries no longer cause CRM to flip back to paid after the void.

How the solution affects potentially affected users

• CRM status remains consistent with the actual ledger state (received until repaid).

• Retroactive action: the ticket suggests deleting the additional row for reversed GL entry if needed.

What to look out for with this change

• Review instances where multiple ledger lines exist for the same payment number and ensure the reversed line is handled correctly.

Post and Print in Deposit opens the wrong posted deposit (15469)

Area Path: Business Central

Problem(s)

When users selected Post and Print in Business Central for a new deposit, the system sometimes opened the wrong posted deposit record. Instead of opening the deposit that had just been posted, it opened the first posted deposit it found.

Potentially affected users

• Internal / External (depending on role): Anyone using Business Central deposits and the Post and Print action.

Solution

• This fix is included in Business Central Version 28.1. Once that version is in place, Post and Print should open the correct posted deposit after posting.

How the solution affects potentially affected users

• Users should now be taken to the correct posted deposit record after using Post and Print.

What to look out for with this change

• Before expecting this fix, confirm the environment is running Business Central Version 28.1 or later.

Pledge Payment Accruals under old process have Document No. "PLEDGE" preventing application of new gift payments (15255)

Area Path: Business Central

Problem(s)

Older pledge accrual records were saved using a legacy Document No. value of PLEDGE. The newer gift payment application process expects a newer document-number format such as GPMT-XXXX. Because of that mismatch, the system could not always find the correct accrual record when applying a new gift payment to an older pledge.

In simple terms, the system was looking for the pledge under the new GPMT-XXXX naming pattern, but some older records were still stored under Document No. = PLEDGE. That made the older accrual look like it was missing, even though it was still there.

Potentially affected users

• Internal: Business Central users responsible for posting and clearing customer ledger entries and processing pledge payments to accounting.

• External: CRM users who create new gift payments and attempt to apply them to previously accrued pledges, especially when the pledge accrual originated from the older system.

Solution

The fix updates the older record so the new process can still recognize it. Specifically, when the parent pledge has an open customer ledger entry with Document No. = PLEDGE, the system aligns that entry so the newer pledge-payment application process can match it correctly.

In plain language: if an older pledge was saved using the legacy PLEDGE document number, the system now adjusts that record so the newer workflow can still find it and apply the payment without forcing staff to recreate accounting entries.

• When an open customer ledger entry for the parent pledge has a Document No. of PLEDGE, the release aligns that entry so the new pledge-payment application can successfully match and apply the pledge balance.

How the solution affects potentially affected users

• Users should be able to apply newly created gift payments to legacy-accrued pledges without encountering matching errors.

• Because this is primarily a document-number alignment on open ledger entries, it reduces the need for manual void-and-recreate workarounds.

Previously accrued pledges should work with newly created gift payments without matching errors, reducing the need for manual void-and-recreate workarounds. If payments were attempted and failed during the bug window, manual correction may still be needed in some cases.

What to look out for with this change

• The fix logic is tied to open customer ledger entries; already closed or fully settled items may require separate handling.

• If alignment posting fails, teams may still need to void and recreate the pledge or use a more manual remediation path.

• Accounting teams should still validate ledger outcomes in acceptance testing.

Approve - Requested Scholarship button blocked by inactive Requested Scholarships (15032)

Area Path: GOapply

Problem(s)

When a Request included older inactive Requested Scholarship records with no Awarded Amount, clicking Approve - Requested Scholarship could fail. The system was checking inactive records that should not have counted, which caused the approval to stop even when the active scholarship information was correct.

Potentially affected users

• Internal: Staff who approve a Request using the Approve - Requested Scholarship button.

• External: Applicants may be affected indirectly if approval is delayed, but this fix helps prevent that delay.

Solution

• The approval logic was updated so it now ignores inactive Requested Scholarship records when checking for an Awarded Amount.

• Regression coverage was added for cases with inactive Requested Scholarship records and for the active missing-Awarded Amount approval path.

In plain terms: the approval process now looks only at active Requested Scholarship records when deciding whether the required Awarded Amount is present.

How the solution affects potentially affected users

• Approvals should now go through when the active Requested Scholarship records have the required Awarded Amount.

• Requests that were blocked only because of inactive Requested Scholarship records should be approvable after deployment, without needing cleanup of those inactive rows.

What to look out for with this change

• If a Request has multiple active Requested Scholarship records, make sure each active record has an Awarded Amount when that value is required for approval.

Requested Scholarship stuck waiting after third-party responses completed (supplemental form) (15087)

Area Path: GOapply

Problem(s)

After a user submitted a transcript or recommendation through a supplemental scholarship form, the related Third Party Response record could change to Completed, but the parent Requested Scholarship could still stay in Waiting for third party reply. The confirmation email GOapply - Recommendation/Transcript Updated also might not send.

Potentially affected users

• External: Applicants who rely on timely status updates and confirmation emails.

• Internal: Foundation staff who track application progress and applicant communications.

Solution

• The downstream completion workflow was updated so zero extracted attachments no longer counts as an automatic success.

• When the response JSON is valid, the system now continues processing even if there are no file attachments.

   ◦ marks the Third Party Response and parent Requested Scholarship statuses correctly after processing

   ◦ sends the GOapply - Recommendation/Transcript Updated email

   ◦ moves the Requested Scholarship forward once all required third-party responses are completed

• Regression coverage was added for the no-attachment completion path and other edge cases to help prevent this issue from happening again.

In plain terms: if a third-party responder submits answers that don’t include attachments, the system still completes the workflow, updates the status, and sends the email.

How the solution affects potentially affected users

• Applicants should now receive the missing confirmation email and see the Requested Scholarship move forward correctly when all required third-party responses are complete.

• This also improves status tracking, so other steps that depend on a completed Third Party Response or Requested Scholarship status are more likely to work as expected.

• For older records, this is mainly a fix going forward. The ticket describes workflow changes and regression coverage, but it does not mention an admin backfill. If a record was left in Waiting for third party reply, the Third Party Response may need to be resubmitted, depending on how the status values were saved at the time.

What to look out for with this change

• Test a third-party submission where the response is valid but no files are attached. Confirm that the Third Party Response still completes, the Requested Scholarship status updates, and the GOapply - Recommendation/Transcript Updated email is sent.

• Also confirm that the email template and any email delivery monitoring in the target environment are working, so this fix is visible to users in real use.

GOapply submission confirmation emails sent multiple times during scholarship Submit All (15501)

Area Path: GOapply

Problem(s)

When a user submitted a scholarship using Submit All, the applicant confirmation email could be sent more than once. This happened when the Current Phase Status moved through several temporary statuses very quickly before reaching the final Submitted status.

Potentially affected users

• External: Applicants receiving repeated confirmation emails.

• Internal: Foundation staff monitoring submissions.

Solution

• The logic around Current Phase Status was updated so a scholarship that is still in progress is not briefly rewritten to a more generic in-progress status before the final Submit All process finishes.

• The confirmation workflow also now includes an idempotency or sent-on guard for the final Submitted transition, which helps prevent the same email from being sent more than once.

In plain terms: applicants should now receive the submission confirmation email only once for each completed submission. Important terms to recognize are Submit All, Current Phase Status, Submitted, and idempotency.

How the solution affects potentially affected users

• Applicants should no longer receive duplicate confirmation emails for the same completed scholarship submission.

• This fix mainly prevents the problem going forward. Emails that were already sent in the past cannot be unsent or automatically corrected.

What to look out for with this change

• Test this in a non-production environment to confirm that automatch, Submit All, and the related Current Phase Status changes still preserve the correct scholarship-specific statuses while sending only one confirmation email.

Accented French characters not preserved in webform/PDF (Safari issue) (15066)

Area Path: GOapply

Problem(s)

When some users entered French accented characters in a webform (GOapply UI), those characters did not always appear correctly later in the generated PDF or on the web page. This issue happened in some Safari scenarios.

Potentially affected users

• External: Applicants submitting French content.

• Internal: Reviewers/recipients working with generated PDFs.

Solution

• The system now preserves printable Unicode characters instead of removing accented characters during text sanitization.

• The PDF rendering process now sends content using explicit UTF-8 encoding so accented characters are handled correctly from submission through output.

• Regression coverage was also added to help confirm this behavior continues working in future updates.

In plain terms: French accented characters should now stay correct from the webform (GOapply UI) through storage and into the final PDF.

How the solution affects potentially affected users

• Applicants and reviewers should now see the correct accented characters in both the webform (GOapply UI) and the generated PDF.

• If older records already saved incorrect characters, those records may still need to be regenerated or reprocessed, depending on where the incorrect values were stored.

What to look out for with this change

• Test this in a Safari environment, since that is where the original issue was reported.

• If any tenant already has saved records with incorrect accented characters, plan for possible regeneration or reprocessing of those outputs.

Invite New User button not clickable in out-of-the-box GOapply email template (15286)

Area Path: GOapply

Problem(s)

In the standard GOapply email template, the Invite New User button looked like it should work, but clicking it did nothing. Users could still copy and paste the invite URL manually, but the button itself did not open the link.

Potentially affected users

• External: People receiving GOapply invites.

• Internal: CRM users triggering invites.

Solution

• The email template HTML was updated so the button now uses the correct GOapply invite URL merge field as the clickable link target.

In plain terms: people receiving the email can now click the Invite New User button to open the invite flow directly, instead of copying and pasting the link.

How the solution affects potentially affected users

• This should make GOapply invitations easier to use and reduce support questions caused by the old copy-and-paste workaround.

What to look out for with this change

• Make sure the updated email template is applied in the correct CRM environment and that the merge field syntax for the GOapply invite URL matches what the template engine expects.

Simple Form Builder survey description not shown in Reviewer UI (15316)

Area Path: GOapply

Problem(s)

In some phases built with Simple Form Builder, users could enter a survey description in the form settings, but reviewers never saw that description in the Reviewer UI. The information was saved, but it was not displayed where reviewers expected to see it.

Potentially affected users

• Internal: Reviewers relying on description context.

• Internal: GOmanager form builders.

Solution

• The system no longer allows a root-level survey description in Simple Form Builder when that description would never appear in the Reviewer UI. This helps prevent users from entering content that reviewers cannot see.

In plain terms: Simple Form Builder no longer shows a description setting that reviewers cannot use in the Reviewer UI.

How the solution affects potentially affected users

• This makes the form-building experience clearer and should reduce confusion about missing description text in the Reviewer UI.

What to look out for with this change

• Existing forms that already include a root-level survey description should continue to work as they do today. This change mainly prevents that setting from being used going forward when it would not appear in the Reviewer UI.

Review Groups allow requests with Scholarship In-Progress to be added (15458)

Area Path: GOapply

Problem(s)

Users could add requests to Review Groups even when the related status tracking record still showed Scholarship In-Progress. This meant applications could be sent to reviewers before they were fully ready.

Potentially affected users

• Internal: GOapply admins/review group managers.

• External: Applicants whose incomplete applications could have been added.

Solution

• The code now blocks requests from being added when the related status tracking record is still Scholarship In-Progress.

• The bulk add user experience was not changed as part of this fix.

In plain terms: Review Groups will no longer include scholarship requests that are still marked Scholarship In-Progress and not ready for review.

How the solution affects potentially affected users

• Reviewers should now only receive requests that are ready to be reviewed, instead of seeing items that are still in progress.

• If items were added to a Review Group before this fix, those older items may still need to be removed manually if they were included too soon.

What to look out for with this change

• Users may now see a per-row flow failure message in the model-driven app if they try to add a request that is still Scholarship In-Progress. This is expected and helps stop incomplete records from being added.

Inconsistent file naming in reviewer UI for applicant uploads (15301)

Area Path: GOapply

Problem(s)

Files uploaded by applicants were renamed correctly on the Request Documents tab using the question name. However, when those same files appeared in the reviewer UI, they could still show the applicant’s original filename instead. This made attachment names look inconsistent between the two places.

Potentially affected users

• External: Applicants (indirectly, via attachment naming in reviewer portals).

• Internal: Reviewers and staff.

Solution

• The reviewer attachment display logic now uses the tenant PDF/attachment naming setting when building filenames in the reviewer UI.

• Only the correct attachment sources, such as applicant-upload attachment records, now use question-based renaming. The submitted scholarship PDF keeps its existing filename.

In plain terms: when your system is set to name files by question, reviewers should now see the same filenames in the reviewer UI that staff see on the Request Documents tab.

How the solution affects potentially affected users

• This makes attachment names more consistent for reviewers and staff when they download or compare files.

• This change mainly affects how filenames are shown going forward. It does not automatically rename files that were already displayed in older reviewer views.

What to look out for with this change

• After deployment, confirm that anonymous masking still works correctly along with the updated filename behavior in the reviewer UI.

Duplicate constituent/contact creation when foundation staff approval clicked multiple times (15312)

Area Path: GOapply

Problem(s)

Sometimes, if foundation staff clicked the submitter approval link more than once, the system created duplicate constituent/contact records for the same GOapply applicant.

Potentially affected users

• Internal: Foundation staff approving submissions.

• External: Applicants/organizations affected by duplicated CRM contacts.

Solution

• The approval process now includes idempotency safeguards, which means only one approval action can process at a time for the same GOapply applicant.

• If the applicant is already approved or denied, extra clicks now return an already-processed result instead of creating more constituent/contact records.

• The system also reduces extra follow-up processing after a final status is reached, which helps prevent repeat actions from causing duplicate work.

In plain terms: clicking the approval link more than once should no longer create duplicate constituent/contact records.

How the solution affects potentially affected users

• This helps prevent duplicate CRM records and the data cleanup work that can follow.

• If duplicate records were created before this fix, those older constituent/contact records may still need to be reviewed and cleaned up manually.

What to look out for with this change

• After deployment, confirm that a normal first-time approval still works correctly, even in slower or high-latency conditions.

Advanced Form Builder mapping reliability for choice/boolean when using Radio Group (15682)

Area Path: GOapply

Problem(s)

In some cases, a question built as a Radio Group in Advanced Form Builder did not save correctly when it was mapped to a CRM choice/boolean field. Instead of storing the real option value, the system could save placeholder values like item1 or item2.

Potentially affected users

• Internal: GOmanager form builders.

• External: Applicants whose responses might have been stored incorrectly.

Solution

• The AFB Creator mapping normalization was updated so Radio Group questions now receive the same CRM choice metadata that dropdown questions already use.

• Newly mapped Radio Group questions should now save the real CRM option values instead of placeholder values.

In plain terms: if you map a Radio Group question in advanced form builder to a CRM choice/boolean field, the selected answer should now save correctly.

How the solution affects potentially affected users

• New submissions should now save the correct values for mapped Radio Group questions.

• Existing forms that already saved placeholder values are not corrected automatically. Those forms may need to be resaved, republished, or in some cases submitted again.

What to look out for with this change

• For forms created during the affected period, plan to resave and republish the form so the corrected mapping is used going forward.

Resubmit third party responses didn’t regenerate submitted file (15548)

Area Path: GOapply

Problem(s)

When users ran the resubmit third party response command, the system did not rebuild the submitted file PDF for some GOapply status tracking third-party responses. There was also no clear message in the activity timeline showing that the job had started or failed.

Potentially affected users

• Internal: GOapply staff using the resubmit tool.

• External: Applicants whose third-party response PDFs are shown to reviewers and applicants.

Solution

• The GOmanager resubmit endpoint workflow (codebased) now queues submitted-PDF regeneration before it runs the submission and attachment steps.

• The activity timeline notes now show clearer diagnostics, including when work is skipped or fails.

• Regression coverage was also added to help confirm this job chain continues to work correctly in future updates.

In plain terms: when users resubmit a third-party response, the system should now regenerate the submitted file PDF and update the record correctly.

How the solution affects potentially affected users

• Regenerated PDFs should now reflect the latest third-party response data.

• If a PDF did not regenerate before this fix, running resubmit third party response again after deployment should correct that record.

What to look out for with this change

• After running the resubmit action, confirm that the regenerated submitted file PDF appears and use the updated activity timeline notes to verify whether the job completed, was skipped, or failed.

GOapply reviewer UI showed uploaded PDF attachments rotated (15758)

Area Path: GOapply

Problem(s)

Some uploaded PDF attachments appeared rotated in the GOapply reviewer UI, even though the same file looked correct when downloaded and opened in a standard PDF viewer.

Potentially affected users

• Internal: Reviewers previewing attachments.

• External: Applicants indirectly impacted through reviewer experience.

Solution

• The PDF.js viewport calculation was updated so the viewer now uses the PDF page’s built-in rotation when no separate rotation is provided.

• Regression coverage was also added to help confirm rotated PDF rendering continues to work correctly in future updates.

In plain terms: uploaded PDF files should now appear upright in the reviewer preview.

How the solution affects potentially affected users

• This should make uploaded documents easier for reviewers to read and reduce confusion caused by sideways or upside-down previews.

• This change affects how PDFs are displayed going forward. It does not change files that were already downloaded or printed in the past.

What to look out for with this change

• After deployment, verify that built-in PDF rotation still works correctly anywhere manual viewer rotation is available.

GOapply and reviewer UI didn’t show long-text question descriptions (15488)

Area Path: GOapply

Problem(s)

For some long text (comment) questions built in Simple Form Builder, the question description was saved in the form setup but did not appear in the Reviewer UI. Reviewers could still see the question and answer, but they missed the extra guidance that was supposed to display with it.

Potentially affected users

• External: Applicants whose form definitions drive reviewer content.

• Internal: Reviewers relying on description guidance.

Solution

• The reviewer PDF rendering was updated so the description for answered long text (comment) questions now appears between the question title and the response content.

In plain terms: reviewers will now see the description text that was set up for long text (comment) questions, instead of seeing only the question and answer.

How the solution affects potentially affected users

• This gives reviewers more context and should reduce confusion or misinterpretation when reading longer responses.

• This change mainly affects how content is displayed going forward. It does not automatically change previously generated reviewer outputs.

What to look out for with this change

• Because the description is treated as plain text in this rendering fix, test any content that includes HTML-like formatting to make sure it appears the way you expect.

GOapply Invite New User email not sent when users created via CRM actions (15054)

Area Path: GOapply

Problem(s)

In some cases, when a GOapply user was created through CRM actions such as Add New GOapply User or Bulk Import, the user record was created and auto-approved, but the Invite New User email was not sent.

Potentially affected users

• External: New GOapply users not receiving an invite.

• Internal: CRM operators who expect automatic invite delivery.

Solution

• The CRM user-creation process now saves both akoya_email and the older akoya_applicantemail field so the system has the email information it needs in different scenarios.

• The templated email plugin now reads the GOapply user’s email more directly and sets addressused correctly before sending the message.

• The Bulk Import web resource now shows custom-action failures instead of continuing silently, which makes email-related setup issues easier to catch.

In plain terms: the Invite New User email should now send more reliably when users are created through CRM actions and auto-approval.

How the solution affects potentially affected users

• New users should now receive the Invite New User email and be able to continue GOapply registration without extra manual steps.

• If users were created before this fix and never received the email, staff may still need to resend the invitation manually.

What to look out for with this change

• After deployment, confirm that email delivery works across environments and that the correct recipient address is being used when the message is generated.

Typing commas into Currency preformatted question type works like a decimal point - IN ADVANCED FORM BUILDER ONLY (11747)

Area Path: GOapply

Problem(s)

In Advanced Form Builder, some currency preformatted questions did not handle commas correctly while a user was typing. For example, entering 1,000 or $1,000 could behave as if the comma were part of the decimal instead of a thousands separator.

Example impact:

• While typing, 1,000 could temporarily act like 1.00, making it hard for users to enter the amount they actually wanted.

Potentially affected users

• Internal: Form builders and testers validating the Advanced Form Builder experience.

• External: GOapply users filling out forms built with Advanced Form Builder currency preformatted questions where values include commas, typically amounts of $1,000 or more.

Solution

The main issue was that the Advanced Form Builder currency component was still using an older Inputmask setup (inputMask: "currency") that did not handle commas correctly while users typed.

The fix updates these currency fields to use the newer SurveyJS v2 currency mask structure instead.

• It replaces the older inputMask: "currency" setting with maskType: "currency" and the matching maskSettings.

In plain terms:

• The currency field should now treat commas as thousands separators, so typing 1,000 results in 1,000.00 as expected instead of forcing the user to re-enter the value.

Compatibility note:

• Older saved responses may still reflect the previous format. This update is mainly a fix forward, meaning new entries should save correctly while still staying compatible with older stored formats where possible.

How the solution affects potentially affected users

• Users should now be able to enter comma-based amounts more naturally and reliably.

• This should prevent the frustrating situation where amounts of $1,000 or more seem to get stuck near $1.00 while the user is typing.

• Retroactive correction:

   ◦ This change mainly improves new input behavior going forward. If users previously saved incorrect amounts because of this issue, those older responses may still need review or correction.

What to look out for with this change

• Test to make sure formatting still behaves correctly after the mask update, including decimal precision and trailing zeros.

• Because this update changes how values are masked and saved for compatibility, acceptance testing should still include amounts entered with commas, amounts entered without commas, and confirmation that the final mapped value sent to submission or business logic is correct.

• • entering amounts with commas (e.g., 1,000)
  • entering amounts without commas (e.g., 1000)
  • confirming the mapped value sent to submission/business logic is correct

2.43. Able to edit Read Only Currency fields on GOapply (15717)

Area Path: GOapply

Problem(s)

Some currency fields marked Read-Only in GOapply could still be changed. The input layer (Inputmask) was still accepting keyboard edits even though the question in form builder was set to read-only.

This was most noticeable when a user clicked inside the displayed amount and typed. Even though the field looked read-only, the value could still change.

Potentially affected users

• External: GOapply applicants entering data in forms that include read-only currency amounts.
• Internal: QA teams validating form builder semantics (read-only enforcement).

Solution

The fix now enforces Read-Only behavior at the masked input level by connecting SurveyJS read-only changes to the underlying Inputmask currency field.

Specifically:

• When a currency question is Read-Only, the masked input now respects that setting so keyboard edits no longer change the value.

• The fix was also applied across shared rendering paths so the same behavior works in both application submission and scholarship submission routes.

In plain terms:

• If a form says a currency field is Read-Only, users should no longer be able to change it by clicking into the amount and typing.

How the solution affects potentially affected users

• Users will be less likely to change values by mistake in fields that are meant to stay fixed.

• This improves data accuracy because Read-Only currency values can no longer be edited on the form.

• Retroactive actions:

   ◦ If users changed Read-Only currency values before this fix, those older submitted records may still need manual review. This change does not automatically correct values that were already saved.

What to look out for with this change

• Editable currency fields should continue to work normally. Testing should include both Advanced Form Builder currency fields that use Inputmask and Simple Form Builder scenarios.

• • advanced form builder currency with input mask
  • simple form builder scenarios

• Also confirm that both scholarship submission and application submission flows are using the corrected shared component behavior.

GOapply HTML field going beyond margins in PDF (12164)

Area Path: GOapply

Problem(s)

In some GOapply-generated PDFs, content from a GOapply HTML field could extend past the page margins. This was most likely to happen when the field contained longer or more heavily formatted content.

The main user-visible problem:

• If a GOapply HTML field included long or styled content, the generated PDF could show that content outside the normal page boundaries.

Potentially affected users

• Internal: QA and release validation teams generating PDFs across GOapply and related portals.

• External: GOapply users downloading application PDFs and reviewers using the exported document for evaluation.

Solution

Two related improvements were made to fix this. First, the PDF rendering components across GOapply and GOfund were aligned to the same SurveyJS PDF v2.3.1 rendering setup. Second, the PDF output was adjusted so large HTML content wraps correctly within the page instead of spilling past the margins.

Two aligned changes were delivered:

1.       Version alignment across GOapply/GOfund PDF rendering surfaces to run on the aligned SurveyJS PDF v2.3.1 runtime template stack.

2.       A functional mitigation so that oversized inline HTML content wraps within PDF page margins without requiring a server-side clamp on font sizes.

In plain terms: rich text in a GOapply HTML field should now stay inside the page and wrap more naturally in the generated PDF, instead of running past the margins.

How the solution affects potentially affected users

• Users and reviewers should now see cleaner PDF output, with HTML content staying within the expected page layout.

• Previously generated PDFs will not update automatically.

• If a corrected version is needed for an older file, that PDF will need to be regenerated using the normal supported process.

What to look out for with this change

• Testing for this fix should include both GOapply and GOfund, because the PDF rendering setup was aligned across both products.

• It’s a good idea to test applications that include long HTML content to confirm the layout stays within the page margins.

GOapply recommendations is duplicating responses in submitted PDF (15024)

Area Path: GOapply

Problem(s)

Some long recommendation comments could appear more than once in the submitted PDF, especially when the comment continued onto a new page. A similar fix already existed in another display area, but it had not yet been applied to the server-side PDF templates used for recommendations.

Potentially affected users

• External: GOapply recommenders submitting long recommendation comments.

• Internal: Reviewers and case workers relying on accurate content in PDFs, plus QA verifying PDF generation correctness.

Solution

The server-side SurveyJS PDF templates were updated so long recommendation comments are handled more reliably during PDF generation.

• A rendered-state guard was added so the same comment block is not printed more than once during multi-page PDF creation.

• Comment HTML is now cleaned up more safely to reduce display problems in the final PDF.

• The system now clears temporary rendered content correctly between steps, so each response is added only once per question during PDF generation.

In plain terms: the PDF generator now reliably prints each long comment only once, even when the comment runs across multiple pages.

In plain terms: the PDF generator now reliably prints each long comment only once, even when the comment runs across multiple pages.

How the solution affects potentially affected users

• Recommenders and reviewers should no longer see repeated response text in final PDFs.

• Retroactive actions:

   ◦ PDFs that were already created before this fix will not update automatically. If a corrected version is needed, the submitted PDF will need to be regenerated for those records.

What to look out for with this change

• Because this issue depended on page breaks, testing should include multi-page PDFs and a check that each response appears only once in the final document text.

• • multi-page PDFs
  • verifying the response appears exactly once in extracted/visible PDF text

• Because several related templates were updated, it is still a good idea to test both GOapply and GOfund areas that use similar SurveyJS PDF rendering.

GOapply: Target View on Lookup Field Not Populating for Applicant After Automatch in Supplementary Form (15026)

Area Path: GOapply

Problem(s)

After automatch, some lookup fields in GOapply supplementary forms did not follow the configured Target View. Because of that, applicants could see the wrong list of choices, or miss the filtered options they were supposed to use.

Potentially affected users

• External: GOapply applicants completing supplementary forms after automatch.
• Internal: CRM/portal users and QA validating automatch-driven form behavior.

Solution

The supplementary-form applicant route was missing the logic that loads the correct Target View for a lookup field. That logic already existed in the main application submission page, but it was not running in this supplementary form scenario.

Fix approach:

• The missing lookup-record handler and service connection were added for the applicant supplementary scholarship flow.

• The system now reuses the existing lookup-record service that resolves Target View by view ID or name, so the correct filtered list loads after automatch.

In plain terms: when a form tells GOapply which filtered list to show for a lookup field, the supplementary form now loads the correct list after automatch.

• When the form tells the app which “filtered list” to show (Target View), the supplementary form page now loads and displays that list correctly after automatch.

How the solution affects potentially affected users

• Applicants should now see the correct filtered dropdown options and be able to choose from the list that matches the configured Target View.

• Retroactive actions:

   ◦ If an applicant selected the wrong value before this fix because the Target View did not load correctly, those earlier records may still need review. This update does not automatically correct past selections.

What to look out for with this change

• Testing should stay focused on the supplementary-form route after automatch, since this fix was intentionally limited to that scenario and does not change unrelated external-response pages.

• Regression testing should also include the supplementary scholarship submission page and the normal application submission experience to confirm the correct behavior in both places.

• • the supplementary scholarship submission page
  • the application submission regression baseline

GOapply user created with “none” permissions and missing parent constituent during auto-approved registration (15706)

Area Path: GOapply

Problem(s)

Some organization users in GOapply were auto-approved, but their account was not fully set up correctly. In those cases, the user could end up with None permissions and no linked Parent Constituent record, which made the account active but not usable.

• permissions set to “none”
• missing a properly linked Parent Constituent record

This could happen even when the registration steps seemed to complete normally, including email verification and audit-history updates. The issue was that the auto-approval plugin did not always confirm that the required Parent Constituent record and permission setup had finished successfully before approval was completed.

Potentially affected users

• External: GOapply organization registrants in the affected tenants/regions who experience account access problems.
• Internal: GOapply support teams resolving account activation/permission issues and constituent linkage.

Solution

The auto-approval plugin now checks for a Parent Constituent before it finishes approving the user.

If the Parent Constituent exists, approval continues and the user is activated with the expected default applicant permission, Submitter, instead of None.

• Approval proceeds, and the user is activated with the correct default applicant permissions (described as Submitter rather than None).

If the Parent Constituent is missing, approval stops and the system shows a diagnostic message. This makes the issue visible so it can be fixed, instead of leaving the user active but unable to use the account.

• Approval stops, and the system provides a diagnostic message so the issue is visible for follow-up (rather than silently leaving the user Active but unusable).

In plain terms: before the system fully turns on an organization user account, it now checks that the account is correctly connected to a Parent Constituent and has the right permission setup.

• The system now verifies that the account is properly “connected” to the organization record and assigned correct permissions before it turns the user on.

How the solution affects potentially affected users

• New auto-approved organization users in GOapply should no longer end up active with None permissions and no Parent Constituent.

• Retroactive actions:

   ◦ If users were already affected before this fix, support may still need to create or link the missing Parent Constituent and reset permissions. This update mainly prevents the problem going forward, but older accounts may still need follow-up through the applicant-update process.

What to look out for with this change

• Because approval now depends on whether a Parent Constituent exists, some edge cases may stop at the approval step instead of continuing automatically. This is expected and helps prevent unusable accounts from being activated.

• Support teams should be ready to handle cases where approval stops with a diagnostic message and verify that the related applicant-update process completed successfully.

GOfund Donation Dedication not Mapping First/Last Name (15257)

Area Path: GOfund

Problem(s)

Gifts submitted via GOfund with a dedication (In Honor Of / In Memory Of) did not preserve the entered dedication first/last name onto the final Gift record. The dedication fields ended up blank on Gift record.

Potentially affected users

• External: GOfund donors submitting dedications and notification first/last names.
• Internal: Fund stewardship and communications teams relying on dedication metadata.

Solution

The GOfund donate flow did not pass a schema compatibility flag (NotificationToFirstNameExists) into the shared donation commands. Because this flag defaulted to false, shared commands skipped the writes that populate notification first/last name fields on donation/transaction records, and consequently the gift record was populated with empty values later.

Fix:

• Populate NotificationToFirstNameExists from settings and pass it into:
  • the CreateDonation.Command in the Fund submit step
  • the FlattenDonationsToTransaction.Command in the Checkout step
• Update GOfund UI to gate dedication First/Last inputs behind the same flag, preventing donors from entering values that cannot be persisted for older tenant schemas.

Non-technical explanation:

• Dedication first/last name now saves correctly when the tenant supports those fields, and the form hides those fields when it does not.

How the solution affects potentially affected users

• akoyaGO users will see dedication first/last name preserved on the Gift record.
• Retroactive actions:

   ◦ This fix addresses how data is saved going forward. For older tenants that do not support these fields, the names could not be saved previously. If missing values matter operationally, any cleanup would depend on that tenant’s schema support.

What to look out for with this change

• If your GOdonate site does not allow , the dedication inputs may now be hidden. This is expected and prevents users from entering information the system cannot save.

Anonymous scheduled distributions requests not indicating anonymity (15481)

Area Path: GOfund

Problem(s)

When someone submitted an anonymous scheduled distribution through GOfund and the CRM scheduled distribution workflow ran, the Request Anonymous field was being set to No instead of matching the user’s anonymity choice.

Potentially affected users

• External: Donors requesting anonymity.

• Internal: Fundholders and staff managing request records.

Solution

• The system now populates the anonymous field based on the anonymity setting selected on the Scheduled Distribution.

In plain language: if a scheduled distribution is submitted anonymously, the related request will now also be marked anonymous correctly.

How the solution affects potentially affected users

• Anonymous requests will now stay marked as anonymous the way the donor intended.

• Retroactive action is not described; affected requests may need correction if they were created with the wrong flag.

What to look out for with this change

• It is worth checking that the anonymity setting stays consistent in the scheduled distribution workflow and in any later process that uses the Request Anonymous value.

Charity Search incorrectly shows GOFund‑eligible organization as deactivated / ineligible (15203)

Area Path: GOfund

Problem(s)

In GOfund Charity Search (IRS-based), some organizations were being labeled as deactivated or ineligible when they should have been selectable. The logic treated only the IRS foundation status code PC as active, which meant other valid codes—such as SO—could be shown as unavailable.

Because deactivated results cannot be selected in the search experience, users could be blocked from choosing organizations that were actually eligible.

Potentially affected users

• External: GOfund grant recommenders using Charity Search.
• Internal: Grant recommendation operations teams impacted by increased inability-to-select scenarios.

Solution

The IRS Charity Search eligibility logic was updated so that:

• PC and SO foundation status codes are treated as active/selectable
• other IRS foundation status codes remain deactivated

This change is limited to the Charity Search flow and does not alter the standard CRM organization search behavior.

In plain language:

• Supporting organizations that should be eligible will now appear as selectable in Charity Search.

How the solution affects potentially affected users

• Users can now select eligible supporting organizations returned by IRS Charity Search.

• Retroactive actions:

   ◦ This fix changes selection behavior going forward. If users were unable to choose an eligible organization before this update, they may need to search again and complete the selection now.

What to look out for with this change

• The decision scope is narrow: only Charity Search mapping was changed.
• Regression coverage should include:
  • PC active
  • SO active
  • non-allowlisted IRS codes deactivated
  • CRA/non-IRS path behavior unchanged

GOfund - Grant Recommendation Confirmation Email pulling name of Grant Fund instead of Gift Fund for Interfund Recommendations (15055)

Area Path: GOfund

Problem(s)

For interfund grant recommendations, the confirmation email used the distributing grant fund name (akoya_grantfund) rather than the receiving gift fund name (akoya_giftfund) when populating the organization name in the email.

Potentially affected users

• External: GOfund interfund recommendation recipients who receive the confirmation email.
• Internal: Program administrators tracking confirmation communications.

Solution

The interfund response mapping was corrected so that CreateResponseFromInterfund reads and uses akoya_giftfund for the email organization name.

Non-technical explanation:

• The confirmation email now correctly names the receiving fund, rather than the originating/distributing grant fund.

How the solution affects potentially affected users

• Recipients will now see the correct fund name in confirmation emails.

• Retroactive actions:
  • Previously sent emails would still contain the incorrect name; regeneration is not implied.

What to look out for with this change

• Interfund recommendation flows are specifically addressed; organization and drafts confirmation paths were reviewed as unaffected.
• Validate with at least one interfund recommendation test to ensure the email content aligns with expected fund naming.

Users can click "back" after grant submission (15040)

Area Path: GOfund

Problem(s)

After submitting a grant recommendation, a user could click the browser Back button and return to the previous page state, where a temporary “processing” screen appeared. This made it look like the grant was being submitted again.

Even when no duplicate submission actually happened, the screen was confusing and could make users think they had submitted the grant twice.

Potentially affected users

• External: GOfund grant recommenders submitting organization/interfund/draft recommendations.
• Internal: Support teams dealing with user concern about duplicate submissions.

Solution

After a successful submission, the system now takes users to a final confirmation page and keeps browser history aligned with that page. If the user clicks Back, they should no longer return to the temporary processing state.

Scope included:

• Organization submit
• Interfund submit
• Draft submit flows All converge on the same confirmation page behavior.

Non-technical explanation:

• After a grant is submitted, the confirmation page becomes the safe landing page, so using Back should not show the old “submitting” screen anymore.

How the solution affects potentially affected users

• Users no longer see a misleading “processing again” state when pressing Back.
• Retroactive actions:
  • The fix affects navigation after the updated release; it does not change historical user navigation behavior for past submissions.

What to look out for with this change

• The safe Back behavior must be consistent across all submission routes that land on the shared confirmation page.
• The team should validate browser-specific behavior (e.g., Chrome) and confirm overlay state no longer appears via Back navigation.

Minimum donation amount is not validated when giving via GOfund (1183/15183)

Area Path: GOfund

Problem(s)

The GOfund donation process was not consistently checking tenant-configured minimum and maximum donation amounts on the first donation screen. In some cases, donors could continue even when the amount entered was outside the allowed range—for example, entering $200 when the minimum was $250.

Potentially affected users

• External: GOfund donors attempting to give amounts below the configured minimum or above maximum.
• Internal: Donor support teams handling donation failures or confusion caused by inconsistent validation.

Solution

The fix now checks the allowed donation range at two points:

1.       Fund screen (first screen): server-side validation now checks the amount against the configured minimum and maximum before the donor can continue.

2.       Checkout screen: the amount is checked again before the transaction is created, so invalid amounts cannot slip through later in the process.

Additionally:

• The shared Core GOdonate settings query was also updated so GOfund can read the configured minimum and maximum values and validate correctly.

Non-technical explanation:

• The donation form now stops users from continuing when the amount is outside the allowed range and gives clearer feedback earlier in the process.

How the solution affects potentially affected users

• Donors will get clearer and more consistent feedback when they enter an amount that is too low or too high.

• Retroactive actions:

   ◦ This update improves validation going forward. If any donation records were created with invalid amounts before the fix, the document does not describe an automatic cleanup, so support may need to review them separately.

What to look out for with this change

• UI HTML input attributes previously included a hardcoded minimum; now the server-side validation is authoritative and consistent with configured settings.
• Regression coverage includes:
  • below-minimum
  • above-maximum
  • valid in-range

GOfund daily invitation job timed out after 2 minutes (15527)

Area Path: GOfund

Problem(s)

A daily GOfund invitation check was timing out after about two minutes, which meant some pending connections were not receiving invitation emails.

Potentially affected users

• External: GOfund contacts awaiting invitations.

• Internal: GOfund administrators.

Solution

• The process was moved from synchronous plugin processing to asynchronous background processing using Hangfire fan-out jobs.

• Each connection is now handled separately, so larger batches are less likely to fail because of a timeout.

In plain language: invitations are now sent in the background one connection at a time, so a timeout should no longer stop the whole job before everyone is processed.

How the solution affects potentially affected users

• Pending eligible connections should now receive invitations more reliably.

• Retroactive action: the system processes remaining pending records automatically until caught up.

What to look out for with this change

• Ensure the legacy scheduled trigger/plugin is deactivated to avoid double-processing.

GOfund settings not available to non-accounting clients (15707)

Area Path: GOfund

Problem(s)

Non-accounting clients could not access certain new usability/configuration settings introduced in 4/30/2026 release, including:

• whether the anonymous checkbox appears for grant recommendations

• an optional setting to turn off one-time donation confirmation emails (GOdonate setting)

Potentially affected users

• Internal: Non-accounting users configuring GOfund settings.

Solution

• Updated permissions/availability so non-accounting clients can use those settings too.

In plain terms: more teams can now control these settings without needing the accounting app.

How the solution affects potentially affected users

• More client roles will now have access to the same configuration options.

What to look out for with this change

• Confirm role-based access behaves correctly and no sensitive accounting settings are unintentionally exposed.

GOfund email template: "GOfund - Access to a new fund" contains dynamic text that doesn't pull in dynamic data (15174)

Area Path: GOfund

Problem(s)

A GOfund email template included dynamic text for a “GOfund URL,” but that value was not available from the GOfund contact record. As a result, recipients could receive the email with that part left blank.

Potentially affected users

• External: GOfund users receiving this email.
• Internal: Marketing/communications owners and GOfund administrators relying on correct template personalization.

Solution

The template was updated to remove the broken dynamic GOfund URL placeholder and replace it with a placeholder that clients can fill in themselves.

Non-technical explanation:

• The email template no longer tries to pull in a URL from data that is not available. Instead, it uses a placeholder that each client can update with the correct link.

How the solution affects potentially affected users

• Recipients will no longer see blank URL content in the affected email.
• Retroactive actions:
  • Emails already sent before deployment would have the blank text; no automatic correction is implied for previously delivered messages.

What to look out for with this change

• Clients should ensure the placeholder is replaced with an appropriate hardcoded URL (as described in the workaround/expectation).
• Validate that the updated template aligns with each client’s actual GOfund domain/URL configuration.

Send to Accounting button not working on GOdonate transactions (15282)

Area Path: GOdonate

Problem(s)

When users clicked the Send to Accounting button on a GOdonate transaction from the Gift Payments subgrid, it looked like nothing happened.

Potentially affected users

• Internal: Users responsible for sending gift payments to accounting.

Solution

• Updated the underlying logic so the Send to Accounting action correctly recognizes akoya_godonatetransaction records from the subgrid and processes them as akoya_giftpayment records.

• Also updated the related web resource version.

In plain terms: clicking “Send to Accounting” now correctly finds the selected gift payments and processes them.

How the solution affects potentially affected users

• Users should no longer experience the “nothing happens” behavior.

• No retroactive data fix is described; the fix affects action processing going forward.

What to look out for with this change

• If this same subgrid setup is used on other forms, such as donor forms, it is worth confirming that the same mapping logic works there too.

Duplicate GOdonate gift payments created when “Create Gifts” clicked during background job (15464)

Area Path: GOdonate

Problem(s)

When a GOdonate transaction reached Paid, a background job began creating gift payments. During that time, the Create Gifts button was still available. If someone clicked it again before the job finished, duplicate gift payments could be created.

Potentially affected users

• Internal: GOdonate users processing transactions.

• External: Donors whose transactions could end up with duplicate gift payments.

Solution

• Added protection to prevent the process from running more than once at the same time. After gift creation starts, the transaction moves to a new “Processing” status, and the button is blocked until the background work is finished.

• If the process ends in a final failure, the transaction returns to Paid so it can be retried safely.

• Additional backend safeguards were also added to reduce the chance of duplicate creation.

In plain terms: after gift creation begins, users can’t accidentally start it twice.

How the solution affects potentially affected users

• This helps prevent duplicate gift payments and reduces cleanup work in accounting and reporting.

• If duplicate gift payments were created before this fix was released, they may still need to be cleaned up manually.

What to look out for with this change

• Make sure the CRM “Processing” status value and the Create Gifts button visibility rules are set up correctly in each environment.

• Several fixes affect PDF generation. Expect improved formatting and corrected content rendering for newly generated documents; previously produced PDFs may require regeneration if clients need updated outputs.
• Several fixes improve data compatibility and input correctness. When troubleshooting, ensure that the affected route/surface is correctly identified (GOapply application vs scholarship vs PDF templates; GOfund Fund vs Checkout vs Charity Search).
• Where fixes address previously failed workflows (e.g., pledge accrual document alignment), support teams should be prepared for limited manual remediation in rare cases, guided by the operational notes associated with the original bug.

 

3.1. Cross-cutting impacts to consider

3.1.1. Data fixes that may still be needed

Some fixes only affect new activity going forward. Others may also require updates to older records that were already affected.

• Likely needs cleanup of older records: pledge accrual balances affected by missing History receipts, pledge accrual void/adjust issues caused by blank balances, and some accounting records where older logic produced incorrect results.

• May be fixable through normal use: some records may correct themselves when they are reopened, resubmitted, or recalculated, depending on how the data was originally saved.

3.1.2. Background jobs and duplicate prevention

Several fixes involve work that happens in the background, such as preventing duplicates or completing actions after a short delay.

• Use timeline notes or activity details, when available, to confirm that background tasks finished successfully.

• Some buttons may now be temporarily unavailable while the system is still processing in the background. This is expected and helps prevent duplicate actions.

3.1.3. Portal and PDF display improvements

This release improves how some content appears in portals and PDFs, including:

• comment text and descriptions shown correctly in reviewer screens

• accented characters displaying properly

• PDF attachments appearing in the correct orientation

• long comments showing only once in generated PDFs

To test these updates, walk through a few real examples from start to finish—for example, submit a form, review it, and then download the PDF.

 

•  

Summary

This release makes several everyday tasks easier and faster. It improves how staff create documents, use scheduled workflows, and process requests behind the scenes.

Here are the main improvements users will notice:

• Letter templates are more flexible, so staff can format dates, numbers, and currency more easily and show different content when needed.

• Scheduled distributions now suggest a default title, so users do not have to create one from scratch every time.

• Request save and create actions are faster because the system avoids extra work behind the scenes.

• Related payment updates now happen more efficiently, which helps reduce delays after changes are made.

The release also improves Fee Formula setup in the Community app. These changes make the setup process clearer, help prevent mistakes, and make it easier to copy, manage, and safely update formulas that are already in use.

Internal and Support Watch-Outs

• Some updates now finish in the background after a Request is saved. Because of that, related values (like fund spendable amounts and grantee flags) may take a few seconds to appear.

• Some actions may feel slightly different in timing than before, but they should still work the same way. This is expected because part of the work now happens later in the background.

Letter templates now support richer formatting

Area Path: akoyaGO
Area Path: akoyaGO with Accounting

 

• DevOps Work Item: 10921
• User-friendly title: Merge fields in letter templates now support Word-style formatting and advanced logic
• Corresponding Product Suggestion: ProdSuug#000000000003114

End-user release note: You can now do more with Akoya GO letter templates. Merge fields support richer formatting for values such as dates, numbers, and currency. They can also handle conditional content, hyperlinks, formulas, and images. This makes it easier to create polished letters without as much manual editing.

Supported Word merge-field formatting examples (Request table)

• Basic field: { MERGEFIELD "Request #" }
• Combined text and fields: Request { MERGEFIELD "Request #" }: { MERGEFIELD "Title" }
• Uppercase formatting: { MERGEFIELD "Purpose" \* Upper }
• Lowercase formatting: { MERGEFIELD "Purpose" \* Lower }
• Caps formatting: { MERGEFIELD "Purpose" \* Caps }
• Date formatting: { MERGEFIELD "Decision Date" \@ "MMMM d, yyyy" }
• Numeric formatting: { MERGEFIELD "Grant Amount" \# "#,##0.00" }
• Currency formatting: { MERGEFIELD "Grant Amount" \# "$#,##0.00" }
• Percentage formatting: { MERGEFIELD "Grant Amount" \# "0.00%" }
• IF string equality: { IF "{ MERGEFIELD "Request Status" }" = "Approved" "Approved branch" "Other branch" }
• IF equals: { IF "{ MERGEFIELD "Purpose" }" = "general OPERATING support" "Equal" "Not equal" }
• IF not equals: { IF "{ MERGEFIELD "Purpose" }" <> "special EVENT tickets" "Different" "Same" }
• IF less than: { IF "{ MERGEFIELD "Grant Amount" }" < 1000 "Less" "Not less" }
• IF less than or equal: { IF "{ MERGEFIELD "Decision Date" }" <= "2026-06-30" "On or before" "After" }
• IF greater than: { IF "{ MERGEFIELD "Grant Amount" }" > 1000 "Greater" "Not greater" }
• IF greater than or equal: { IF "{ MERGEFIELD "Grant Amount" }" >= 5000 "Greater or equal" "Less" }
• Nested IF: { IF { MERGEFIELD "Grant Amount" } >= 5000 { IF "{ MERGEFIELD "Request Status" }" = "Approved" "Flagship award" "Large award" } "Standard award" }
• Numeric range with nested IF: { IF { MERGEFIELD "Grant Amount" } >= 10000 "Tier 3" { IF { MERGEFIELD "Grant Amount" } >= 2500 "Tier 2" "Tier 1" } }

HYPERLINK and Formula examples (Contact table)

• Hyperlink using Website field: { HYPERLINK "{ MERGEFIELD Website }" }
• Hyperlink with custom text marker: { HYPERLINK "{ MERGEFIELD Website }" } [[text:Website for contact #{ MERGEFIELD "Contact #" }]]
• Hyperlink built from Contact #: { HYPERLINK "https://example.org/contact/{ MERGEFIELD "Contact #" }/profile" }
• Formula addition: { = { MERGEFIELD "Annual Income" } + 1000 }
• Formula subtraction: { = { MERGEFIELD "Annual Income" } - 2500 }
• Formula multiplication: { = { MERGEFIELD "Annual Income" } * 2 }
• Formula division: { = { MERGEFIELD "Annual Income" } / 2 }

Image merge examples (Fund table)

• GemBox picture merge: { MERGEFIELD "Picture:Public Fund Image" }
• Picture merge with \x: { MERGEFIELD "Picture:Public Fund Image" \x }
• Picture merge with \x \y: { MERGEFIELD "Picture:Public Fund Image" \x \y }
• INCLUDEPICTURE from CRM image field: { INCLUDEPICTURE "{ MERGEFIELD "Public Fund Image" }" \d }
• INCLUDEPICTURE from dynamic URL: { INCLUDEPICTURE "https://placehold.co/600x200/png?text=Fund+{ MERGEFIELD "Fund Code" }" \d }

 

 

What changed / what to watch for

• Letter templates can now show merge fields in more display styles, so finished letters may look more consistent and professional.

• If you already use older templates, review them after deployment to make sure the formatting options display the way you expect.

Scheduled distribution Quick Create now defaults recommended titles

• DevOps Work Item: 15053
• User-friendly title: Scheduled distribution quick create now recommends default titles when blank
• Corresponding Product Suggestion: ProdSuug#000000000005038

Area Path: akoyaGO with Accounting

 

End-user release note: When creating a Scheduled Distribution in Quick Create, the Title field is no longer required before saving. If you leave it blank, the system will add a default title after the record is saved.

• For Grant distributions, the default title uses this pattern: Grant to [Organization] from [Fund].

• For Interfund distributions, the default title uses this pattern: Interfund to [Fund] from [Fund].

This helps users save the record faster without having to decide on a title first.

What changed / what to watch for

• If you leave Title blank in Quick Create, a default title will appear after the record is saved.

• You can still change the Title later if you want to use a different naming style.

Faster request processing by optimizing plugin calls and GOapply behavior

• DevOps Work Item: 15233
• User-friendly title: Optimize request pipeline calls on create/update to reduce unnecessary work

Area Path: akoyaGO
Area Path: akoyaGO with Accounting

End-user release note: Saving or updating a Request should now feel faster. The system now avoids extra background checks unless they are actually needed. It also handles some GOapply requirement updates through the correct workflow path, which reduces unnecessary processing during save.

In simple terms, this update is meant to make everyday Request saves and updates more responsive without changing how the process works for users.

What changed / what to watch for

• The user experience should stay the same, but some steps may happen a little differently behind the scenes because the system now does fewer unnecessary reads and checks.

• If you use GOapply workflows that depend on Request updates, it is still a good idea to test those scenarios after deployment—especially anything related to request payments or status tracking.

Consolidate multiple request-create workflows into plugin code

• DevOps Work Item: 15234
• User-friendly title: Consolidate 6 request-create workflows to reduce pipeline overhead

Area Path: akoyaGO
Area Path: akoyaGO with Accounting

End-user release note

Creating a Request should now be faster and more reliable. The system moved six separate background process workflows into one shared plugin, so the same setup steps still happen but with less overhead during save.

• The system still fills in a default Request title when the right conditions are met.

• Budget FY is still set when a related Budget Line Item is provided.

• Auto-filled school fields are still cleared when they match the applicant and should not remain.

• Payee can still default from the applicant or the applicant’s default payee when Payee is blank.

• Payment anonymity is still set based on the selected fund.

• GO Verify checks for Publication 78 still run when they apply.

What changed / what to watch for

• The visible behavior for users should stay the same, but creating a Request should feel quicker because the system now uses one shared plugin instead of several separate workflows.

• After deployment, it is still a good idea to test your most common Request creation scenarios to confirm the expected defaults and updates still happen.

Workflows being deprecated this release

 

IMPORTANT NOTE: The workflows listed below will now appear in your PowerApps environment with ‘xDeprecated’ appended to the front of the title UNLESS you have made customizations to this workflow. If the following workflows do NOT appear as “xDeprecated [WORKFLOW NAME]” , it’s important you make sure that these workflows are turned off/deactivated after the release. It is also recommended that you re-label the workflow so it is clear that it is no longer part of akoyaGO functionality.

Workflow Name	What It Does
Default a Request Title	If Fund is set, Title is null, not a GOApply record, Request Type is not default, and not Anonymous: concatenates Request Type + " to " + Applicant Name as Title.
Assign Budget FY per selected Budget	If Budget Line Item is populated, reads the associated Budget Line Item's Program Budget's Fiscal Year value and sets it on the request's Budget FY field.
Clear autopopulated high school and college fields	If Applicant equals High School field, clears High School. If Applicant equals College field, clears College.
Copy Applicant to Payee when Grant is Entered	If Payee is null: copies Applicant to Payee, or if Applicant has a Default Payee, copies that instead.
Set Payment anonymity based on fund anonymity	If the related Fund's Anonymity field has a specific option set value (730850000, 730850001, or 730850002), sets the request's Anonymous field to True.
GOVerify - check Publication 78 on create	If not Interfund, checks if Payee has a Tax ID, hasn't been checked in past 5 days, and is not GOverify Exempt. If conditions met, sets akoya_goverifytrigger timestamp on Payee record.

 

Move expensive fund and grantee recalculations to asynchronous execution

• DevOps Work Item: 15235
• User-friendly title: Defer expensive fund spendable and grantee flag recalculations to async processing

Area Path: akoyaGO with Accounting

End-user release note: Saving a Request should now feel faster because two heavier updates no longer run during the main save. The system now updates the fund spendable amount and related grantee flags in the background shortly after the save finishes.

• Fund spendable amount recalculation

• Grantee flag updates on related constituent/contact records

These updates are now processed in the background. Fund spendable amounts and grantee flags still update automatically, but they may appear a few seconds after the Request is saved.

What changed / what to watch for

• If you check right away after saving, you may briefly see the older fund spendable amount or grantee flag values until the background update finishes.

• No extra action is needed. The system should complete these updates automatically a few seconds later.

Speed up payment propagation on Request Post-Save (batch/parallel updates)

• DevOps Work Item: 15236
• User-friendly title: Batch/parallelize payment updates on Request save to eliminate slow N+1 calls

Area Path: akoyaGO
Area Path: akoyaGO with Accounting

End-user release note: When you save a Request after changing the Applicant, Payee, or Primary Contact, related Request Payments now update more efficiently. Instead of processing each payment one at a time, the system handles those updates in a faster way so the overall save experience is smoother.

The Payee confirmation pop-up message still works the same way. If the Payee changes, users will still be asked to confirm before related updates are applied.

What changed / what to watch for

• If a Request has no related Request Payments, the system now skips unnecessary follow-up work.

• The payments grid now refreshes once after all updates finish, instead of refreshing after each individual payment update.

Remove auditing where system-generated totals/logs make audit noise

• DevOps Work Item: 15692
• User-friendly title: Disable auditing for system-generated log/totals tables to reduce audit volume
• Corresponding Product Suggestion: ProdSuug#000000000005271

Area Path: akoyaGO
Area Path: akoyaGO with Accounting

 

End-user release note: This update reduces audit log volume by turning off auditing for some system-generated totals and log tables. The goal is to save audit history space while keeping the most important user-driven audit information where it matters most.

What changed / what to watch for

• You should see fewer audit entries for data the system creates automatically behind the scenes.

• Regular user edits are not the target of this change. This update is focused on system-generated tables and values.

 

Auditing was removed on the following tables:

• GOapply Logs

•  GOverify
 

Auditing was removed on system updated fields (rollups/aggregates) on the following fields on the Donor table:
 

• Total Giving 2 Years Ago

• Total Giving 3 Years Ago

• Total Giving 4 Years Ago

• Total Giving 5 Years Ago

• Total Giving Last Year

• Total Giving Last Year

• Total Giving This Year

• Total Referrals
 

Auditing was removed on system updated fields (rollups/aggregates) on the following fields on the Fund table:

• Total Giving Last Year

• Total Giving This Fiscal Year

• Total Giving This Year

---

 

New akoyaGO purchase invoice system: split by dimension sets before posting

This redesign changes how akoyaGO handles purchase invoices so dimension-based corrections and tax/reporting requirements (such as 1099 scenarios) are posted correctly.

• DevOps Work Item: 15211
• Area Path: Business Central
• Product Suggestion: n/a

End-user release note: 

Purchase invoice posting in akoyaGO now handles invoices more carefully when they include different dimension sets. Before posting, the system can split the invoice into matching sections so Business Central can post each part correctly. This helps with correction scenarios and reporting needs, including some 1099 situations.

 

What changed / watch-outs:

• Invoices with $0.00 lines may still show warnings while they are being processed.

• If an invoice contains multiple dimension sets and splitting is turned off or not allowed, posting will stop. The message will tell the user to open the invoice and post it individually so the split can happen first.

• Batch multi-select posting is still limited for invoices that need splitting in this first release.

• Invoices with mixed dimensions will not continue into the main posting process unless they first go through the split workflow.

---

 

1.1 Clarified confirmation message for adding Pending Requests

When users click +Add Pending Requests for a Review Group, the confirmation message now uses clearer wording that matches what users see in the Requests tab.

Work item

• 15193 
• Area Path: GOapply
• Product Suggestion: 000000000005048

What changed (user-friendly)

• The pop-up confirmation previously said: Success! All Review Group Applications were created.
• It now says: Success! All Pending Requests matching the Opportunity, Phase (and Scholarship if applicable) of this Review Group have been added.

Why it matters

• The old message used an internal term that may not have been familiar to end users.

• The new message makes it clearer that Pending Requests were added based on the selected Opportunity, Phase, and, when applicable, Scholarship.

What to watch for

• After clicking +Add Pending Requests, users should now see a clearer success message.

• This update does not change how the process works. It only improves the wording shown to users.

1.2 Prevented customizations to GOapply Users configuration

To help keep the experience consistent, customization access was removed for the GOapply Users and Add GOapply Users forms and tables. This helps prevent changes that could unintentionally affect how the system works.

Work item

• 15194 
• Area Path: GOapply
• Product Suggestion: 000000000005052

What changed (user-friendly)

• Users and system customizers can no longer make changes to these items:

   ◦ GOapply Users table

   ◦ Add GOapply Users table

   ◦ Certain user setup fields, including:

§  User Permissions

§  Applicant Type

§  Role

• The table setup was also updated so users can no longer:

   ◦ Change the display name

   ◦ Create new forms

   ◦ Modify hierarchical relationships

Why it matters

• This lowers the risk of accidental changes that could make the screens behave differently or cause problems for users.

• It helps keep the GOapply Users experience stable and consistent for everyday use.

What to watch for

• If anyone previously relied on customizing these forms/tables, those changes will no longer be possible.

• Support teams should confirm that any planned tailoring is handled through supported configuration paths rather than table/form customization.

1.3 Updated Submitted system view for status tracking (remove award/status details)

The Submitted system view used for status tracking was updated so applicants no longer see fields they should not have access to, and one helpful field was added.

Work item

• 15317 
• Area Path: GOapply
• Product Suggestion: 000000000005161

What changed (user-friendly)

• Removed from the Submitted view:
  • Request Status
  • Grant Amount
• Added to the Submitted view:
  • Submitter

Why it matters

• Applicants will no longer see internal or sensitive details such as Grant Amount or Request Status, which helps avoid confusion.

• Adding Submitter gives users useful context about who submitted the request without exposing those hidden details.

What to watch for

• If your organization uses Grant Amount or Request Status for internal tracking, those fields can still be added to an internal view if needed.

• The Submitted view should no longer show those two fields to applicants.

 

 

---

 

• DevOps Work Item: 15502 (Limit Featured Fund fields to only show GOdonate enabled funds)
• Area Path: GOdonate
• Corresponding Product Suggestion: 000000000005033

End-user release note: In GOdonate settings, the Featured Fund fields now show only funds that are enabled for GOdonate. This makes it easier to choose the right funds and helps prevent a fund from being selected here but not appearing as featured in the donor portal.

Why this matters:

• Helps prevent confusion when a fund is selected but does not appear in the donation experience.

• Reduces avoidable support questions and follow-up cleanup.

What to watch out for

• If you previously chose a fund that is not GOdonate-enabled as a Featured Fund, it may no longer appear as an option.

• After updating, check that all three Featured Fund selections are set to GOdonate-enabled funds so they display correctly in the portal.

• DevOps Work Item: 15196 (Clarify Gift Purpose Mapping in GOdonate)
• Area Path: GOdonate
• Corresponding Product Suggestion: 000000000004071

End-user release note: When a donor makes a General Unrestricted donation, the Gift record will no longer save the text “General Unrestricted” in the Gift Purpose field. Instead, the Gift Purpose field will be left blank for these gifts.

For Designated Purpose donations, the donor’s entered purpose text will still be saved in the Gift Purpose field exactly as entered.

Why this matters:

• Keeps Gift Purpose data cleaner and more consistent.

• Helps reports and workflows that use the Gift Purpose field avoid unnecessary “General Unrestricted” values.

• Makes it easier to see when a donor entered a specific purpose.

What to watch out for

• On the GOdonate Transaction page, the Purpose dropdown is hidden so users are guided to the correct donor-purpose fields.

• If you use the Gift Purpose field in downstream processes, note that General Unrestricted gifts will now leave that field blank by design.

 

---

 

GOfund Release Notes Summary

These release notes summarize improvements and fixes delivered across the GOfund experience, focusing on donation checkout clarity, grant recommendation usability, Fund Summary flexibility, and performance and navigation consistency for fundholders.

For each change below, you will find:

• The DevOps work item number (with a direct link)
• A user-friendly title
• The Area Path
• The corresponding Product Suggestion identifier (or n/a if not present)
• A clear, end-user release note written for non-technical audiences
• What to watch for (including any practical behavior changes or guidance for support teams)

1.1 Donors can optionally cover the processing fee

• Work Item: 15173
• Area Path: GOfund
• Corresponding Product Suggestion: 000000000005101

End-user release note: Foundations can now allow donors in GOfund to choose whether to cover the processing fee during checkout. If enabled, this can help preserve more of each gift for its intended purpose.

What to watch for: If this feature is enabled, your donation form will display a fee coverage option to donors. If it is not visible, the setting may not be turned on for your site.

1.2 Donor selection is easier when there is only one match

• Work Item: 15192
• Area Path: GOfund
• Corresponding Product Suggestion: 000000000005111

End-user release note: GOfund now automatically selects a donor profile during donation checkout when only one matching donor record exists. This streamlines the donor experience and can reduce unnecessary selection steps.

What to watch for: If donor matching is incomplete, donors may still see prompts or encounter errors during checkout. You may want to confirm donor records are configured as expected.

1.3 Foundations can hide “Add New Donor” during checkout

• Work Item: 15180
• Area Path: GOfund
• Corresponding Product Suggestion: 000000000005108

End-user release note: Foundations can now decide whether the “Add New Donor” option appears during donation checkout. This can make checkout simpler for users who should use an existing donor record instead of creating a new one.

What to watch for: If “Add New Donor” is hidden, checkout will use existing donor or contact information when available. If donor details need to be added or corrected, your foundation team may need to help.

1.4 Optional dedication is available only when enabled

• Work Item: 15666
• Area Path: GOfund
• Corresponding Product Suggestion: n/a

End-user release note: Foundations can now control whether the “Add Dedication” option appears during the gift process in GOfund. This gives your organization more flexibility over the donor checkout experience.

What to watch for: If donors report that they do not see an “Add Dedication” option, check whether the feature is turned on for your foundation.

1.5 Donation Checkout page label can be reworded

• Work Item: 15197
• Area Path: GOfund
• Corresponding Product Suggestion: 000000000005113

End-user release note: Your foundation can now change the wording used for the Donation Checkout page label. This makes it easier to match the language your users are already familiar with.

What to watch for: The page title may look different than before, but the checkout process itself works the same way.

1.6 Donors can choose recurring gift start and end dates in GOfund

• DevOps Work Item: 15171 (Recurring Gift End Dates when making gifts via GOfund)
• Area Path: GOdonate
• Corresponding Product Suggestion: 000000000005092

End-user release note: GOfund checkout now lets donors choose recurring gift start and end dates when creating a recurring gift, and also when editing an existing recurring gift.

Checkout will:

• Show or hide the date fields you need based on the recurring frequency you choose.

• Validate date selections so the gift dates are consistent.

• Use the dates you selected to schedule the recurring gift correctly.

Why this matters:

• It can reduce manual follow-up by foundation staff who previously had to stop recurring gifts themselves.

• It helps foundations better support donor intent by allowing recurring gifts to end as expected.

• It supports common pledge “pay down a pledge” scenarios where a recurring gift should end automatically.

What to watch for

• You may want to confirm the recurring gift start and end date experience works as expected on your site.

• If your foundation uses recurring gift schedules for reporting or reconciliation, confirm the saved end date behaves as expected.

 

2.1 Hide certification text when it does not apply

• Work Item: 15175
• Area Path: GOfund
• Corresponding Product Suggestion: 000000000005103

End-user release note:

A new GOfund setting lets you hide the certification text (and the "I certify" checkbox) on the Interfund Grant Recommendation page when it does not apply to your foundation. When hidden, fundholders can submit interfund recommendations without checking the certification box.

Configuration

• Setting: Interfund Show Certification Text (on the GOfund Settings record).

• Default: Yes — the certification text and checkbox continue to appear, so there is no change for existing tenants.

• To hide it: set the toggle to No. Fundholders will no longer see the certification block on the Interfund Grant Recommendation page, and they can submit without it.

Notes

• The certification text itself (used elsewhere on the Recommend Grant page) is unchanged — this setting only controls whether the block appears on the Interfund flow.

• Saved interfund records still record the certification value as satisfied so reports and downstream processes remain consistent.

What to watch for: If the certification text is hidden, the submission form will be simpler, and you should still be able to complete and submit the recommendation normally.

2.2 Tax ID can be optional when creating a new organization

• Work Item: 15176
• Area Path: GOfund
• Corresponding Product Suggestion: 000000000005104

End-user release note:

Fundholders can now enter a Tax ID when adding a brand-new organization from the Recommend a Grant page. The field is optional — leave it blank if the Tax ID isn't known.

Where it appears

• On the Recommend a Grant page, after clicking Add New Organization, a new Tax ID field appears directly under Organization Name.

What happens when you provide it

• The Tax ID is saved on the new Constituent record that gets created from the recommendation, so it carries forward into CRM without manual re-entry.

• The Tax ID is also captured on the form-submission PDF stored with the request, alongside the rest of the new-organization details.

Notes

• The field is free-form text (max 50 characters); no specific format is enforced. Enter EINs, business numbers, or other tax identifiers in whatever format your foundation prefers.

• When the field is left blank, nothing is written to the new Constituent's Tax ID column — your existing data and defaults are preserved.

• This change applies only to new organizations created during a Grant Recommendation. Selecting an existing organization or using the charity-search flow is unchanged.

 

What to watch for: If you leave the Tax ID blank, your submission should still work normally.

2.3 Foundations can rename the “Recommendation Note” field

• Work Item: 15044
• Area Path: GOfund
• Corresponding Product Suggestion: 000000000005039

End-user release note: Your foundation can now relabel the “Recommendation Note” field on grant recommendation forms. This allows the label to better match your audience and the type of request you are collecting.

What to watch for: The field label and any supporting guidance text may differ by foundation settings, but it does not change how the form is submitted.

2.4 Interfund grant forms can show, hide, and customize more fields

• Work Item: 15045
• Area Path: GOfund
• Corresponding Product Suggestion: 000000000005040

End-user release note: Foundations can now customize Interfund Grant recommendation forms with additional configuration options. They can show or hide key fields, optionally require specific inputs, and change field labels and helper text to better guide users.

What changed

Administrators can now configure Interfund Grant Recommendation fields independently from organization grant recommendations in the Dynamics model-driven app.

The interfund form now supports separate settings for:

• Gift Fund label and helper text

• Amount label and helper text

• Grant Date visibility, label, and helper text

• Purpose of Grant visibility, label, and helper text

• File Upload visibility, required status, label, and helper text

• Recommendation Note visibility, label, and helper text

• Comments visibility, required status, label, and helper text

User impact

This gives administrators more control over how the interfund recommendation form appears and what information users must provide, without changing the organization grant recommendation form.

If Grant Date is hidden, the system will still save the recommendation using today’s date behind the scenes so submission and downstream processing continue to work normally.

What to watch for: Depending on your foundation’s settings, some fields may not appear, some may be required, and helper text may be different than before.

2.5 Separate wording for Organization vs Interfund recommendations and aligned Fund Summary titles

 

• Work Item: 15041

• Area Path: GOfund

• Corresponding Product Suggestion: 000000000005026

End-user release note: GOfund now supports separate page titles, header text, and Fund Summary titles for organization grant recommendations and interfund grant recommendations. This helps users see the right wording and follow the correct workflow more easily.

What to watch for: If your foundation uses custom naming, the titles, headers, and Fund Summary labels may look different depending on whether the recommendation is for an organization or an interfund grant.

2.6 A warning appears when you choose “Submit Now” but drafts exist

• Work Item: 15660
• Area Path: GOfund
• Corresponding Product Suggestion: n/a

End-user release note: If you choose “Submit Now” for a grant recommendation while you already have other unsubmitted draft recommendations, GOfund will now show a pop-up message telling you how many drafts are waiting. You can either continue with “Submit Now” or cancel to review and submit your draft recommendations.

What to watch for: After selecting “Cancel,” the current recommendation will be saved as a draft and the user will be directed to the drafts list.

2.7 Foundations can rename the “Grant Recommendation Drafts” page

• Work Item: 15049
• Area Path: GOfund
• Corresponding Product Suggestion: 000000000005042

End-user release note: Your foundation can now rename the “Grant Recommendation Drafts” page label. The updated name appears at the top of the page and also in the tooltip when users hover over the basket icon.

What to watch for: The page name may be different depending on your foundation’s settings, but the drafts and shopping cart behavior stay the same.3.1.8 Foundations can relabel “Submit Later”

• Work Item: 15050
• Area Path: GOfund
• Corresponding Product Suggestion: 000000000005043

End-user release note: Your foundation can now change the label of the “Submit Later” button on grant recommendations (for example, to “Save for Later”) to match your preferred donor language.

What to watch for: Button text may vary by foundation settings, but the functionality continues to save the recommendation for later.

2.8 Custom helper text for standard grant recommendation fields

• Work Item: 15515
• Area Path: GOfund
• Corresponding Product Suggestion: 000000000005193

End-user release note: Custom descriptions/helper text configured for standard grant recommendation fields (such as Recommendation Notes and Amount) now display in a consistent location—under the field title and above the input area. This improves readability and helps ensure the standard form looks similar to custom recommendation forms.

What to watch for: Users may notice helper text moving slightly on the page, but the form fields and submission steps do not change.

2.9 A submission receipt now appears for batch shopping-cart grant submissions

• Work Item: 15048
• Area Path: GOfund
• Corresponding Product Suggestion: 000000000004914

End-user release note: When multiple grant recommendations are submitted from the shopping basket, GOfund now shows a receipt page with the submitted items and their status. This gives foundations and fundholders clearer confirmation of what was submitted.

• After you submit a batch of grant recommendations from the drafts page, you'll now land on a confirmation screen that shows each recommendation you submitted by name, amount, and status — the screen no longer drops you back to an empty drafts list.

• The confirmation screen updates the status of each recommendation automatically as background processing completes; you don't need to refresh the page.

• A clear note on the screen tells you that you can close the page or come back later — you'll receive a confirmation email when all your recommendations finish processing, and the screen is bookmarkable so you can return to it any time.

• Each status has an information icon with a tooltip explaining what it means (Processing, Submitted, Submitted with delivery delay, Submission failed), so you don't have to consult the email to understand a row's state.

 

What to watch for: The receipt page stays available so users can review what was submitted and see the processing status for each item.

3.1 Fund Summary boxes can be sorted by column

• Work Item: 15178
• Area Path: GOfund
• Corresponding Product Suggestion: 000000000005106

End-user release note: On the Fund Summary page, fundholders can now sort sections such as pending recommendations, recent grants, recent contributions, and scheduled distributions by column. This can make it easier for your users to review information in the order that matters most to them.

Sorting the data in any of the Fund Summary boxes:

• Click any column header on the Fund Summary boxes (Recent Grant Payments, Recent Contributions, Pending Recommendations, All Scheduled Distributions) to sort that column.

• Click once for ascending order; click again to flip to descending.

• Sort works for amounts, dates, status, and text columns.

• Each box sorts independently — sorting one doesn't affect the others.

 

What to watch for: Sorting only affects the section you are viewing. Filters and page navigation work the same as before.

3.2 Foundations can customize Fund Summary section titles and helper text

• Work Item: 15033
• Area Path: GOfund
• Corresponding Product Suggestion: 000000000005032

End-user release note: Your foundation can now define custom titles and helper/subheader text for multiple Fund Summary sections, including Recent Contributions, Scheduled Distributions, Pending Recommendations/Submissions, Recent Grant Payments, and Pending Interfund Grants. This helps users understand exactly what each section represents.

What to watch for: Some section names or helper text may look different from the default wording if your foundation has customized them.

3.3 Pending Interfund recommendations now appear on Fund Summary

• Work Item: 13413
• Area Path: GOfund
• Corresponding Product Suggestion: 000000000004592

End-user release note: Fundholders can now see pending interfund items on the Fund Summary page. Pending Interfund recommendations appear where they should help users understand their upcoming activity, and the UI automatically hides empty sections when there is no data.

What's new

• A new Pending Interfund Recommendations table appears on the Fund Summary page, directly beneath the existing Pending Grant Recommendations table.

• The Pending tile at the top of the Fund Summary now counts pending grant recommendations and pending interfund recommendations together.

• A new Pending Amount tile shows the combined dollar total of all pending recommendations.

Configuration

• The new section appears automatically when interfund recommendations are enabled for the foundation and the fund has at least one pending interfund.

• The section title and optional subheader are customizable per foundation via the Fund Summary Pending Interfund Grants Label and Fund Summary Pending Interfund Grants Subheader settings on the GOfund settings table.

 

What to watch for: If your pending interfund items are awaiting payment status updates, you should now see them reflected in the Fund Summary tiles/cards.

3.4 Top navigation stays consistent when switching funds

• Work Item: 15046
• Area Path: GOfund
• Corresponding Product Suggestion: 000000000005025

End-user release note: The top navigation menu now stays consistent when users switch between funds. Main menu items stay in place, while fund-specific actions still appear in the fund subheader based on your permissions for that fund.

What's Changed:

Cleaner, more predictable navigation in the GOfund donor portal.

• The top navigation menu now stays consistent — the same items (Home, Fund Summary, Documents, Charts, Featured Causes, FAQ) are always visible regardless of which fund you're viewing.
• Fund-specific actions (Donate, Fund Statement, Recommend a Grant, Grant History, Gift History) now appear in a dedicated subheader just below the top nav, and only when you're working within a specific fund.
• A new fund picker is built into the subheader — click the fund name to quickly switch funds without leaving your current page.
• A help (?) icon was added to the top nav for one-click access to Contact Us.
• The Drafts button in the top nav now shows a count of your saved grant recommendations.
• If you have multiple funds and click Fund Summary or Charts in the top nav, you'll see a quick fund picker so you can drill in without having to pick a fund first.
• Documents are now accessed from the main navigation instead of appearing in the fund subheader. This helps keep navigation more consistent.

New 'Hero' tier for Funding Opportunities

• Foundations can now flag a Funding Opportunity as 'Hero' via a new Hero Opportunity toggle on the opportunity record in CRM. Hero opportunities get prominent placement at the top of the Funding Opportunities page and on the home page.
• When one opportunity is flagged Hero, it appears as a large editorial card with image, title, description preview, and a Learn More button.
• When two or more are flagged Hero, they rotate automatically in a carousel with auto-advance, indicators, and prev/next arrows. Carousel respects accessibility preferences for reduced motion.
• Hero is in addition to the existing Featured toggle — if an opportunity is flagged as both Hero and Featured, it shows in the Hero tier only (no duplicate).

On the home page, Hero and Featured opportunities both appear as horizontally-scrollable tile rows that adapt to your screen size, with arrow buttons that appear only when there are more tiles to scroll to.

What to watch for: If you previously noticed menu options disappearing when changing funds, that should no longer happen. Subheader buttons may still vary depending on your permissions for that specific fund.

3.5 Update the GOfund Pending Fund Disbursements system view name

• DevOps Work Item: 15635
• User-friendly title: Update Pending Fund Disbursements system view name to include GOfund
• Area Path: GOfund
• Corresponding Product Suggestion: n/a

End-user release note: The system view name Pending Fund Disbursements now includes GOfund so users can more easily identify which area the view belongs to.

What to watch for: This is a naming update to reduce confusion. It does not change what the view is for.

 

4.1 Faster login by deferring audit logging and analytics

• Work Item: 15237
• Area Path: GOfund
• Corresponding Product Suggestion: n/a

End-user release note: GOfund login performance was improved by moving sign-in audit and analytics processing to the background and avoiding unnecessary settings refreshes during login. As a result, logging in to GOfund should now feel faster for your users because background tasks like audit logging and analytics no longer delay the sign-in process.

What to watch for: Logs and analytics will still be recorded, but some may appear a little later because they now run in the background.

4.2 Login and navigation improvements for mobile accessibility

• Work Item: 8808
• Area Path: GOfund
• Corresponding Product Suggestion: 000000000002680

End-user release note: On mobile screens, the hamburger/navigation icon now automatically adjusts for better contrast against dark navigation backgrounds, improving visibility for fundholders.

What to watch for: If you use a dark navigation theme on mobile, the menu icon should be easier to see.

5.1 Password requirements are listed during reset and onboarding

• Work Item: 15798
• Area Path: GOfund
• Corresponding Product Suggestion: n/a

End-user release note: During password reset and new user onboarding, users now see the password requirements up front. As they type a new password, the requirements are checked so users can confirm they meet the rules before attempting to save.

What to watch for: If a password fails validation, the checklist provides a more direct path to what needs to be corrected.

5.2 Users can reveal passwords using an eye icon

• Work Item: 15800
• Area Path: GOfund
• Corresponding Product Suggestion: n/a

End-user release note: Users can now click an eye icon to reveal the password on both the password reset page and the new user onboarding page. This helps reduce typing errors and improves confidence when entering complex passwords.

What to watch for: Password visibility is temporary and intended for usability during entry.

5.3 Password complexity rules are enforced for GOapply users

• Work Item: 8397
• Area Path: GOfund
• Corresponding Product Suggestion: 000000000002966

End-user release note: GOapply account creation now includes clearer password complexity requirements (such as length and the need for character variety). This supports stronger account security for private foundations and their grantees.

What changed

GOfund now supports password complexity settings at the tenant level instead of using one shared rule set for every portal.

Each foundation can now have its own password requirements for:

• minimum password length

• minimum number of unique characters

• whether a password must include a number

• whether a password must include a lowercase letter

• whether a password must include an uppercase letter

• whether a password must include a special character

These settings are read from the tenant's GOfund configuration and applied automatically when password rules are evaluated. If a tenant does not have one of these settings configured, GOfund falls back to the existing application default for that rule.

Additional password protection

GOfund now also prevents users from choosing a password that matches their username.

For GOfund users, that protection checks both:

• the full email address used to sign in

• the portion of the email before the @

This helps block easy-to-guess passwords such as using the account email itself or a simple variation based on the email username.

What to watch for: Users may need to update their password creation approach to meet the new requirements.

6.1 Faster GOfund page loads by optimizing fund connection lookups

• Work Item: 15538
• Area Path: GOfund
• Corresponding Product Suggestion: n/a

End-user release note: GOfund pages should now load faster for your users because the system uses a more efficient way to check fund access. It also improves how access changes are reflected after a refresh.

What to watch for: After permission changes, users should see updated access more reliably due to the corrected refresh behavior.

7.1 Submission speed improved by deferring non-critical work to background processing

• Work Item: 15232
• Area Path: GOfund
• Corresponding Product Suggestion: n/a

End-user release note: Grant recommendation submissions in GOfund should now complete faster because time-consuming tasks (like generating PDFs, uploading documents, and sending confirmation emails) are handled in the background. This applies to immediate submissions, single draft submissions, and batch submissions.

Faster grant recommendation submissions

• Submitting a grant recommendation now returns to the confirmation page right away. Behind-the-scenes work (creating the request record, attaching your supporting document, generating the recommendation PDF, sending the confirmation email) finishes in the background.

• When you submit multiple recommendations from the drafts page, you'll receive a single summary email once all of them have been processed. The email lists each recommendation's name, amount, and final status:

   ◦ Submitted — created and fully processed.

   ◦ Submitted with delivery delay — the recommendation is on file; a post-submission step (such as document storage) is still completing and the foundation's operations team has been notified.

   ◦ Submission failed — the recommendation could not be created; the draft remains in your shopping cart in an Error state and can be reviewed or resubmitted.

• If something goes wrong while a recommendation is being processed, it's flagged on your drafts page and the foundation's operations team is automatically alerted, so no failure goes unnoticed.

 

What to watch for: After submitting, you may see status updates reflected as processing continues. For batch submissions, a confirmation page provides a clearer picture of submitted items.

8.1 Remove Fund Balance section for private foundations/non-accounting sites

• Work Item: 12947
• Area Path: GOfund
• Corresponding Product Suggestion: 000000000004439

End-user release note: For private foundations and non-accounting GOfund sites, the Fund Balance section no longer appears on the Fund Summary page. Users will instead see the balance information that is most relevant to their site, such as GOfund spendable balance.

What to watch for: If users are expecting to find Fund Balance values, they will not appear on these sites by design.