There's a phrase that echoes through Slack channels and Teams chats in every company that builds physical products: "Can you send me a screenshot of that?"
It's asked by product managers who need to approve a design. By QA analysts who need to reference a part geometry. By procurement teams comparing a supplier's drawing to the internal spec. By sales engineers preparing a customer presentation.
Every time it's asked, an engineer stops what they're doing, opens CAD software, positions the model, takes a screenshot, and sends it over. Sometimes one screenshot isn't enough. Sometimes the requestor needs a different angle, a different zoom level, or a different configuration.
This isn't a failure of communication. It's a failure of tooling. Here are five Confluence workflows that eliminate the screenshot request entirely - and what each one looks like in practice.
Workflow 1: The self-service design review
The old way: An engineer creates a design review page in Confluence, writes up the design rationale, attaches the CAD file, and exports a few screenshots to embed in the page. Before the meeting, reviewers message the engineer: "Can you rotate to the bottom view?" "Can you show the cross-section at the midplane?" "What does the assembly look like from the back?"
The better way: The engineer creates the review page and embeds the CAD model using the Model Viewer macro. No screenshots needed. Before the meeting, every reviewer opens the page and explores the model themselves - rotating, zooming, cross-sectioning from any angle they need.
How to set it up:
Create a Confluence page template for design reviews with these sections: design intent (text), the embedded model (Model Viewer macro), revision history (revision tracking shows past versions), and review comments (standard Confluence comments or inline comments).
The key detail that makes this work: set the viewer to load the model in a default orientation that shows the most important features. Reviewers who need a different view can rotate themselves. Reviewers who just need the overview see something useful immediately.
What changes: Reviews that used to require 30 minutes of screen-sharing ("let me rotate to show you this area") now start with everyone already familiar with the geometry. The meeting becomes about decisions, not orientation.
Workflow 2: The living manufacturing work instruction
The old way: Manufacturing documentation references specific part drawings. Technical writers export DWG files as PDFs and embed them in the Confluence page. When the drawing updates, the PDF stays stale until someone remembers to re-export - which might be weeks later. Machine operators sometimes work from outdated drawings because the PDF on the Confluence page doesn't match the latest release.
The better way: Embed the actual DWG file in the Confluence page using the Model Viewer macro. When the drawing is updated in AutoCAD and the new version is uploaded to Confluence, the embedded viewer shows the latest version automatically. Revision tracking records the change.
How to set it up:
For each work instruction page, attach the native DWG file (not a PDF export) and embed it with the viewer macro. Establish a workflow where design updates trigger a new file upload to the same Confluence page. Use revision tracking to maintain the history - if manufacturing needs to reference a previous version, it's accessible without digging through file archives.
Add a "Last updated" callout panel at the top of the page that references the current drawing revision number. This gives operators a quick visual check that the instruction is current.
What changes: The documentation is always current. The manual export-and-upload step that nobody enjoyed and everyone forgot is eliminated. Drawing discrepancies between documentation and design drop to near zero.
Workflow 3: The QA defect library
The old way: QA finds a defect on a physical part. They create a Jira issue and describe it in text: "Wall thickness below tolerance in the upper left region of the bracket." The engineer reads this and asks: "Which bracket? Which region? Can you mark it on a drawing?" QA takes a photo of the physical part, annotates it in paint, and attaches it to the Jira issue. The engineer has to mentally map a phone photo back to the CAD model.
The better way: Build a QA defect reference library in Confluence. For each part family, create a Confluence page with the 3D model embedded. When QA finds a defect, they reference the model - "wall thickness issue in the area visible when you rotate to this orientation and zoom in here" - with enough specificity that the engineer can locate the feature in CAD without back-and-forth.
How to set it up:
Create a Confluence space (or section) called "Part Library" with one page per part or assembly. Each page has the current CAD model embedded via Model Viewer, plus a table of known defect areas with descriptions and linked Jira issues. Use the Model Catalogue feature to make the library searchable - so QA can find the right part quickly when filing a new defect.
For teams that also use Model Viewer for Jira, the same CAD file can be attached directly to defect issues. This gives the engineer the model right in the Jira issue without navigating to Confluence.
What changes: Defect reports become precise. The "which bracket?" back-and-forth disappears. Engineers can reproduce the issue faster because they can see exactly where on the geometry the problem was found.
Workflow 4: The supplier collaboration space
The old way: A supplier sends a revised part drawing by email. Procurement downloads the DWG, realizes they can't open it, and forwards it to engineering. The engineer opens it in AutoCAD, compares it to the internal spec, and reports back: "Looks fine" or "The flange diameter doesn't match." This cycle can take days if people are busy.
The better way: Create a shared Confluence space for supplier collaboration. When a supplier sends updated drawings, upload them to the relevant Confluence page. Procurement, engineering, and quality can all view the drawings inline - comparing the supplier's file to the internal design embedded on the same page.
How to set it up:
For each active supplier, create a Confluence page (or page tree) containing: the internal design specification with the CAD model embedded, a section for supplier-submitted drawings (each embedded with Model Viewer so they're viewable by everyone), a comparison notes section where procurement and engineering can comment on differences, and revision tracking to show the evolution of supplier drawings through the quoting and approval process.
Use Confluence's page restrictions if the space contains sensitive design data that should be limited to specific teams.
What changes: Procurement can do initial drawing reviews themselves - flagging obvious discrepancies before routing to engineering. The turnaround time for supplier drawing reviews drops from days to hours. Engineering only gets pulled in for technical judgment calls, not for "can you open this file and tell me what it looks like."
Workflow 5: The engineering onboarding wiki
The old way: A new engineer joins the team. They spend weeks asking: "Where do I find the model for the XYZ assembly?" "What's the current revision of the housing?" "Do we have a drawing for this bracket?" Senior engineers become walking indexes of the file system, losing time to questions that should be self-service.
The better way: Build a product knowledge base in Confluence where every major part, assembly, and drawing is catalogued with an embedded interactive model. New engineers browse the catalogue, explore models, and understand the product without scheduling walkthroughs.
How to set it up:
Create a hierarchical page structure in Confluence that mirrors your product architecture: top-level assembly -> sub-assemblies -> individual parts. Each page has the CAD model embedded, a brief description of the part's function, key specifications, and links to related documentation (test procedures, manufacturing instructions, supplier information).
The Model Catalogue makes this searchable - a new engineer who needs "the intake manifold" can search rather than navigate the page tree. Revision tracking shows how each part has evolved, which gives context that a raw CAD file alone doesn't provide.
What changes: Engineering onboarding time decreases. New hires become productive faster because they can explore the product independently. Senior engineers reclaim the hours they used to spend as human search engines.
The common thread
All five workflows share the same principle: make CAD files viewable by everyone, right where the work happens. The specific workflow details - page templates, naming conventions, space structures - are things each team will customize. But the enabling capability is the same: embed the actual CAD file in Confluence and let people interact with it directly.
CAD 2D and 3D Model Viewer for Confluence supports 70+ formats including DWG, DXF, SolidWorks, CATIA, Inventor, Revit, Fusion 360, Creo, Siemens NX, STEP, IGES, STL, and more. Combined with Model Viewer for Jira for issue tracking and CAD Model Viewer for Outlook for email workflows, your team has CAD visibility everywhere they work.
Built by Move Work Forward. SOC 2 Type II certified. Trusted by 7,000+ businesses.
