--- title: "CostGuard Version 20.8 Details" slug: "costguard-version-20-8-details" updated: 2026-05-09T18:15:12Z published: 2026-05-19T16:54:26Z canonical: "help.idibilling.com/costguard-version-20-8-details" --- > ## Documentation Index > Fetch the complete documentation index at: https://help.idibilling.com/llms.txt > Use this file to discover all available pages before exploring further. # CostGuard Version 20.8 Details #### [CostGuard Version 20.8 Core Bulletin](https://cdn.us.document360.io/3f7f8ade-bcb1-4ec8-af25-0c0ad8601afb/Images/Documentation/CostGuard-20.8-Core-Release-Bulletin(1).pdf?sv=2026-02-06&spr=https&st=2026-11-14T11%3A15%3A47Z&se=2026-11-14T12%3A15%3A47Z&sr=c&sp=r&sig=CPqrFBWvdgkZDEpMtko%2FGVSFquwgRWAxkBvMZM4W%2F4Y%3D) #### Change Orders | **Functional Area** | **AR/FR** | **Description** | | --- | --- | --- | | Customer Care | FR 3005 | **Viewing retail history on an account** – The Orders link on the customer main menu previously took you directly to the Order History view. Now this link functions as a drop down menu with two options: - **Order History** takes you to the original Orders view. - **Retail History** takes you to a view listing all completed Retail Transactions for the account. On this view each retail transaction can be expanded to show the line items within. Selecting a transaction presents the details on the right-hand side. The **View** drop down menu in the details panel has three options for viewing the following details: Summary, Tax Details, Starting Codes. | | Orders | FR 3277 | **Override unit pricing on direct invoicing and retail products** – Similar to existing functionality for overriding the unit price of a billing product when you add the product to an order, you can now change the default unit price of any direct invoice or retail product as defined in the Product Catalog. > [!NOTE] > **Note**: > > The ability to override the default unit price is controlled by the existing *Override Charge* permission. The scope of this permission has been expanded to cover retail and direct invoice items. | | Communications | FR 3232 | **Improved efficiency on indexing body text for message and notification search** This release provides enhancements to mitigate storage limitations and expense related to storing message/notification body text in the Azure search index. > [!NOTE] > **Note**: > > The Data Lifecycle Management functionality described below is not fully developed for this release and will be delivered in a later release of Communications. - **Discontinue storage of notification body text** – Communications no longer stores the body of notifications in the Azure search index. A one-time process will remove all existing notification bodies from the index. Also, the *Body* field is disabled when Notifications are selected as the Type in Communications search. An information icon informs users that body searches only apply to Messages. - **Data life-cycle management** –When fully implemented, the system will automatically remove message body text from the search index for aged messages related to Workflow, Customer Care, Tickets and Communications after a set number of days. When a body text search is performed against an aged message it will return no results. Instead, users will get a warning indicating body text search is not available for aged messages. > [!NOTE] > **Note**: > > This release includes four new *Archive Messages* actions in Workflow that are set up specifically for Data Lifecycle Management. They are not intended for any other purpose and do not require any configuration by IDI system users. > [!NOTE] > **Note:** > > With these enhancements users will be unable to find notifications and *aged* messages when searching the body text, however, the original message and notification body text is still intact. Users can navigate to items using other search criteria to see full body text. | | FR 3258 | **Visual indication of message sent** – Prior to this enhancement, after sending a message directly from Communications, there was insufficient feedback that the message was sent which could cause users to resend the message. Now, after sending a message in Communications, a confirmation box is displayed asking users if they wish to send additional messages. Clicking **Yes** returns users to the *New Message* screen with the opportunity to send additional messages. Clicking **No** brings users to the *Search* screen to avoid having users resend the message. | #### Resolved Known Issues | **Functional Area** | **PR** | **Description** | | --- | --- | --- | | Communications | 83500 | In Customer Care, Tickets and Communications, inbound messages with no send date in the message header were displaying the send status as *pending*. The display logic in Customer Care, Tickets and Communications has been updated to set the send date to *today* when there is no send date in the message header. | | Security | 83472 | On creating a new user in any web application (Cuistomer Care, etc,,,), SaaS Security permitted creating user names with commas, for example Test,account; however, the web applications would not allow log-in with such user names. To avoid log-in errors, Security and the Security web service have been updated to not allow commas in users names. Attempting to create a user name with a comma in any web application will now result in an error. | | RateBill | 83523 | Derive commit logic has been updated to fix intermittent derive operation failures. | | Payment Processing | 83524 | On some occasions the Create Recurring E-Pay Transactions Scheduled Job would complete successfully but not process all transactions due to an internal timeout. Time out interval and batch size for creating recurring transactions were both increased to prevent this. | | Address Validation | 83499 | The system was not correctly handling situations where an address was in CoreLogic but did not have USPS validation ZIP+4 information. This caused a failure when trying to use the USPS result. The logic has been corrected to properly handle the above scenario. | | CostGuard Client E-Pay | 83517 | In CostGuard Client, on the *E-Pay Accounts* grid (select **Status** > **E-Pay** on the Customer Account screen) there was a discrepancy in the Expiration Date displayed in the upper pane (Accounts list) and lower pane (Account Information for a selected E-Pay account). In the upper pane, the Expiration Date was adjusted for the local client time. In the lower pane, the Expiration Date, as well as End Date and Recurring End Date, all show the actual date as stored in the database. To be consistent and avoid any confusion, now both views for Expiration Date show the actual date. | #### Platform System Deployment Updates: | **Module** | **Target Deployment Updates** | | --- | --- | | Communications | 08/10/2020 |