No-code database quality

A no-code app is only as dependable as its records. Good database quality lets someone identify the right record, understand its fields, change it safely and trace what changed later. Define those behaviours for each critical table first.

Define what a usable record looks like

For each table, write down its purpose, owner and fields needed at each stage. A new request may need a submitter and description, while a completed request may also need a decision and completion date. Requiring every field at creation can push people to enter guesses. Allow a genuine unknown where the workflow permits it, then ask for the value when someone can reasonably know it.

Use consistent field types and controlled choices where they help. A status field should have a short list of meanings that staff share. Give someone responsibility for changing those meanings; adding another near-identical choice can fragment reports. Keep display labels understandable and document any code or abbreviation used by an integration.

Quality rules should apply to every route into the table: forms, imports, automations and APIs. In Dataverse, column requirement determines whether data is required to save the row. Check your platform’s actual behaviour rather than assuming a form setting protects every write path.

For Dataverse columns used in imports or integrations, check that the underlying name is stable as well as the display label. Microsoft Learn notes a column’s unique name is generated from its display name and cannot be changed after creation because applications or code may reference it. Custom column names also include the solution publisher’s customisation prefix.

Critical Field Rules for Record Quality

Give each record an identity

An internal record ID answers “which row is this?” It does not necessarily answer “is this the same customer or request?” Decide which real-world identifier, or combination of fields, should be unique.

A customer number may suit an account; a person’s name usually is not. If an external system supplies the identifier, keep its original value and source so an import can match existing records.

Treat likely matches and guaranteed uniqueness separately. A match on name and email may flag a record for review, while a supported unique key can identify records using a defined combination of values. Review existing duplicates before enabling a new constraint. Also test concurrent submissions and imports: a lookup performed before saving is not necessarily a uniqueness guarantee.

Dataverse alternate keys can identify a row using one or more column values that form a unique combination. Microsoft Learn gives account number as an example and advises using values that should not change. Alternate keys are intended for programmatic use, including integrations where an external system does not store Dataverse row IDs.

Dataverse supports alternate-key columns of type Decimal, Whole Number, Single line of Text, Date and Time, Lookup or Choice. The feature can make external data imports without row IDs simpler and support more robust bulk data operations. Check that the chosen fields fit these supported types and that their combined values represent the identity you need.

Preserve missing information honestly

Blank, zero, “No” and “not applicable” express different things. Do not fill an unknown price with zero or an unanswered approval with “No” merely to make a table look complete. Define which fields may be blank, which need an explicit reason, and which must be supplied before the next workflow step.

Check calculations and reports that read those fields. A count of records with a known amount has a different denominator from a count of all records. If the interface displays a fallback such as “Awaiting amount”, keep that label separate from the stored value.

Handling Missing Information: Best Practices

Control changes that affect many records

A bulk edit can correct a consistent error, but it can also apply a new mistake across a whole filtered view. Before running one, record the selected IDs, the exact field and intended new value, the expected number of affected records, and who approved the change. Make a recoverable copy using the platform’s available export, snapshot or backup facility, then test a small sample.

Check the result against the original selection. Inspect records at the edge of the filter, not just obvious matches, and confirm that automations or notifications behaved as expected. Do not assume a platform’s “undo” covers imports, integrations or every bulk operation. If the change cannot be safely reversed, pause for a more controlled method.

Keep the history that the business needs

For important fields, decide what question the history must answer: who changed a value, what it was before, when the change happened and why. A platform’s revision feed may answer some of these questions, but its retention and export options may be limited.

A backup serves recovery; an audit trail serves investigation; a decision log explains the business reason. They are related, but they do different jobs.

Limit access to history where it contains sensitive values. Check whether automated changes identify the automation as well as the person who initiated it, and whether history survives an export or move to another platform. If the platform cannot retain the required evidence, design a separate controlled change log before the need arises.

When history contains personal information, include its handling in record-quality controls. The Office of the Australian Information Commissioner (OAIC) says entities covered by the Privacy Act 1988 must take reasonable steps to protect personal information from misuse, interference, loss, and unauthorised access, modification or disclosure. The OAIC guide describes technical and organisational measures as part of those steps.

The OAIC guide also covers reasonable steps to destroy or de-identify personal information when it is no longer needed, unless an exception applies. The guide is not legally binding, but the OAIC may refer to it when exercising its Privacy Act functions. Use this as a prompt to define how long personal information in records and history is needed and what happens afterwards.

Audit Trail vs Backup vs Decision Log

Make quality routine

Give each important table a business owner. Review a small, repeatable set of exceptions: suspected duplicates, overdue missing fields, failed imports and unexplained high-volume changes. Fix the rule that created a recurring problem, then correct affected records.