Sign inGet started

Workflows

Design Once, Export to Multiple Stacks

Goal: Use OWB as the single source of truth for a data model that needs to power multiple systems simultaneously — database, API layer, graph store, semantic tooling, and documentation.

Prerequisites

  • A model that represents a reasonably complete domain (entity types with properties and cardinality-set relationships)
  • The model should be in a state you're ready to export from (all validation issues resolved)

Steps

1. Open or create the source-of-truth model

Open the model you want to export from on the dashboard, or create a new one. This model is your single source of truth — all downstream formats are generated from it. Keep it complete and accurate before exporting.

2. Verify entity type properties are fully specified

Click through each entity type in the sidebar. For every property, confirm:

  • Data type is set correctly (String, Integer, Float, Boolean, DateTime, Enum, etc.)
  • Required flag is set where the field must always be present
  • Enum values are defined for any Enum-typed property
  • List item type is set for List-typed properties

Incomplete properties produce warnings in exports (e.g. a property without a type may be emitted as String by default, which could be wrong for your target stack).

3. Verify relationships have cardinality set

Select each relationship in the sidebar. Every relationship should have a Cardinality value (1:1, 1:N, N:1, or N:M). Cardinality controls how ORM exports model foreign key constraints and how graph exports model edge multiplicity.

Relationships without cardinality are flagged by validation and will produce a comment in the exported output.

4. Run validation — fix all issues

Click Validate in the toolbar. The drawer lists every error, warning, and info notice across the model.

Fix all errors before exporting. Warnings are exported with inline comments (the output is still valid), but it's best practice to resolve them — they usually indicate missing information that will matter at runtime.

Once the drawer shows 0 issues, you're ready.

5. Export to Prisma

Click Export in the toolbar. Select Prisma Schema.

The output is a schema.prisma file with:

  • model blocks for each non-abstract entity type
  • @relation annotations derived from your relationships and cardinality
  • Prisma enum blocks for Enum properties
  • Abstract entity types skipped with a comment (their fields are inherited by concrete subtypes)

Copy the output into your prisma/schema.prisma file and run prisma generate to validate it.

6. Export to GraphQL SDL

Back in the export drawer, select GraphQL SDL.

The output is a .graphql schema where:

  • Abstract entity types become interface definitions
  • Concrete types that inherit from an abstract parent include implements
  • Required properties are non-nullable (!)
  • Relationships become typed fields pointing to the target entity type

Drop this file into your GraphQL server's schema directory.

7. Export to Neo4j Cypher

Select Neo4j / Cypher.

The output contains:

  • CREATE CONSTRAINT statements for unique IDs on each node label
  • MERGE patterns for creating nodes and edges
  • Edge property definitions for relationships that carry their own properties

Run the constraint statements against your Neo4j instance to initialize the schema.

8. Export to OWL/RDF

Select OWL / RDF.

The output is an OWL/XML document where:

  • Entity types map to owl:Class
  • Object properties (relationships) map to owl:ObjectProperty
  • Data properties map to owl:DatatypeProperty
  • Inheritance is expressed as rdfs:subClassOf
  • Semantic annotations (disjointWith, equivalentTo, deprecated) are preserved

Open the file in Protégé or load it into Apache Jena for semantic reasoning.

9. Export to HTML Documentation

Select HTML Docs.

The output is a standalone HTML file with a complete reference for every entity type, its properties (with types and required flags), and its relationships. No external dependencies — share it directly with non-technical stakeholders, drop it in a wiki, or attach it to a ticket.

10. Take a snapshot labeled with the version

Click Version History (clock icon) and then + New snapshot. Label it something like v2.1 — exported 2025-01-15. Click Save.

This locks the exact model state that produced your exports. If a downstream system breaks after a schema change, you can return here and see precisely what the schema looked like at export time.

What happens next

  • Publish and automate — publish the model so it's available via the REST API, then use the API export endpoint to pull schemas in CI without opening the workbench. See the API Endpoints reference.
  • Share the documentation export — the HTML Docs file is a self-contained stakeholder artifact. Use the share link to give non-technical reviewers a live view of the published canvas.
  • Track changes — subsequent edits create a new draft. Re-export after each publish to keep all target-format files in sync.