Feature deep dive

Versions and audit log: what changed, who changed it, when

Maintenance is where a warehouse design spends most of its life. Save a version at every release, compare and restore, and read a permanent field-by-field record of the changes made in between.

Request a trial Back to features

Version timeline listing v1 to v6 with descriptions, tags and source badges, and restore and compare actions

Overview

The maintenance half of the pipeline

Versions capture the model at the moments you choose; the audit log records each change to the model in between.

A warehouse outlives its first release by years. Sources change, business definitions are revised, new marts are added, and every change request starts with the same questions: what is in production, what has changed since, who changed it, and what else does it touch.

A version is a snapshot of the whole design: the logical model with its submodels, concepts and graphs, the dictionary, every physical model with its generated DDL, every Flow and the sources. The version you record as deployed is also the baseline the next migration script is planned from.

The audit log runs continuously underneath. It records who changed which field, from what to what and when, across the logical model, dictionary, Flow, physical models, sources and tasks — without anyone having to remember to take a snapshot.

Walkthrough

From release baseline to an answered audit question

Three views that carry a design through years of change.

Step 1

Save a version at every milestone

Take a snapshot with a description and tags such as release or baseline; the number — v1, v2, v3 — is assigned for you and never reused. Model One also takes one automatically before an import, a restore and other broad operations. If a change goes wrong, restore only the entities, relationships, physical models and Flows you tick, with a safety snapshot taken first.

Snapshots of the whole design, numbered for you, with a description and tags
Manual, Import and Auto badges show how each version was made
Restore the objects you tick, or roll the whole logical model back
A Before restore snapshot is always taken first, so there is a way back
Any version can be the baseline of a migration script

Migrations in the physical model

Step 2

Compare before you release

Compare any two versions, or a version with the working model. Every change is listed as added, removed or modified with its before and after values, and classified breaking, non-breaking or cosmetic, so a release review can start with the breaking changes, such as a removed column or a changed datatype. What a change would do to rows already in the database is the migration plan's job: it labels each step safe, lossy or blocking.

Any two versions, or a version against the current working model
A heading per kind of object, with each changed object on its own row and its before and after values
Breaking, non-breaking and cosmetic counts to triage a release
Database risk read from the migration plan, step by step

Comparison of v4 and v5: 1 breaking, 54 non-breaking and 3 cosmetic changes, an Entities heading with each changed entity on its own titled row, and Sales Order expanded to show a renamed attribute's before and after values

Step 3

Read who changed what, and when

The Audit log tab lists every recorded edit, newest first: the object and its type, the field, the value before and after, who made the change and when. The trail is permanent, nobody can edit it, and every project member can read it, Viewers included. Most editors also show their own object's trail: the History tab on an entity, Change history on a relationship, a term, a Flow, a physical model or a work item.

Field-level record across logical model, dictionary, Flow, physical, sources and tasks
Changes made through OneAssist filed under the person who asked, marked (via assistant)
Filter by object, module, type, author, change kind and date across the whole trail
Owners can redact a sensitive value with a stated reason, and restore it later

Audit log tab with rows showing object, type, field, before and after values, author and time, one change marked (via assistant)

Highlights

What makes change safe to maintain

The questions a change request raises, answered from the model.

Impact before a change

An entity's Used in tab lists the submodels, Flows, terms and related entities that use it, and before a delete its editor names the graph objects that depend on it.

Versions as migration baselines

Record which version each environment runs, and the next migration for it starts from that version.

Undo the whole team shares

Each module keeps one shared undo history of its last 20 changes on the server, so any editor can undo a recent mistake. Changes made through OneAssist are audited, not undoable.

Redaction without gaps

An Owner can hide a personal identity code pasted into a definition, with a stated reason. Who, what and when stay visible, and it can be restored.

Ask OneAssist about history

Where OneAssist is set up, ask what happened to an entity last month or which version changed it. It reads the trail and cannot change it.

Clear about what is kept

The audit log leaves out canvas layout, colours and generated DDL. Version snapshots leave out work items, whose history is in the audit log.

Keep exploring

Where change is managed

Versions and the audit log reach into every module.

Walk a change request through with us

We will take one change through the whole loop: its impact, the work item, a new version, the migration script and the audit trail it leaves.

Book a demo Compare plans