Connect to data

Sync an ontology with Microsoft Fabric

Syncing keeps an ontology in Kenseme and an ontology item in Microsoft Fabric in step. A push sends your classes, attributes, relationships, descriptions, and lakehouse bindings up to Fabric. A pull brings changes made in Fabric back into Kenseme. Every run shows you a preview first.

In the app: Data Context › Ontologies › your ontology › More › Bind to Lakehouse › environment bar

Before you start

  • The ontology needs a lakehouse binding environment that names a Fabric ontology item. You set this up when you create the environment. See Bind an ontology to a lakehouse.
  • You need Read/Write access in the organization to change bindings and resolve conflicts. See Roles in Kenseme.
  • Your organization needs a working Fabric credential with access to the target workspace.
  • Save your work first. The sync button is disabled while you have unsaved binding decisions (Save or reset your unsaved decisions before syncing).

Note: A lakehouse is optional on the environment. Without one, a push publishes the ontology’s structure to Fabric with no data bindings.

Push, pull, or sync

The sync control on the environment bar is a split button.

  • The first time, its label is Publish to Fabric. It creates the content of the Fabric ontology item.
  • After the item has been published, the label is Sync, which reconciles both directions in one run.
  • Its menu always offers Push to Fabric and, once the item exists, Pull from Fabric.
Run What it does
Push Sends changes from Kenseme up to Fabric.
Pull Brings changes made in Fabric down into Kenseme.
Sync Does both in one run. Anything that changed on both sides becomes a conflict for you to decide.

While a run is in progress, the environment bar shows Syncing…. Afterwards it shows the latest run’s result, and a warning badge with a number if conflicts are waiting.

Preview before you run

Every push, pull, or sync opens a preview. Nothing changes until you click the run button.

[screenshot]
The sync preview with its change counts, a warning, and the grouped change list above the Execute button.

The preview shows:

  • Counts: Push, Pull, Conflicts, and Existence (things deleted or unbound in Fabric).
  • The change list, grouped into Push to Fabric, Pull into Kenseme, Conflicts, Existence (deleted in Fabric), Unbound in Fabric, and Informational. Each row names the entity, its kind, and what changes.
  • AI risk summary, an optional button that explains the run’s risk in plain language, starting with anything destructive.

It can also show three kinds of problem:

  • Stale bindings. Bindings that point at lakehouse tables or columns that no longer exist. Tick Skip stale bindings for this run to leave them out; otherwise the run fails.
  • Blocking problems. Things Fabric would reject, for example a relationship whose endpoint class has no entity key. You can’t run until they’re fixed. Fix all applies the automatic fixes it can, saves them, and reopens a fresh preview.
  • Warnings. Worth reading, but they don’t stop the run.

If there’s nothing to do, the preview says Everything is in sync — nothing to push (or pull, or sync). It compares against the last saved baseline. If you believe the two sides have drifted anyway, click Reset baselines & re-check to force a fresh comparison against Fabric.

When you’re ready, click Execute Push, Execute Pull, or Execute Sync. If the run has conflicts, the button says how many (for example Execute Sync (3 to review)). Conflicts are never applied automatically. They wait for you in the conflict review.

What a push sends to Fabric

  • Structure: classes become Fabric entity types, attributes become properties, and relationships become relationship types.
  • Bindings: each bound class, attribute, and relationship is published with its lakehouse table, columns, and entity key.
  • Descriptions and synonyms:
    • A class’s description becomes the entity type’s description, and its label plus alternative labels become the entity type’s synonyms.
    • Attributes and relationships push their descriptions. They have no synonyms in Fabric.
    • A description longer than 1,024 characters is shortened to fit, and the preview points out any description that will be.

A pull brings the same fields back: descriptions from Fabric land in your ontology, and an entity type’s synonyms return as alternative labels.

A push only writes the fields Kenseme manages, so other content you added in the Fabric portal stays. Descriptions and synonyms are Kenseme-managed, though. If a push would clear a description or synonyms that someone wrote in the Fabric portal, the preview warns you and names the class, attribute, or relationship. Pull first to keep the portal text, or write it into the ontology in Kenseme.

Resolve conflicts

A conflict means the same thing changed on both sides since the last run, or one side deleted something the other still has. Kenseme doesn’t guess which side wins.

To open the conflict review, click the warning badge on the environment bar or the Resolve conflicts (N) button in the workspace.

[screenshot]
The Resolve conflicts dialog with the Kenseme and Fabric columns side by side and the per-row buttons.

Each row names the entity and what happened, such as Edited in both, Deleted in Fabric, edited in Kenseme, Deleted in Kenseme, still in Fabric, or Unbound in Fabric, bound in Kenseme. The Kenseme and Fabric columns show each side’s value; a missing side reads — absent —. Expand a row for the full field-by-field comparison. Use the Filter: chips to narrow a long list to structure, binding, or existence conflicts.

Resolve each row with one of these:

Button Effect
Keep Kenseme Keeps your version. It goes up to Fabric on the next push.
Keep Fabric Takes Fabric’s version now. If that overwrites an edit you made in Kenseme, you’re asked to confirm.
Edit… For a binding conflict: pick the Table (and Column) yourself, then Resolve with edit.
Restore to Fabric / Delete in Kenseme When Fabric deleted something you still have.
Restore in Kenseme / Keep deleted When you deleted something Fabric still has.

Anything that deletes in Kenseme asks you to confirm first.

To resolve many at once, use Keep all Kenseme or Keep all Fabric. Tick some rows first and those buttons become Keep Kenseme for selected (N) and Keep Fabric for selected (N).

Keeping your Kenseme side (or an edited binding) is staged until your next push; a note reminds you to run Sync. Taking the Fabric side applies immediately. When the last conflict is resolved, the badge and the button disappear.

When the Fabric item has been deleted

If someone deletes the Fabric ontology item, the environment bar shows Fabric item missing. Click it to recover:

  • Re-create on next push clears the link to the dead item. Your next push publishes a new Fabric item. The environment stays set up for sync.
  • Unlink environment does the same and also switches sync off for this environment, so it becomes a plain binding environment until you run a sync action again.

Neither option changes your ontology or its bindings.

Deploy a saved version

The runs above work on the live ontology. You can also push a saved version from the ontology’s Versions page. The deploy dialog previews the change list in Added, Updated, and Removed groups, then offers:

  • Additive Only — add and update in Fabric, but never remove anything.
  • Full Overwrite — make Fabric match the version exactly, which removes anything Fabric has that the version doesn’t.

When a deploy would remove items, the dialog tells you how many Full Overwrite would delete and how many Additive Only would keep.

Warning: Full Overwrite deletes Fabric content that isn’t in the version, including items that may only have been renamed. Read the change list and warnings before choosing it.

See Ontology versioning.

Review past runs

Every push and pull is recorded on the ontology’s Sync History page, with what changed, who ran it, and why a run failed. See Ontology sync history.