To Share or Not to Share
Last week I received a 3D file for a large department store. It was glorious. A digital artefact that revealed the dedication of store developers, shopfitters, and visual merchandisers—an entire team shaping a space to feel warm, inviting, and curious enough to make a consumer wander.
And then I opened the file.
I felt a flicker of intimidation at the vastness of it all: tags, layers, components, unique assets, materials, nested groups—an ecosystem of intent and hierarchy. I didn’t want to disturb it. I had been entrusted with the model (and I sincerely hope it was the true “as-built” file), yet I paused.
What if I broke something?
What if I renamed a layer, shifted a tag, and unknowingly disrupted an internal workflow?
What if I returned the file altered in ways that rippled through systems I couldn’t see?
Yes, yes - I see you at the back rolling your eyes.
Of course, in large corporations and institutions, there are systems. Departments with clear authority and responsibility. Redundancies built into daily workflows. Access protocols. Tiered permissions. And then, of course, the almighty silos.
Brutalist in proportion. Monumental.
Departments that communicate only when absolutely necessary - and rarely share resources, let alone 3D files.
Allow me to set the scene.
Department A: Store Plan Council Submission.
It concerns itself with storefronts, back-of-house, H&S, and plan views for council approval. Once approval is granted, its mission is complete. It lives comfortably in CAD or Revit.
Department B: The Experience Makers.
Vectorworks, Revit, AutoCAD, SketchUp - perhaps even a dash of CorelDRAW. Its sole focus: making the store feel exceptional. That overhead fire extinguisher line centred against the bulkhead? Vital to Department A. Almost invisible to Department B.
Alright, perhaps that’s a touch bleak for a Tuesday morning. Let’s reframe.
These silos don’t fail out of resistance - they struggle because they operate under different KPIs, responsibilities, and deliverables. Without a shared milestone or unified objective, there isn’t always enough overlap to create a seamless handover or shared file ecosystem.
And so, back to our generous department store team who provided the SketchUp model of their ground floor.
I realised I had two practical options:
1. The Mother File Approach
Create a master file that links to the original source material and insert my design within it, combining both while maintaining the ability to reference or revert to individual components.
2. The Protected Asset Approach
Back up the client file in a separate cloud location. Import a clean copy into my working file on its own dedicated layer. Lock it. In SketchUp, most people don’t unlock assets lightly. Semi-safe, dare I say.
But where to from here?
Surely there’s a more elegant solution.
For example, one could create a Trimble Connect project and upload the base floorplan as a view-only “source of truth.” As long as coordinate systems align, your evolving design would consistently sit on top of that fixed foundation whenever you sync.
That led me to another question.
What if the single source of truth remained embedded, but untouchable, within the shared model? Could one build a safety mechanism via an extension? A locking protocol that preserves hierarchy and protects base information?
And if so, what happens when collaborators don’t have that extension? Does the lock dissolve? Could access be tiered? Password-protected? Permission-based? Would collaborators willingly install a plugin to ensure data integrity?
If such a mechanism existed, I suspect many of us would feel less intimidated, and far more confident, opening and contributing to client files.
So here’s to the plugin developers. I’m quite certain they could solve this with one hand tied behind their back.
Who knows what’s next.
#RetailDesign #SketchUp #DesignSystems #Collaboration #DigitalWorkflow
