RevitCDE — solution overview

For buyers

01What this is

RevitCDE is a Common Data Environment for Revit projects.

It binds user actions to concrete model objects.

Key idea

Build an auditable digital loop.

For buyers

02For whom

RevitCDE addresses several distinct roles.

BIM coordinator / Project manager

Sees the state of model, approvals, documents and tasks.

Author (designer)

Works in Revit without constant context switching.

Approver

Reviews incoming requests with snapshot and documents.

Viewer

Read access within project scope.

Estimator

Estimate database, line items, non-model costs.

Planning engineer

Schedule, activities, non-model time processes.

Administrator

Server, users, projects, databases, policies.

For buyers

03Problems we solve

Gap between Revit and management processes

Why it hurts

Approvals and tasks live separately from the model.

How we fix it

The plugin captures model data and links requests to objects.

No single source of truth

Why it hurts

Files, e-mail and spreadsheets drift apart in versions.

How we fix it

A CDE structure stores projects, documents, versions and history.

Opaque approvals

Why it hurts

Decisions get lost and routes are informal.

How we fix it

ApprovalRequest, multi-stage routes, append-only events, immutable snapshots.

Model status invisible in Revit

Why it hurts

The designer does not see what is approved, pending or rejected.

How we fix it

Statuses mirrored into Shared Parameters and Extensible Storage.

3D, 4D and 5D not connected

Why it hurts

Estimate and schedule run separately; non-model work drops off the radar.

How we fix it

Per-project estimate.db and schedule.db, WorkPackage as the 4D/5D hub.

Offline / local work without a server

Why it hurts

Detached models need local storage without losing the path to a server.

How we fix it

Local mode in Extensible Storage, optional external single-file DB, later migration to server.

For buyers

04How it works

Three layers form a single data loop.

The user works in Revit. The plugin reads model elements, sheets, views, schedules and statuses.
The model is bound to a server project. The binding is stored inside the RVT model via Extensible Storage.
The plugin syncs project elements, model elements, changes, statuses, requests, tasks, chats and documents with the server.
The server keeps global data in the main database and subject data in per-project bases: model_{guid}.db, disciplines.db, estimate.db, schedule.db.
The web cabinet exposes projects, documents, approvals, tasks, chats and administration; realtime updates flow over SignalR.
Approver decisions, status changes, linked documents and tasks return to Revit and surface in the plugin and model parameters.

Architectural principle

The server is the source of truth for collaborative mode; the model still keeps the minimum binding and local data so work survives Revit restarts and offline windows.

For buyers

05What it does

The functional map at a glance.

Projects

Project setup, members, roles, standards, disciplines, stages, packages.

Model

RVT binding, sync, identifiers, fingerprint, statuses, dirty tracking.

Approvals

Requests, routes, snapshots, decisions, withdrawal, journal, realtime.

Documents

CDE documents, versions, upload/download, SHA-256, WIP→Shared→Published→Archived.

Tasks

Kanban, Gantt, importance, statuses, assignees, task relations.

Communications

Project chats, messages, reactions, correspondence, e-mail integration.

Administration

Users, roles, server parameters, databases, health, authorisation policies.

4D/5D

Estimate, schedule, WorkPackage, quantity snapshots, EVM/CPM.

Local work

Extensible Storage, optional external local DB, migration to server.

Localisation

Centralised UI localisation, 22 languages by roadmap.

For buyers

06Usage scenarios

Submitting a sheet or view for approval

Step 1
Step 2
Step 3
Step 4
Step 5
Step 6

A document from WIP to publication

Step 1
Step 2
Step 3
Step 4
Step 5

Linking model, estimate and schedule

Step 1
Step 2
Step 3
Step 4
Step 5

For buyers

07Frequently asked questions

Question 1

Answer 1

Question 2

Answer 2

Question 3

Answer 3

Question 4

Answer 4

Question 5

Answer 5

Question 6

Answer 6

Question 7

Answer 7

Question 8

Answer 8

Question 9

Answer 9

Question 10

Answer 10

Technical detail

08Solution composition

Component	Purpose	Technology
`RevitCDE.Addin`	Revit add-in entry point, model binding and command registration.	C# /.NET Framework, Autodesk Revit API
`RevitCDE.UI`	Desktop panels, commands and user interaction inside Revit.	WPF / MVVM
`RevitCDE.Core`	Application services, synchronization, local storage and server communication.	C# services, HTTP clients, SQLite
`RevitCDE.Domain`	Shared domain models, identifiers, statuses and business rules.	netstandard2.0 library
`RevitCDE.Server`	Central API, authentication, project data and integration services.	ASP.NET Core 8, EF Core, PostgreSQL
`RevitCDE.Cabinet`	Web cabinet for projects, documents, approvals, tasks, chats and administration.	TypeScript / React web UI
`RevitCDE.Localization`	Central translation dictionaries and language switching for all visible UI.	JSON dictionaries, shared i18n keys

Technical detail

09Local and server modes

RevitCDE supports two runtime modes.

Local mode

Data lives in the model's Extensible Storage.

External local storage

A separate database file per RVT model.

Server mode

Active data lives on the server.

Local & server modes

Migration rules from local to server.

Technical detail

10Storage architecture

Store	What it stores	Why it works this way
Main server DB	Users, organizations, projects, roles, global settings and license data.	Keeps cross-project data in one authoritative server database.
model_{guid}.db	Model elements, sheets, views, schedules, quantities and model-level bindings.	Large model data is isolated per RVT model for performance and maintenance.
disciplines.db	Project disciplines, stages, packages and standard-specific documentation structure.	Project standards can evolve without changing the global schema.
estimate.db	Estimate documents, positions, non-model costs, quantity links and WorkPackage bindings.	Cost data has its own lifecycle and must include items not present in the model.
schedule.db	Schedule activities, dependencies, non-model time processes and WorkPackage links.	Planning data needs CPM/Gantt logic and may reference both model and estimate data.
Extensible Storage	Minimal model binding, technical identifiers and local fallback data inside RVT.	The model remains self-identifying even outside the server environment.
External local DB	Optional one-file local database for chats, approvals, documents, tasks and other local data.	Detached/local models can keep richer data without bloating Extensible Storage.

Technical detail

11Security and access

Security is built around membership, roles, JWT and trust modes.

JWT authentication.
Secure password hashes; bootstrap admin at initial setup.
Login by username, e-mail or phone if configured.
User login is the primary mode.
Optional workstation mode without password.
High-trust actions still require a real sign-in.
Project-scoped Read / Write / Manage / Admin.

Technical detail

12Approvals — under the hood

A formalised, reproducible process.

Submit for approval

Creates an approval request for the selected model revision or document package.

Immutable snapshot

Records the exact model and document state being reviewed so the decision remains reproducible.

Approval routes

Defines ordered or parallel review steps, responsible participants and required decisions.

Recorded decisions

Stores approvals, rejections, returns and comments together with author and timestamp.

Event history

Keeps an append-only timeline of submissions, assignments, decisions and status changes.

Status synchronisation

Returns the confirmed approval status to the project objects and connected Revit workflow.

Real-time updates

Publishes approval changes to connected clients without requiring a manual page refresh.

Technical detail

13WorkPackage — the 4D/5D hub

The central object linking model, quantities, estimate, schedule and progress.

`ModelElement`	Links the work package to BIM elements and their stable identifiers.
`QuantityItem`	Stores measured quantities and the source from which each quantity was obtained.
`EstimateItem`	Connects quantities with estimate positions, unit rates and calculated cost.
`WorkPackage`	Acts as the central object joining scope, model, cost, schedule, responsibility and evidence.
`ScheduleActivity`	Links the work package to planned activities, dates, dependencies and critical-path data.
`ProgressSnapshot`	Stores actual progress, earned-value indicators and reporting-period facts.

Why no cross-DB FK

Project databases are split by subject area.

Technical detail

14Standards, disciplines, stages, packages

Project standard drives documentation, estimate and schedule formats.

`ProjectStandard`

Defines the active project rules, naming conventions and required information structure.

`Discipline`

Maintains the project discipline catalogue and discipline-specific responsibilities.

`PackageType`

Defines reusable package structures for design, procurement and construction work.

`ProjectStage`

Controls project stages, stage transitions and the data expected at each stage.

`ProjectRole`

Defines responsibility, permissions and approval authority within the project.

`StandardPreset`

Applies a reusable bundle of standards, disciplines, stages, roles and package types.

Technical detail

15REST API — primary groups

REST API by subject area, JWT-authenticated.

`/api/auth/*` · Authentication, account sessions, password recovery and access tokens.
`/api/approvals/*` · Approval requests, routes, decisions, comments and status changes.
`/api/cde/*` · Projects, models, documents, issues and shared project data.
`/api/chats/*` · Project conversations, participants, messages and attachments.
`/api/tasks/*` · Tasks, assignees, due dates, priorities and completion states.
`/api/standards/*` · Project standards, disciplines, stages, roles and package presets.
`/api/45d/*` · Work packages, quantities, estimates, schedule activities and progress.
`/api/admin/*` · Administration, configuration, diagnostics and controlled maintenance operations.

Technical detail

16Glossary

CDE: Common Data Environment — a controlled space for project information, communication and decisions.
Extensible Storage: Revit mechanism for storing structured application data inside a model.
Shared Parameters: Revit parameters shared across projects and families through a common definition file.
ProjectElement: A project-side record representing a BIM element outside the Revit document.
ModelElement: A stable reference to an element in a specific model and model revision.
Snapshot: An immutable record of the exact project data state used for review or approval.
ApprovalRequest: A formal request that sends a defined scope through an approval route.
WorkPackage: The central 4D/5D object joining scope, quantities, cost, schedule and responsibility.
EVM: Earned Value Management — progress measurement using planned value, earned value and actual cost.
CPM: Critical Path Method — schedule analysis based on activity dependencies and available float.

Technical detail

17What's on the way

The current implementation has a working core; below is what we're growing next.

Expanded localisation

Complete terminology review and domain-specific wording for every supported locale.

Document workflows

Versioned document registers, transmittals, review packages and evidence chains.

Deeper 4D/5D

More detailed work-package planning, cost control, progress forecasting and earned-value analysis.

BCF interoperability

Exchange issues and viewpoints with other BIM applications through the BCF standard.

Linked-model coordination

Coordinate linked models, ownership, revisions and cross-model dependencies.

Observability

Operational dashboards, audit metrics, diagnostics and service-health monitoring.