Remediation Improvement
Remediation can be further simplified by having an option in the report to turn on remediation and provide a value. Then in the background the report is updated in SQL with the value provided and the user does not have to go into SQL. If the logic is more complicated then the user can go into SQL and update. The remediation value would then be visible in the UI for the report
Log in to comment and vote
Comments2
John Munkberg
May 1, 2025
Hey Derek! We used to have this, I called it “Static” remediation. You simply configured the value as part of the Report Definition. When that report ran, for example, it would just default all the blank or invalid LAND1 fields to “US”.
The feedback I got (consistently) was that the Business user had no visibility to the “remediation value” in the error report.
So we deprecated that feature so that you always need to specify the “LAND1_REMEDIATE” value in the report itself. When remediation is enabled, a user would see LAND1 and LAND1_REMEDIATE columns, giving them very positive confirmation that they have bad data in their error report, but for this Mock cycle we will be remediating all these records to US.
If remediation is disabled, then those reports should NOT show the LAND1_REMEDIATE field because nothing will be remediated, and all these error will remain in the load files because remediation is disabled.
To address you main challenge - it’s a pain to open the view in SQL to edit the value - we are working (very soon) to release an IN APP SQL Editor. Very soon you will be able to edit the REPORT SQL directly from the SKP platform - in the browser! No reason to leave the product. That should make this much simpler to maintain over time.
Note the SQL Assistant which is useful for people like me that are intimidate by typing SQL queries :-)
John Sanders
Aug 28, 2025
Need to bundle remediation with considerations for reporting overhaul.