A lot of SolidWorks time is not really design time
It is finding the right drawing. Checking whether the model has the right properties. Opening an assembly just to confirm where a part is used. Exporting PDFs, STEP files, DXFs, and other release files one at a time. Then checking the names, moving them into the correct folder, and hoping nothing was missed.
None of that work is especially complicated. That is probably why it gets ignored. But it still takes time, and when it is repeated across dozens or hundreds of files, it quietly eats into the engineering day.
That is where Solidise is useful.
Solidise is not trying to take over the design work. SolidWorks is still where the modelling, drawings, configurations, and engineering decisions happen. Solidise is built for the work that surrounds those files: browsing, checking, understanding relationships, and preparing exports in a more controlled way.
The problem is not one export. It is the repeated export process.
Exporting a single PDF from a drawing is not a big deal.
The problem starts when a release needs 40 drawings as PDFs, 40 models as STEP files, sheet metal parts as DXFs, and maybe a BOM export for purchasing or production. Suddenly the job is not “export a file.” It is a small admin project.
The engineer has to make sure the correct models are selected, the drawings match the parts, the output formats are right, and every file lands in the proper location. Then there is naming. File names often need part numbers, revision letters, descriptions, materials, customer references, or other custom properties.
That is exactly the type of detail that becomes risky when it is handled manually.
A missed revision in a file name might not look like much, but it can cause confusion once the files are sent to a supplier or moved into a manufacturing release folder. The work is repetitive, but it still needs accuracy.
Solidise helps by turning that release preparation into a workflow rather than a series of manual clicks.
Solidise sits around SolidWorks, not in place of it
The way I think about Solidise is simple: it helps you manage what is already in your SolidWorks environment.
It uses a local agent and gives the user a browser-based workspace for browsing and working with CAD information. That distinction matters. Many teams are cautious with CAD data, especially when the files are large, sensitive, or tied to customer work. The useful part here is that the files stay on the workstation, while Solidise indexes the information needed to make them easier to search, inspect, and process.
For teams without a full PDM setup, this can be especially valuable.
Windows Explorer can only tell you so much. It can show file names, folders, dates, and sometimes thumbnails, but it does not really understand the CAD structure. It will not give you the bigger picture of how parts, assemblies, drawings, configurations, properties, and BOM data relate to each other.
Solidise adds that CAD context around the files.
That means you can browse parts, assemblies, drawings, thumbnails, custom properties, configurations, BOM information, and where-used relationships from one workspace before deciding what actually needs to be opened in SolidWorks.
Browsing CAD files should not require opening everything
Anyone who has worked with older SolidWorks folders knows the problem.
You remember the bracket. You might remember the project. You might even remember part of the part number. But the folder has several similar files, the thumbnails are not helpful, and the file names do not tell the full story.
Without context, finding the right file becomes trial and error.
Open a part. Wrong one. Open another. Check the drawing. Go back to the assembly. Search again. Repeat.
Solidise makes that process less blind. Instead of relying only on file names and folders, you can inspect more useful CAD information first. You can see what a file is, what properties it carries, what drawing belongs to it, what assembly it appears in, and whether it is part of a larger structure.
The where-used information is one of the most practical parts of this.
A component can be reused in several assemblies, and that is not always obvious from the folder structure. Before editing, replacing, renaming, or deleting a part, I want to know where it is used. Otherwise, a small change can create problems somewhere else.
Having that check available as part of the browsing workflow makes a difference. It lets you understand the impact before you start changing files.
The automation queue is where the time savings become obvious
The browsing side helps you find and understand the files.
The automation page is where the file browsing turns into Solidworks batch file export.
In Solidise, selected parts, assemblies, or drawings can be added to an export queue. From there, you choose the output formats you need, such as PDF, STEP, DXF, or other supported SolidWorks export types.
The important thing is not only that Solidise can export in batches. The important thing is that the batch can be reviewed before it runs.
That is where many manual processes fail. You only discover the problem after the export has already created a folder full of files. Maybe two outputs had the same name. Maybe the revision was missing. Maybe a drawing was included that should not have been included. Maybe a naming rule produced something that looks fine for one file but breaks for another.
Solidise gives you a chance to preview the queue and check the naming before running the export.
That makes the export process feel less like “click and hope” and more like a controlled release step.
Naming rules are more important than they look
A STEP file with the wrong name is still a STEP file, but it is not a very useful release file.
Most teams have some kind of naming logic. It might be based on part number and revision. It might include description, material, thickness, customer code, or manufacturing process. The specific rule changes from company to company, but the need is the same: exported files should be clear, consistent, and traceable.
The problem is that engineers often end up cleaning names manually after export.
That might be fine for five files. It is not fine for 150 files.
Solidise can use SolidWorks custom properties inside naming rules, which is where it becomes practical. If the part already has a revision property, the export name can include that revision automatically. If the description or material is already stored in the model, those values can be used too.
For example, a team might want the exported name to include a revision only when that revision field is filled in. Instead of manually checking every file, the naming rule can handle that condition. A part called Flange with revision B could export with a name like:
Flange.REV_B.step
That is a small detail, but small details are exactly where release work becomes slow and error-prone.
The goal is not just faster exporting. It is cleaner exporting.
Why I would look at Solidise for this kind of work
There are bigger systems in the SolidWorks ecosystem, and they absolutely have their place.
Some teams need full PDM. Some need strict revision control, approvals, permissions, lifecycle states, and formal engineering change processes. For those teams, a larger data management system may be the right answer.
But not every team is trying to solve that whole problem.
Some teams simply need a better way to browse SolidWorks files, understand where parts are used, check BOM context, and export release files without spending half a day on repetitive processing.
That is the area where Solidise makes sense to me.
It stays close to the actual day-to-day workflow. Find the file. Understand what it belongs to. Check the related data. Select the outputs. Preview the names. Run the export.
That is not a huge promise, but it is a useful one.
To see Solidise in action check out this video: Solidise Walkthrough video.
A practical tool for practical SolidWorks work
The best engineering tools are often the ones that remove boring work without adding a new layer of complexity.
Solidise fits into that category. It helps with the tasks that SolidWorks users already deal with: file browsing, BOM checks, where-used review, batch exports, naming rules, and release preparation.
It still depends on good habits. Custom properties need to be filled in properly. Release rules need to make sense. Teams still need to know what they want to export and why.
But when those basics are in place, Solidise can make the process much smoother.
For me, the value is simple: less time spent opening files just to check them, less time renaming exported outputs, and less time repeating the same release steps by hand.
That leaves more time for the work engineers should actually be doing.