Fixed an issue where creating PDC Payment Schedules would sometimes not the full amount owed on an account could not be scheduled.
Fixed
Beyond 3.5.6
2025-12-15
Fixed a rare scenario that could cause connection errors in DSXQI.
Fixed
Beyond 3.5.5
2025-12-10
Improved the time it takes to load payments in the PDC tab of an account.
Changed
Fixed an error when running an action with a single history comment in it.
Fixed
Fixed an issue with the Beyond Services installer.
This addresses an issue where some files were not installed if Report Runner was the only item selected in the installer options.
Fixed
Beyond 3.5.4
2025-11-24
Improved the time it takes to load and work accounts.
Changed
Fixed an issue where vendor mail return was not properly updating the bad address flag on an account when using the deliverability status of "G".
Fixed
Fixed an issue where dates with the value "12/31/9999" would not save properly.
Fixed
Beyond 3.5.3
2025-10-23
Created a new integration with the Reassign Number Database (RND).
Reassign Number Database (RND) Integration
In this release we have added a new integration with Reassign Number Database (RND) through reassigned.us. This new integration will allow any outgoing text message to be scrubbed to verify if the number being contacted has recently be reassigned. The RND scrubbing is a 3rd party service uses an available API that DAKCS has integrated with.This integration is a paid feature with DAKCS. If you are interested in using the RND integration, please reach out to DAKCS Support to enable the feature.
Configuration on DAKCS Hub
Once the RND feature has been enabled, a new menu item RND Configuration will be added to the sidebar of the DAKCS Hub in the Communication section. If you have not setup the RND integration yet, you will see a screen with a button you can click to start the setup process.Clicking the Add Configuration button will open a flying menu on the right. There are 4 options that must be configured as follows:
Company ID - This is a unique ID that is provided by RND after signing up for their service.
Days - This determines how often DAKCS should scrub an existing phone number with RND.
By default this is pre-set to rescrub phone numbers 60 days.
A phone that DCS never attempted to text before will always be scrubbed.
API Token - This is the API Key allowing DAKCS to use the RND service.
Active - this is a simple On/Off toggle whether DAKCS should scrub numbers with RND.
Send on Failure - If RND scrubbing is active but we fail to perform the scrub, a text message will not be sent. This option allows you to override this behavior and, even if the scrub fails, a text message can still be sent out through DCS.
Reasons for a failure can vary. Some possible reasons might be be RND having and outage with their API or if you have exceeded your monthly scrub limit with RND.
If you exceed your monthly query limit, you will need to contact RND*. DAKCS does not have any way to increase your query limit.*
Note: The scrub process does not work in batches or at set times or intervals. Whenever a DCS text message is queued to send, before it is sent it will be scrubbed if needed. There is no way to “manually” scrub a number at this time besides attempting to send a DCS text message.Once the RND setup is complete, the screen will show you the configuration information as well as a usage meter. This meter shows how many queries (scrubs) you have used and how many you have left for the current cycle. It also shows the date where your RND subscription is due to expire. Your query limit and subscription duration will be based on whatever service agreement you have with RND and will likely look slightly different than the example screenshot shown below.Note: Because RND is a separate provider, DAKCS is unable to assist in managing your subscription with RND. For questions or making changes to your RND subscription users will need to contact RND directly.
RND Results Report
We have also created a new report RND Results to view the results of the phone scrubbing. Like other reports on the DAKCS Hub, this report allows you to search for a specific phone number as well as filter the results based off some window of time. Also, like other reports, the Export button will save the currently filtered list to a .CSV file.
Beyond Communication History
Lastly, we have added a new status in Communication History to identify when a phone number has been scrubbed. There are two new statuses:
Reassigned - the number was reported as reassigned at the time it was scrubbed.
RndConnectionError - the most recent scrub attempt for a phone number failed.
As mentioned previously, a scrub failure can occur for various reasons.
Lastly, we have created two new System Queries in Advanced Inquiry to search for any reassigned numbers or failed scrubs within the past 60 days. Like other system queries, these queries cannot be modified directly; if you wish to alter or build upon them, you will need to do a Save As and save a new copy of the query and make any modifications to your copied query.Note: When viewed in the Communication History on an account, the new statuses will be displayed as their proper names. However, the actual statuses are stored as numeric values in the COMMUNICATIONHISTORY@ table. The Reassigned status is represented by a the value 20 and a RndConnectionFailed is status 21.
New
Created a new action trigger in Beyond for when a portal document is viewed by a consumer.
Document Viewed Trigger
We have added a Document Viewed new action trigger to Beyond under the in the Consumer Portal trigger section in Action Designer. The trigger is fired off when a consumer views a document provided along with a DCS document link. This is helpful in verifying that the consumer viewed the document itself more so than just knowing they received the message and/or clicked the document link.Note: This trigger is not tied to any specific document or template. Once the trigger is setup, it will queue an action any time a consumer views a document on the portal. To avoid action spam or to create specific logic for specific document(s), you will need to build any conditional logic within the action. This is explained in greater detail later in these release notes.
Trigger Setup
This new trigger functions similar to others in Action Designer. The Document Viewed trigger is a new option in the Consumer Event dropdown in the Consumer Portal section of Action Trigger Setup.We have also added a new System Variable Portal Document to go along with this new trigger. When the trigger queues up an action, the specific document that the consumer viewed will be passed back in the action and you can create conditions and logic based off that document. All the properties available Portal Document are as follows:
File Name - the name of the document shown to the consumer
This is the Portal Document name, not the name of the template nor the name of the document in report designer.
Last Viewed At
The date and time the document was most recently viewed by a consumer.
Uploaded At
When the document was originally uploaded to the portal and made available for the consumer to view.
This is effectively the same time as the DCS link being sent to the consumer since the document would be available immediately when clicking the document link.
Note: the DocumentID, Record Number, and MasterLink are also available properties for PortalDocuments, but these are internal values used by the system and are unlikely to be useful within an action.Note: The “File Name” used in the example above is referring to the Portal Document Name that is setup when sending a DCS document.
New
SMS and MMS document links sent through DCS can now pull the amount owed from a field within the displayed document.
DCS Document Link Enhancements
We have a new feature for DCS Document Links that default payment amount shown to the consumer to be pulled directly from a field in the Report designer Document that is shown to the consumer after clicking the document link.
Report Designer
In Report Designer, the Payment Properties is now available all the time instead of only for QwikFlow documents. The menu can be found in Report Designer by going to:Edit → Payment PropertiesIn this menu, you can select a textbox field from within the document that you want to use as the Payment Amount Field. When a consumer uses the link and views the document, this is the prefilled payment amount that will be shown to the consumer on the Consumer Portal when they click “Make A Payment” while viewing the document.Note: The Payment Amount Field value is shown to the consumer only when they access the portal using a DCS document link. When a consumer logs into the portal manually to make a payment they payment amount will be populated with the default value.
Action Designer
In addition to the Payment Properties menu in Report Designer, we have expanded the Document Settings option in Action Designer for both the Send MMS Message and Send Communication Message nodes.Note: Only the SendMMS node is shown as an example but the configuration process is identical for the Send Communication Message node.In the Document Settings window, we have added a new checkbox Use Report Payment Amount. When this checkbox is selected, if the selected document is also configured to do so, the Payment Amount Field will be displayed as the payment amount on the Consumer Portal when they view the document and click “Make A Payment”.
Consumer Portal
When a consumer uses a document link that has been setup to use the Report Payment Amount, they will no longer see the payment amount across the bottom of the document page. The consumer will instead just look at the presented document to see the the payment amount.When the consumer clicks “Make A Payment”, the next page will be prepopulated with the value from from whichever textbox in the document is being used as the “Report Payment Amount”.Note: The Report Payment Amount is shown as the default payment value but the consumer can change still change the amount they want to pay.
New
Added a new Action Node for manually updating the Last Letter Sent on a master.
Action Designer - Update LLS Action Node
We have added a new action node in Beyond that allows manually updating the Last Letter Sent (LLS) field on accounts. This new node allows you to create more dynamic workflows with letters by moving accounts into different phases of a letter sequence without being tied to sending an actual letter.The new node operates at a debtor-level, and all qualified accounts under that debtor will be updated when it is used.Note: Accounts are qualified based on the Update Condition property that is explained below.The Update LLS action node can be found in the Action Event tab in Action Designer.The new node has three options that can be configured:
Add to Collector Time Usage (True/False) - functions the same as other nodes; controls whether the action node should add to collector time usage.
Letter Code - picks which letter code that the LLS will be updated to.
You can also free-type any 3 character letter code you wish. This includes letter codes that may not exist on your system if desired.
Update Conditions - criteria for what accounts are qualified and will have their LLS updated.
By default, this is pre-populated with a condition to exclude updating any accounts that have a status code that is PIF, SIF, C-coded, or X-coded.
When selecting a letter code, a dialog box will show all the current letter codes on your system that the LLS can be updated to.Note: The Letter Code dialog will show all the letter codes that are defined and does not filter out any old or inactive letter codes.
Risks of Updating Last Letter Sent (LLS)
The LLS field on an account is heavily involved with automated letter sequence processes. Manually updating the LLS field can alter the behavior of these automated processes and also may cause confusion when viewing an account where the LLS shows a value when that letter may not actually been sent on the account.We recommend exercising caution when building actions with the new Update LLS node and testing the actions you create thoroughly to ensure they are operating as desired.