Views:

 

Last Updated: 1/22/2026

 

RELEASE NOTES: January 22, 2026

 

akoyaGO release notes give all users information about bug fixes, enhancements, and new features in the current release. This document describes all changes as of 1/22/2026. Documentation will be updated or created to reflect these changes. If you have questions, please contact your account manager or akoyaGO Support. Please be aware that you may need to refresh your browser, clear your browser cache, or log out/log back in to see the following changes after the day of the release. 

 

akoyaGO

 

  • Bug Fixes
    • The Approve – Partial button now behaves correctly: Sets the Request Status to Approved, populates the Original Grant Amount, and creates the appropriate Payment record.
    • The Approve – Requested Scholarship action has been fixed. Previously, users saw a generic error when attempting to approve requested scholarships. Now, this command successfully approves the Request and creates the related Payment records, allowing staff to process scholarship awards in bulk more reliably.
    • The prompt to update a spouse’s address when editing a contact has been refined so that it no longer treats “ex-spouse” type connections the same as current spouses and it more carefully respects connection roles and end dates. This avoids accidentally updating addresses for former spouses that were brought in during data migration.
    • The Request Quick Create form now correctly respects a constituent’s Default Payee when creating a Request from the constituent record. This behavior now matches akoyaGO with accounting, ensuring consistency for staff regardless of your accounting integration choice.
  • Enhancements
    • The Source field on Constituent records now indicates how the record was created using the following options to help staff understand where each organization came from and design follow-up processes accordingly:
      • CRM User – entered manually in akoyaGO.
      • GOapply – created from a GOapply application.
      • GOfund – created from a GOfund grant recommendation.
      • GOdonate – created from a GOdonate donation.
    • Similarly, the Source field on Contact records now reflects whether a contact was created:
      • Manually (CRM User)
      • From GOapply
      • From GOdonate
    • The Request Status field in the header of the Request form is now locked for foundation staff. Status changes are controlled by the appropriate buttons and workflows (Approve, Deny, etc.) rather than manual edits, protecting the integrity of your grant lifecycle and reporting.
    • The Attendee Number field is no longer displayed on the general tab of the Event Attendee form (it remains visible only in the header). This reduces clutter and focuses staff on information they actually need to manage event participation.

 

akoyaGO with Accounting 

 

  • Bug Fixes
    • General (effects all workspaces)
      • We have cleaned up the action toolbar on payment records in instances where there were duplicated Send to Accounting buttons. 
      • The prompt to update a spouse’s address when editing a contact has been refined so that it no longer treats “ex-spouse” type connections the same as current spouses and it more carefully respects connection roles and end dates. This avoids accidentally updating addresses for former spouses that were brought in during data migration.
    • Grants Management
      • The Approve – Partial button now behaves correctly: Sets the Request Status to Approved, populates the Original Grant Amount, and creates the appropriate Payment record.
      • The Approve – Requested Scholarship action has been fixed. Previously, users saw a generic error when attempting to approve requested scholarships. Now, this command successfully approves the Request and creates the related Payment records, allowing staff to process scholarship awards in bulk more reliably.
      • On the Payment or Requirement form, the Refunded Amount field no longer excludes inactive records. Only records with an appropriate Payment Status are included in this calculation.
    • Donor Management
      • The Donor # field on the Donor/Prospect form is now read-only. Staff can no longer change it directly, which protects the integrity of donor numbering and ensures that donor numbers remain consistent across reports, correspondence, and external integrations.
      • The Attendee Number field is no longer displayed on the general tab of the Event Attendee form (it remains visible only in the header). This reduces clutter and focuses staff on information they actually need to manage event participation.
      • On the Payment Quick Create form, Request Applicant is now displayed (read-only), Request Contact is displayed (read-only), and Payee appears when Type is Payment and can be modified, but is not required. This gives staff better context while entering payments, reducing lookup time and accidental mistakes.
      • On the Gift Payment form, the Refunded Amount field no longer excludes inactive records. Only records with an appropriate Payment Status are included in this calculation.
  • Enhancements 
    • General (effects all workspaces)
      • The Source field on Constituent records now indicates how the record was created using the following options to help staff understand where each organization came from and design follow-up processes accordingly:
        • CRM User – entered manually in akoyaGO.
        • GOapply – created from a GOapply registration.
        • GOfund – created from a GOfund grant recommendation.
        • GOdonate – created from a GOdonate donation.
      • Similarly, the Source field on Contact records now reflects whether a contact was created:
        • Manually (CRM User)
        • From GOapply
        • From GOdonate
      • GOverify no longer runs on Interfund Requests or Payments. This prevents unnecessary review steps and confusion when processing fund-to-fund transactions inside your foundation. Your existing Interfund workflows and approvals continue to function as before—just without the extra GOverify step.
      • The system views behind the Payment Processing Dashboard now include only active records that are actually waiting to be sent to accounting or to be reviewed. This keeps your dashboard focused on payments that still require action and reduces clutter from historical or inactive records.
    • Grants Management
      • A new Quick Create form for Interfund Grants allows staff to create fund-to-fund grants much more quickly while still respecting your accounting setup.
      • When staff do not provide a Grant Title on an Interfund Grant, the system now fills it in automatically on save. If Grantee is filled: Grant to [Grantee]. If Grantee is blank: Grant to [Gift Fund Formal Fund Name]. This ensures every Interfund record has a helpful, readable title for searching, reporting, and correspondence.
      • On Interfund Grants, when you save a record where Payor is populated but Donor is blank, Donor is now auto-filled to match the Payor. This aligns Donor and Payor for internal fund transfers when appropriate, saving staff time and maintaining consistent donor information.
      • The Request Status field in the header of the Request form is now locked for foundation staff. Status changes are controlled by the appropriate buttons and workflows (Approve, Deny, etc.) rather than manual edits, protecting the integrity of your grant lifecycle and reporting.
    • Donor Management 
      • The Payment Type field on the Gift main form has been hidden and is no longer required during data entry. Payment Type is still managed appropriately at the Payment record level. This change prevents confusing error messages on gift save and simplifies the process, especially for new implementations where Payment Type was already being set during payment creation or through GOdonate imports.
      • On the Gift Quick Create form, fields formerly labeled Memorial Contact and Memorial Note Sent are now correctly labeled as Notification Contact and Notification Note Sent, respectively. These changes bring the quick create form in line with the main Gift form and better reflect all types of notification contacts (not only memorials).
      • New and refined system views help staff manage pledges and acknowledgments more effectively:
        • Active Pledges with Outstanding Balance – shows gifts where Type = Pledge, Status = Active, and Balance > 0.
        • Pledges – a view listing all gifts where Gift Type = Pledge.
        • Gifts to be Acknowledged – now includes the Informal Greeting column, helping staff process acknowledgements with donor-preferred salutations.
        • Pledges to be Acknowledged – updated to fit these new pledge-oriented views, giving a clearer picture of outstanding pledge-related thank-yous.
    • Fund Management
      • You can now capture additional custom data on Scheduled Distributions and have that information automatically carry over to generated Grant Requests and Interfund Grants. A new, configurable workflow lets your team define which extra fields you want to store (for example: program area tags, internal notes, or special handling instructions). Once configured, those values appear automatically on the resulting grant records, reducing manual entry and keeping important context in one place.
      • The Gifts Pending field on Fund records has been updated to better reflect its behavior:
        • The tooltip now explains that it sums Net Amount from active gift payments where Payment Status is blank.
        • The underlying calculation has been updated to match this description.

 

Business Central

 

  • Bug Fixes
    • The akoyaGO Disbursement Journal report, which previously mixed deposits and payments and showed incorrect statuses, has been deprecated. With the corrected reversal/adjustment process now in place, this extra report is no longer needed. Foundations should rely on standard payment journal and bank reports, using explicit payment types like Manual check, Computer check, or Electronic transfer for clean posting and reconciliation.
    • When posting payments and deposits more than a year in the past, there is now a path to ensure that Payment Status in CRM is updated (from Received to Deposited/Paid), even when the standard one-year window would previously block updates. This addresses cases where clients are catching up on older transactions and need CRM to reflect that historic activity correctly.
    • Adjustments now validate against the posting date on the adjustment record itself, not the original payment’s date. As long as the adjustment’s posting date is within the allowed date range in Business Central, the adjustment posts successfully—even if the original payment date is older. This supports correct corrections across fiscal periods without requiring staff to manipulate posting windows unnecessarily.
    • The Autobalance process now respects the maximum (most recent) of the Allow Reapportion From date in akoyaGO CRM Accounting Settings and Allow Posting From date in Business Central General Ledger Set Up. This ensures no historical apportioning or autobalance adjustments are posted to dates that fall outside your allowed financial period, aligning CRM and BC rules and preventing inadvertent back-dating.
    • Merging vendors that both have 1099 Form Boxes set up could previously pass initial validation but fail mid-merge due to the IRS forms app, leaving users with an unhelpful “resolve 1 conflict” message. The merge routines have been updated so that the IRS forms data is validated and updated as part of the vendor merge and users receive clearer error handling when a conflict prevents merge.
    • Staff can now use the out-of-box Business Central merge functions without being blocked by hidden coupling review permissions. This reduces reliance on special roles or workarounds just to merge vendor records.
    • The Approvals → Workflow User Groups menu in Business Central now opens the correct list page instead of a document card page. This makes it easy to see all workflow user groups at once and manage approvals configuration without confusion.

 

GOapply

 

  • Bug Fixes
    • When GOapply cannot convert a particular file into PDF during application consolidation, the system now logs clearer details on the application’s timeline, including the question name where the problematic file was uploaded and the file name that failed. This helps staff quickly identify the exact attachment causing issues so they can contact the applicant or adjust the file as needed.
    • When third-party request emails fail to send (for example, due to missing “send on behalf” permissions), GOapply now:
      • Sets the Regarding field on the third-party email so it’s easier to find.
      • Uses the Internal Phase Contact when configured.
      • Writes a clear error message on the Status Tracking record’s internal tab and timeline. Staff can now see not just that something went wrong, but what went wrong and which record needs attention.
    • When staff add new GOapply Users, the system now correctly handles users who may already exist:
      • If the user exists in the central Identity service but not in your tenant’s GOapply Users table, the “GOapply – User Already Exists” email is sent, guiding them to log in.
      • If the user already exists both in Identity and in your tenant, the system shows a clear “User already exists” error instead of silently failing. This prevents users from getting stuck without an email and gives staff clear feedback about why a new invite cannot be sent.
    • When users created through the GOapply Bulk Import Users tool click their password setup link, they previously saw a confusing placeholder called OnboardNewUserEmailHelpBlock under their email address. This text has been removed or replaced with friendly language so that invitees see a clean, professional message instead of internal system labels.
    • When staff use Diagnostics → Resend Email Verification for a GOapply user, the system now:
      • Generates a fresh verification link with a new expiration date.
      • Ensures that clicking “Verify my account” works without an invalid token error. This helps staff cleanly recover cases where earlier verification attempts expired or never reached the applicant.
    • GOapply Email Messages “Regarding” the Right Records:
      • GOapply verification emails are now automatically linked to (set “Regarding”) the GOapply User record, so you can see them in that user’s timeline.
      • GOapply password reset emails are also set regarding the GOapply User record, improving audit trails when troubleshooting login issues.
      • Third-party request emails (recommendations, transcripts) are now set to an appropriate related record (Status Tracking or GOapply User), so it is much easier to trace communications when something fails or a recommender has trouble.
    • Previously, trying to impersonate a GOapply user without a first or last name caused a 500 server error. The system now prevents that situation by either:
      • Requiring the First and Last Name fields, or
      • Handling missing names gracefully so impersonation succeeds. This protects staff from confusing technical errors when assisting applicants.
    • The “First page is a start page” navigation option in Simple Form Builder caused pages to freeze and navigation buttons to misbehave. This setting has been removed so staff cannot accidentally configure forms into a broken state. Existing and new forms will now behave more predictably when applicants move between pages.
    • Simple Form Builder has been optimized to prevent long pauses at 45% loading and missing pre-mapped panels that previously required browser cache clearing to appear. Staff should experience faster, more consistent loading of pre-mapped panels such as Recommendation and Transcript, without needing technical workarounds.
    • When converting from Simple Form Builder to Advanced Form Builder, any Rich Text Editor questions were previously removed entirely. The updated behavior ensures that rich text questions are either preserved (for example, converted to Comment-style questions), or staff receive a clear warning if certain question types cannot be migrated. This prevents accidental data loss and helps staff make informed choices when upgrading forms. 
    • When akoyaGO multi-line text fields are mapped into panels in Simple Form Builder, they now appear in GOapply as proper multi-line comment boxes, instead of single-line fields. This makes it easier for applicants to provide detailed descriptions without being constrained by one-line inputs.
    • Third-party recipients of transcript request emails now see the correct response form when they click their email link, instead of a blank page. This ensures school staff and other third parties can submit transcripts smoothly without additional support from your team.
    • On the third-party request status screen clicking “Go back” now truly just navigates back without sending any emails and only the “Update request” action sends an email notification. This prevents confusing duplicate messages when third parties are simply reviewing information.
    • If there is an error in the eligibility criteria setup for Scholarship Automatching, students no longer remain on a misleading “automatching” page that appears to work but does not. They will now see an appropriate on-screen error message indicating that something went wrong. This prompts them (and staff) to know that a technical issue, not their own input, is blocking matches.
    • The Scholarship Automatch action button on Request can now run successfully even when a Request is in “Awaiting Third Party Reply” status, as long as a valid Status Tracking record exists. The system now recognizes the existing Status Tracking, performs eligibility matching, and creates requested scholarship records as expected. Staff will no longer see the misleading “No related Status Tracking record is found” message in these cases. 
    • If an Automatch submission fails (for example, due to background job issues), GOapply now logs an Error status with clear messages on the Status Tracking record, writes detail to both the timeline and the internal tab, and may attempt a retry where appropriate. This gives staff a clear trail to investigate when scholarship matching fails ‘silently’.
    • The “Scholarship in Progress” view in Status Tracking only appears once now. Duplicate views with identical filters have been removed, simplifying navigation for staff.
    • GOapply Reviewer bug fixes
      • In rare cases, a specific application’s PDF did not load for a reviewer even though the application was correctly assigned to the Review Group. This issue has been corrected so that if an application appears in a review group list, its full PDF is reliably accessible when opened by reviewers.
  • Enhancements
    • Users now have cleaner form options for GOapply setup:
      • Phase forms: “Phase” and “Phase – New”
      • GOapply Opportunity forms: “Opportunity Information” and “Opportunity – New”
      • Creating a new Phase from an Opportunity now uses a Quick Create form, making setup faster while keeping key data organized under intuitive tabs.
    • Staff can now set default answers for most question types in Simple Form Builder, across GOapply Phase forms, Scholarship-specific forms, Grant recommendation / Interfund recommendation forms, Transcript and recommendation forms. Setting a default value means applicants see a pre-filled answer that they can keep or change and for mapped questions, the default answer is saved directly onto the underlying Request or related record. This is useful for common responses, standard terms, or pre-agreed options you want to present to applicants by default.
    • You can now include all three types of matrix-style questions (unmapped) in Simple Form Builder. These grid-style questions allow you to collect ratings or answers across multiple items and columns in one table and keep complex evaluations or checklists visually compact for applicants. These matrix questions are for narrative and rating capture only; they are not mapped to specific CRM fields.
    • When Automatic Opt In is turned on in GOapply Settings, the applicant-facing language no longer prompts students to manually “opt in” to scholarships. Instead, it reflects that they will be included automatically, removing confusion and unnecessary steps.
    • An unused message icon in the GOapply header that led to a non-functional page has been removed. This avoids confusion for applicants who previously clicked the icon and reached a dead end.
    • Pre-built email fields in GOapply (especially in transcript request panels) now allow email domains with more than three periods (for example, @mail.dps.k12.va.us). This ensures that applicants and third parties with complex school or government domain names can enter their email addresses accurately.
    • Scholarship-Specific Third-Party Forms
      • Radio Group Options Usability: On scholarship-specific third-party response forms, staff can now add and remove choices for unmapped radio group questions. Previously, the plus and delete controls were missing, which made customizing answer options impossible.
      • Multi-Line Text (Comment) Question Types: Scholarship-specific third-party response forms now include appropriate multi-line (comment) question types so references and recommenders can provide narrative answers, not just short text. These are especially important for recommendation letters and transcript-related notes. 
    • GOapply Reviewer Enhancements
      • To protect review data review Groups that have Reviewers, Review Group Applications, or Review Responses can no longer be deleted. If staff attempt to delete such a group, a pop-up explains why and prevents deletion. This aligns Review Group behavior with other protected records like Requests, and helps avoid accidental loss of review history.
      • The GOapply Review Responses by Reviewer report has been adjusted so that it enables staff to focus on responses per individual reviewer, rather than duplicating the existing group-level and request-level reports. If run from a reviewer record (or with filters), it surfaces responses tied to that person. This makes it easier to analyze reviewer workloads and scoring patterns without manually filtering large data sets.

 

GOfund

 

  • Bug Fixes
    • If your organization customizes the labels used for organizations and established funds in GOfund Settings, these labels are now carried through to the buttons on the Grant Recommendation submission screen. This update ensures donors see consistent, familiar terminology from start to finish as they recommend grants, reducing confusion.
    • The Recent Organizations list in the GOfund “Recommend a Grant” flow was displaying an alphabetical list of all eligible organizations rather than true recent selections. To match its actual behavior, this area is now labeled Eligible Organizations. Donors will see a clear list of organizations they can recommend grants to, without expecting personalized “recent” history.
    • When recommending a grant to an established fund, donors now see all eligible Interfund funds in the Gift Fund dropdown, not just a partial list. This ensures that every fund included in the “GOfund Interfund Funds” view in akoyaGO is available for donor selection, even if your organization has many internal funds.
    • The tooltip for the GOfund Available to Grant field on fund records has been updated so that its description matches the actual calculation used. 
    • When a donor submits an Interfund Grant Recommendation and it succeeds, only one Interfund record is created and any staff notifications reflect that single success. If an error occurs, the system avoids creating multiple Interfund records behind the scenes and provides clearer messaging instead of quietly creating several duplicate grants. This prevents donors from accidentally submitting the same internal grant multiple times when they see an unclear error on screen.
  • Enhancements
    • When donors create a new Organization while recommending a grant, GOfund now supports longer organization names—up to 160 characters. This matches the length of the Applicant field in akoyaGO Requests and prevents errors when working with organizations that have long legal names.

 

GOdonate

 

  • Bug Fixes
    • A bug where donors navigating backward through GOdonate after checkout could cause Status Reason and Payment Status to revert or Gift amounts to be cleared has been addressed. Once a transaction successfully reaches paid/succeeded, its payment information no longer reverts to an earlier state. This reduces the risk of mismatched donor receipts and missing payment data.
    • Previously, attempting to deactivate GOdonate transactions with a payment status of requires_payment_method caused a cryptic error about invalid state codes. This has been corrected so staff can properly deactivate abandoned or incomplete transactions without technical failures.
    • We have refactored the process that creates gifts/gift payments upon completion of a GOdonate Transaction. This reduces the chance of “paid but not completed” donations and makes them easier to recover if they do occur.
  • Enhancements
    • Donors can now turn Add Dedication (In Memory/In Honor) on, enter dedication details, and later change their mind and turn it off, fully clearing the dedication information. This makes it straightforward for donors to correct mistakes before finalizing their gifts.
    • GOdonate password reset emails are now automatically set regarding the Contact record in akoyaGO. Staff can pen the Contact record, review the timeline, and see when password reset emails were sent. This improves your ability to troubleshoot access issues with donors.
    • The Status Reason field on GOdonate Transactions is now read-only for foundation staff. It is updated only by system processes, which prevents manual overrides like incorrectly marking a transaction as Completed and ensures that reporting and reconciliation agree with the true payment state.
 
Keywords: Release Notes, Product Update, January 2026