Choose visual checks for missing values, uniqueness, row counts, ranges, patterns, permitted values and matching references. More complex rules can use custom SQL with an explicit condition for passing.
Data Quality
Find data exceptions before the next step.
Define what acceptable data means, run repeatable checks and inspect recorded failures. Use supported workflow gates to stop downstream work when a required check fails.
A preview checks the current rule without storing a run. Saving creates or updates the rule. Run now or a supported workflow step saves the execution result and a limited failure finding when the check does not pass.
A quality-check job or control step in a coordinated workflow can stop supported downstream work. The workflow execution, quality-check result and reason it was triggered remain separately recorded.
Custom SQL is not universally checked by an independent parser that guarantees one read-only statement. Use least-privileged read credentials and exclude secrets and unnecessary personal data from samples. After editing a rule's SQL, rerun it: an earlier result does not validate the new version.
Rules can change and are not directly pinned to dataset versions. Rule suites, automatic repair, complete finding remediation and confirmed notification delivery are not current capabilities. Managed Sandbox tables are checked through the project's Sandbox source.
Define what acceptable data looks like.
Choose visual checks for missing values, uniqueness, row counts, ranges, patterns, permitted values and matching references. More complex rules can use custom SQL with an explicit condition for passing.
Missing and empty values
Duplicate values and row-count limits
Numeric or comparable value ranges
Text patterns and permitted values
References that must exist in related data
Custom SQL with a defined pass condition
Try a rule, save it, then keep the result of its execution.
A preview checks the current rule without storing a run. Saving creates or updates the rule. Run now or a supported workflow step saves the execution result and a limited failure finding when the check does not pass.
Preview returns a result immediately without saving an execution record.
Save updates the editable rule definition.
Manual runs and supported workflow runs retain their execution result.
A failed check keeps a limited quality finding, separate from the Assurance finding workflow.
Stop the next workflow step when a required check fails.
A quality-check job or control step in a coordinated workflow can stop supported downstream work. The workflow execution, quality-check result and reason it was triggered remain separately recorded.
Keep database access and failure samples appropriately restricted.
Custom SQL is not universally checked by an independent parser that guarantees one read-only statement. Use least-privileged read credentials and exclude secrets and unnecessary personal data from samples. After editing a rule's SQL, rerun it: an earlier result does not validate the new version.
Know what is checked and what still needs separate handling.
Rules can change and are not directly pinned to dataset versions. Rule suites, automatic repair, complete finding remediation and confirmed notification delivery are not current capabilities. Managed Sandbox tables are checked through the project's Sandbox source.
Next step
Start with the flow that cannot afford ambiguity.
Bring the systems, owners, rules, delivery obligations and evidence requirements that matter.
Discuss a critical flowIn brief
What does this part of advanexus do?
Define what acceptable data means, run repeatable checks and inspect recorded failures. Use supported workflow gates to stop downstream work when a required check fails.
What should I check before using it?
Suite execution, automated repair and a complete finding-remediation workflow are not current capabilities.