Muljat Group Commercial

Muljat CRM Review

This page is for Muljat Group Commercial team members.
Enter the password to continue.

Muljat Group Commercial  |  Bellingham, WA
Build Spec for Robert · Space Breakout & the Property–Space Model

One property, many spaces — break out and connect.

Model a property as having one space or many; break a space out into its own deal when it gets an offer (2228 Queen St); and connect existing space-level deals up to their parent property card (Salish Village). Plus the property→space→lease data model, stacking plans, and floor plans inside the CRM — with diagrams of the exact behavior.
In Troy's words (6/12): "I look at properties as having either one space or multiple spaces. I want to break out a property into multiple spaces depending on its current situation. I'd like to see building plans or floor plans within the CRM when there are multiple spaces."
← Back to the Review Checklist

Visual reference — the two leasing workflows

Mockups of the exact behavior, drawn from the real cards on the board (2228 Queen St and Salish Village). Cards styled to match the CRM's leasing pipeline.

① Break out a space — 2228 Queen St

One building, two spaces. When a space gets an offer, split it into its own deal that advances on its own — while the parent stays Listed for the rest.

● LEASING · LISTED
2228 Queen St
2228 Queen Street · Bellingham, WA
2 spaces · 3,750 SF total
▪ Suite A · 1,875 SF · AVAILABLE
▪ Suite B · 1,875 SF · LOI RECEIVED
→
● LEASING · its own deal
2228 Queen St — Suite B
1,875 SF · breaks out & advances:
LOI → PENDING → SIGNED
● LEASING · LISTED (unchanged)
2228 Queen St — Suite A
1,875 SF · stays Listed for the remaining space

② Connect space deals to the parent property — Salish Village

Five separate tenant deals already exist on the board — they all need to link UP to the one Salish Village property card, so the property shows every deal and its stage (and each deal can click up to the property).

★ PROPERTY CARD
Salish Village
4839 Rural Ave · Ferndale, WA
40,000 SF · 5 active space deals
All deals below roll up here ↓
⇄
● Columbia Bank
OFFER/NEG
● McDonald's
LEASE PREP
● Tunnel Car Wash
OFFER/NEG
● Nicole's Sea Brew
OFFER/NEG
● Walmart
LISTED
+ future spaces

Same model as ①: the property is the hub; each tenant is a space-level deal connected to it. Break-out (①) creates these; connect (②) links ones that already exist.

The Property → Space → Lease data model

The universal pattern every serious CRE platform uses (RealNex, AscendixRE, VTS, Prophia): a property has one to many spaces. A single-space property is just the degenerate case — one space child. Don't special-case it; that way a multi-tenant office building and a single-tenant NNN ground lease are the same shape.

Recommended schema

PROPERTY (building)                       — the parent record
  name, address, APN/parcel, type (office/retail/ind/MF),
  total_rentable_SF, year_built, owner_contact_id, floors_count,
  floorplan_files[]   (one per floor: image/PDF + hotspot-map)
  ── rollups (COMPUTED from spaces): occupancy %, vacant_SF,
       WALT (weighted-avg lease term), avg in-place rent

  └─ SPACE / SUITE   (child, 1..N)        — one OR many per property
       suite_number, floor, rentable_SF,
       status  (Vacant | Occupied | Available-leased | Under-LOI),
       current_lease_id, tenant_contact_id,
       asking_rent / listing_id  (when on the market),
       floorplan_hotspot_id     — links suite to a region on the plan

       └─ LEASE   (child of space, with history 1..N over time)
            tenant, landlord, guarantor,
            commencement, rent_commencement, expiration,
            lease_type, base_rent_schedule[], escalations[],
            CAM/opex terms, pro_rata_share, CAM_cap,
            security_deposit, TI_allowance, options[],
            source_doc_id, verified

            └─ ABSTRACT_FIELD  (granular, for the AI workflow)
                 field_name, value, source_page, confidence,
                 verified_by, verified_at

Five design rules

  1. Single-space = one space child. "Break out a property into multiple spaces" = add Space rows. The whole-building lease is suite "100 / entire building."
  2. Status lives on the Space, not the Property. Occupancy %, vacant SF, and WALT are computed rollups from the spaces — never typed in.
  3. Lease is a child of Space, with history. Re-leasing a suite creates a new Lease row; the old one stays. The "current" lease drives the stacking-plan color and rollups.
  4. Every abstracted field carries a source-page citation + verified flag. This is the line between "works well" and "Pattern."
  5. Floor plan = a file per floor + a hotspot map linking regions to space.id. A space's status change auto-recolors its hotspot — same engine as the stacking plan, different geometry.

Stacking plans (the multi-space view Troy wants)

A stacking plan is a floor-by-floor / suite-by-suite visual of how a building is occupied — each block is a suite, sized to its SF, stacked by floor. It's just a render of the Spaces collection, so it comes almost for free once the model above exists.

ConventionDetail
Vacant = greenIndustry-standard — the one thing you want to spot instantly
Occupied = color by expiration yearEach lease-expiration year gets its own color, so a floor rolling over the same year visually clusters as risk
Hover / click a blockTenant, SF, base rent, lease start/expiration, options
Roll-up metrics on the planRentable SF, vacant SF, occupancy %, WALT, avg in-place rent
Dynamic, not ExcelAuto-updates the instant a lease/abstract changes — the whole point vs. a hand-built PowerPoint

Note: this pairs with the CBA color system Troy already specified for the CRM (blue=industrial, red=office, green=retail, yellow=multifamily) at the property level — and the green=vacant / color-by-expiry convention at the space level inside a building.

Floor / building plans inside the CRM

How to do it (the AscendixRE pattern)

How the incumbents do it (credibility check)

PlatformSpace model + abstraction + plans
ProphiaSelf-service abstract → 99% (AI + human QA) → feeds a per-property dynamic stacking plan automatically. Abstract from ~$20/doc.
Crexi Vault~2 min/doc, 24+ fields, bulk up to 100 docs → searchable records by asset/occupancy. Free to Crexi users.
Zuva / LeaseLensFormer Kira engine, 200+ fields. Free to extract, pay per export — the cheap benchmark to beat.
AscendixREObjects: Properties → Availabilities/Spaces → Leases; stacking plans + floor plans inside the CRM.
VTSSystem of record for space ↔ lease ↔ deal ↔ building; instant extract + expert verification; dynamic stacking plans.
RealNexProperty has a "Spaces" tab; responds to inquiries with floor plans + unit availabilities. Cleanest reference model.

Recommended build order

For Robert — sequence that compounds

  1. Ship the Property → Space(s) → Lease model first (single-space = one child). Everything else renders off it.
  2. Add the lease-abstract workflow with source-page citations + a verified toggle, auto-filing to the Space.
  3. Render the stacking plan from the Spaces collection (green=vacant, color-by-expiry; rollups computed).
  4. Add floor-plan upload + suite hotspots linked to Space records (same recolor engine).
  5. Wire it to the deal card — the cascading-suites requirement from 6/12 (Bender Plaza: one suite leasing under a building you list entirely) is exactly this model surfaced on the pipeline.

This is the one CRE-specific capability the Muljat CRM is currently missing versus the paid incumbents — and with the data model above, the stacking plan and floor-plan views come almost for free.