Overview
Most organizations generate data quality reports where issues are identified, yet errors persist in Enterprise Resource Planning (ERPs), Customer Relationship Management (CRMs), and downstream analytics because there is no operational path to correction. Manual, out-of-band fixes lack auditability, recurring defects drive rework, and latency between detection and resolution undermines trust in enterprise data.
The Syniti Knowledge Platform (SKP) closes this gap with a unified execution model: it detects data quality issues, enables governed remediation through business-friendly WebApps, and writes corrected records back to source, staging, and target systems—all within a single, fully audited workflow.
How SKP Solves It
The SKP integrates the following core capabilities into one closed-loop workflow:
Data Quality detects issues and calculates scores by individual rule, data object, business process, and subject area to prioritize high-impact defects.
Construct generates governed WebApps where data stewards review, enrich, and correct failed records in familiar interfaces.
Replicate stages and loads data, including replication using OData endpoints to and from modern SaaS and SAP systems.
Orchestrate automates end-to-end workflows. Construct page events trigger tasks that invoke Replicate to load validated changes back via replications.
The SKP capture every change, user action, and system response, surfacing meaningful API and ERP errors directly to data stewards for rapid resolution.
The SKP delivers a single platform where data quality insight and execution live together, reducing time-to-fix the system of record and keeping source/target systems and the SKP continuously aligned.
Data Quality Remediation Process Example
The diagram below illustrates the end-to-end process for replicating, validating and correcting SAP data within the SKP. Data is first replicated from SAP S/4HANA Public Edition into the Data Lakehouse using Syniti Replicate, ETL, or SAP BDC Data Products. Data Quality rules are then executed on the lakehouse, and any failed records are written to the SKP Construct Database for remediation in a Construct WebApp. After the data is corrected, the updated records are written back into SAP S/4HANA, and the extraction process is rerun so that the Data Lakehouse reflects the latest changes.
Detailed Process Flow
1A. Syniti Replicate can extract data in both batch and near real time from a large number of databases and application. The diagram shows the cloud replication software pulling data from an SAP ECC or S/4HANA source and writing the data directly to the Data Lakehouse (Databricks or Snowflake).
1B. Data replication can occur via SAP BDC utilizing the Data Products and the zero-copy exposure of the Data Products into Datasphere, Databricks, or Snowflake. If SAP BDC is available we expect this to be the primary flow from SAP S/4HANA going forward.
2. Defined DQ rules are executed directly on the data lakehouse; Datasphere, Databricks, or Snowflake. The SQL executes on the lakehouse platform, and the failed data record set is then written in Step 3 to a Construct-accessible database.
3. DQ results are written to a Construct database so that failed data can then be remediated.
4. Users and rules can then update the failed dataset to resolve the issues identified and correct the data errors in a Construct WebApp.
5. Once the data is corrected, the user or approver (depending on the complexity of the approval flow) can run another Data Replication task directly from the Construct WebApp to populate the data via API back into the source system of record, i.e., SAP S/4HANA.
Note
The process then repeats so that data changes in the source system are reflected in the data lakehouse as changed data is picked up and replicated via either 1A or 1B option.
Find & Fix Problematic Data
Follow the steps below to identify and remediate invalid data records:
Prerequisites and Considerations
Configure the required data sources as Datastores using database connectivity details or OData endpoints for implementing data quality rules. Refer to Datastores for more information.
Note
You can run these rules at the source, staging, or target database. If running on the staging/target database, ensure that you use Replicate Preview to import data from the source database and apply data quality implementations on the staged/target datastores.
Create datasets for the configured datastores and ensure that data quality rules, business processes, and subject areas are defined for the configured datasets before using this workflow. Refer to Subject Areas for more information.
Validate user permissions to ensure only authorized users can update source system data.
Ensure that you create the required replications in Replicate Preview’s workspace based on datastore connections (database or OData) associated with the datasets that needs remediation.
Refer to Configure Workspace: Datastores for more information on creating target/source datastores and replications.
Refer to Using OData Endpoints for Refresh for more information on creating replications using OData endpoints.
Ensure that you create a custom Orchestrate workflow with Run Replication (Preview) tasks using the configured replications. Refer to Orchestrate Workflows and Tasks for more information.
Identify Data Quality Issues
Access the appropriate Data Quality subject area Overview page.
Run configured data quality rules against registered datasets to generate Data Quality Reports with errors and opportunities.
Use score trends to focus on high‑impact issues first and review the rule results to identify failed records.
Correct Failed Records
Access the Cloud Construct Home page and open the remediation WebApp associated with the configured dataset/datastore. If the WebApp is not configured, contact your Business Administrator (WebApp Designer) to create a WebApp that presents failed records with business context, validations, and lookups.
Note
Additional capabilities, such as notifications, basic workflows, approvals, and validations, can be built into the WebApp to support more complex logic around the data remediation and approval processing steps. Security filters can be applied to the WebApp to limit the data that certain individuals or teams see when accessing the WebApp.
Note
Configure fields on the setup of the WebApp to allow edits only on fields that require remediation.
Refer to Create a WebApp in Construct Preview for more information.
Ensure that either an OnSave Event or an event in a toolbar button is configured with the Orchestrate Workflow event task using the workflow identified in Prerequisites. Refer to Construct Events for more information.
With the remediation WebApp open, review the records that failed the DQ rules and follow the steps below:
Select a record in the grid and enter corrected values in the editable fields.
Repeat for additional records as needed.
Save changes to apply updates in bulk.
Write Corrected Data Back to Configured Datastores
Click Save to persist changes in the WebApp.
The OnSave or toolbar button event configured with the Orchestrate Workflow executes the replication process to write remediated data back to the configured datastores. Filters can be applied to limit the data returned to only records that are approved or changed.
Verify Updates
Confirm that updated values are written back to the configured datastores.
Re-run data quality rules to validate that issues are resolved.