U.S. = 1 July, Tuesday Evening | Canada = 1 July, Tuesday Evening
| Australia = 2 July, Wednesday Morning

 

Enhancements

View Content Page from Ambassador Challenge Admin Controls

Administrators can now access the Ambassador content landing page directly from the admin controls. Previously, an admin had to know the location of the content landing page to access it. This update streamlines access to the page and enables easier review and editing of content. It improves visibility and control, helping admins manage Ambassador content more efficiently.

Set Custom Sort Order for Ambassador Challenges and Initiatives

Administrators can now set a custom sort order when adding initiatives and challenges to scoreboards to determine the order in which they are displayed on the site.

Web Services Rate Limiting Enforcement – 50 Calls per Minute

To help protect stability and ensure fair access to data, we are implementing rate limiting for Encompass Web Services and API usage. Clients will now be limited to 50 API calls per minute. If this threshold is exceeded, a standard HTTP 429 – Too Many Requests error will be returned. If you are not utilizing the Encompass API there is nothing that you need to change.

This is a standard practice across APIs and helps ensure that system resources remain available and performant for all institutions. If you have questions about how to handle the 429 response you can reference this page. If you have questions with adjustments of testing your integration, please contact your Client Success Manager or Encompass Support. We will be able to work with you to help as smooth of a transition as possible.

Accessibility Improvements

Form controls are elements on a form users use to enter information or make selections. Some common examples are buttons, checkboxes, and text fields. As part of our ongoing efforts to improve accessibility and meet WCAG standards, we made targeted improvements to specific form controls.

Form control used a <label> element which was hidden from assistive technologies

Issue: The "Attendee list" form control used a <label> element which was hidden from assistive technologies. As a result, the form control did not have an accessible name, and the purpose of the control was not conveyed to assistive technology users.

Resolution: The form label is no longer hidden and the accessible name matches the visible label text.

Accessible name did not contain the visible text

Issue: The visible label for the form control is "Donation amount" and "$" but the accessible name for the control was "Enter currency amount." This made it difficult for assistive technologies users to identify and operate the controls.

Resolution: The accessible name for the control now contains the visible text.

Noninteractive element was receiving keyboard focus

Issue: A noninteractive table created when you searched the Attendee List was receiving keyboard focus.

Resolution: The table was removed from the tab order and no longer receives keyboard focus.

Button focus order was not logical for the user view of Advanced Designations display on a form

Issue: When a keyboard user selected Save Selection or Close on an Advanced Designations display on a form, the focus was lost and moved to the body of the page.

Resolution: When a keyboard user now selects Save Selection or Close, the focus moves back to the Advanced Designations control, which is the logical location. 

 

Status messages that are apparent to sighted users should be announced to those who are using screen readers. As part of our ongoing efforts to improve accessibility and meet WCAG standards, we made a targeted improvement to a status message.

Visible status change was apparent to sighted users but not to those using a screen reader

Issue: When you submitted a search term for the Attendee List, a loading icon appeared. The loading status was not announced by screen readers.

Resolution: Screen readers will now announce a status change when content is dynamically added to the table.

 

If a user submits a form with an error in only one field, all the data should remain in the form, and the focus should move the field with the error. There should be an error message in plain text associated with the field in error. The message should describe the error and make any appropriate suggestions for how to fix it. As part of our ongoing efforts to improve accessibility and meet WCAG standards, we made a targeted improvement to a specific input error.

Input error on a form was not identified and described in text to the user

Issue: When a user made an error entering data in the Email address to notify/remind field on a form, that error was not identified and described to the user in text.

Resolution: Now, if a user makes an error entering data in the Email address to notify/remind field, focus moves to that field, and they are notified of the error in text.

Resolutions

Functional Area	Reference	Description
Events	2396975	Previously, an event with a limit could throw a limit error when the limit was reached by multiple users filling out the form at the same time. In this case, no confirmation email was sent; however, billing and registration still went through. Constituents did not realize they were registered. We updated the logic to correctly handle concurrent submissions and now valid submissions are accepted up to the true limit. Registrants receive the correct confirmation experience and confirmation emails are sent appropriately.
Giving	2507388	When a user partially completed submissions on a form for a donations campaign that used Giving Levels, it caused core admin dropdown menus to become unresponsive. We updated  the form-handling logic to safely handle and ignore incomplete level data. Admin menus now function as expected regardless of the submission state of the form.
Email Reporting	2459482	Some constituents were not always appearing when searched in the "All Recipients" view in the email reporting interface, even though they had received and opened emails as verified through the Email History and Individual Email Reports. The query logic used by the "All Recipients" page was corrected to ensure that all valid recipient record are now returned in search results to ensure full traceability and confidence when auditing email outreach.
Email Reporting	2203377	Previously, comments entered in the "Send Preview" modal were not included in a preview email if it was sent form the Email Reporting page. Now, all comments entered in the "Send Preview" modal are retained and included in the outgoing preview email regardless of preview entry point.
Email Marketing	2359070	Some emails were being marked as "Failed to Send" with a null error reason in the admin interface; however, they had been partially sent successfully. This created confusion and raised concerns about duplications when attempting to resend the email. Now: A "Partial Send" notification is displayed if an email sends to a portion of the list before a disruption occurs The dashboard displays a "-" instead of an incorrect "0" if the number of emails sent cannot be confidently calculated Email reporting continues to reflect actual recipients and delivery metrics for transparency
Email Reporting	2566512	Previously, recipient details failed to load beyond the first page in the Email Reporting interface when accessed by going to the hamburger menu and choosing Recipients. The first page displayed data correctly, but subsequent pages displayed blank tables. The issue was resolved and recipient data now loads dynamically and reliably across all pages.
Email Marketing	2520976	We fixed an issue where the Body Font Family and Button Text Color were not being inherited from the Dynamic Content Stylesheet in email loop elements.
Email Marketing	2257002	We patched some cross site scripting vulnerabilities in the email marketing area.