Category: SOLIDWORKS

Integrating SOLIDWORKS PDM (Product Data Management) with a PLM (Product Lifecycle Management) system is one of the most effective ways for companies to streamline their product development process. In fact, building a connector between SOLIDWORKS PDM and PLM systems helps bridge the gap between engineering and enterprise operations. While PDM ensures files and revisions are controlled locally, PLM provides enterprise-wide visibility, connecting engineering data to the wider business, including manufacturing, supply chain, and quality teams. The scope of a connector is not to replace either system, but to create a bridge that ensures the right information flows between them. Most companies do not require an exhaustive integration of every field or object instead, they typically need a few key workflows automated. What Most Companies Need Through our experience working with manufacturing and engineering firms, we’ve found that almost 90% of companies ask for the same three capabilities when planning a PDM-to-PLM connector: These three elements cover many use cases and represent the backbone of most PDM-to-PLM connectors. Triggers for Synchronization For a connector to be practical, it must support flexible triggers that PDM administrators can configure. Based on real-world requests, there are three primary trigger methods: This three-pronged approach balances user control with automation, making it easy for administrators to configure the right level of synchronization for their company. Saving Settings A PDM-to-PLM connector requires configuration, and one of the key considerations is how and where to save settings. In addition to credentials, variable mapping is a critical part of the setup: By keeping settings lightweight encrypted credentials plus variable mappings companies ensure the connector is secure, adaptable, and easy to maintain. Technical Requirements At a technical level, the PLM system must expose a method for receiving data. The most straightforward option is a REST API: Ultimately, while workarounds exist, the presence of a well-documented REST API significantly reduces development cost and improves long-term reliability. Conclusion Creating a connector between SOLIDWORKS PDM and a PLM system is less about building an all-encompassing integration and more about solving a handful of core use cases. Nearly every company benefits from building a connector between SOLIDWORKS PDM and PLM systems that supports: When paired with flexible triggers (manual or automatic) and secure settings management (encrypted credentials + variable mapping), these features ensure smooth collaboration between engineering and the rest of the business. At the technical level, a REST API is strongly recommended, but not strictly required, to implement a reliable connector. About Blue Byte Systems Inc. Blue Byte Systems Inc. is a Canadian software company specializing in SOLIDWORKS API and PDM automation. With over a decade of experience, we have built tools and connectors that help engineering teams eliminate manual steps and keep their data in sync across platforms.Our solutions, including PDMShell, PDMPublisher, and PDM2Excel, are trusted by companies worldwide to streamline workflows and improve efficiency. Whether you need a custom connector to your PLM or a turnkey automation solution, Blue Byte Systems delivers software that puts engineers back in control of their time.

Let me start by saying this: I love SOLIDWORKS PDM tasks. And I know many people will disagree with that statement. Yes, we’re inevitably moving toward cloud-based solutions—and that’s a good thing—but small changes can still go a long way in improving an application that hasn’t seen substantial UI or UX updates in years. As a SOLIDWORKS PDM developer, I’ve spent the last five years building custom add-ins, task scripts, and automation solutions for customers across a variety of industries. I’ve even developed a framework—PDMSDK—to help developers get started with PDM add-in development quickly and consistently. After half a decade of building the same types of solutions, I’d like to share some constructive feedback—things I genuinely hope Dassault Systèmes considers improving around the PDM task framework. TaskDetails Dialog The Task Details window is used to show the result of a task execution—such as exporting a BOM or converting a file. You can access it by: Unfortunately, the current implementation has some frustrating limitations: ❌ Current Pain Points: ✅ Suggested Improvements: 🌐 Bonus Suggestion: Developer-Friendly Help Enhance the Help button by allowing developers to redirect users to a custom help page, using the existing IEdmTaskInstance.SetStatus method to capture the help page URL. This could link to internal documentation, support articles, or troubleshooting guides—far more helpful than the generic SOLIDWORKS documentation that many users are currently redirected to. Task List This is the admin’s go-to view for tracking scheduled and completed tasks. Currently, it’s only available through the PDM Administration tool. ❌ Usability Friction: Accessing the task list involves: That’s at least 4 clicks and multiple credential fields—just to view task history. For admins who check this daily, this feels excessive. ✅ Suggested Improvements: The Task Setup Dialog The Task Setup interface is generally well designed, but there are a few important areas where improvements could go a long way, especially for custom task developers. ❌ Pain Points: The dialog has a fixed width and height. While this is acceptable for built-in tasks provided by SOLIDWORKS, the available UI space becomes minimal when developing custom tasks with custom pages. For example, on the Options page, a vertical scrollbar appears—not because of too much content, but because the parent dialog’s width is fixed. Ideally, the task setup dialog should use a resizable tool window (SizableToolWindow in WinForms/Win32 API terms) Rather than a fixed tool window, it allows developers more flexibility in designing user-friendly interfaces. The Execution Method requires prior permission for the task’s add-in to be granted through the Task Host Configuration dialog—a step that is often overlooked by many PDM administrators. To permit an add-in, you must: Unfortunately, these steps are time-consuming and not immediately obvious. ✅ Suggested Improvements: Here are a few miscellaneous issues that make working with tasks harder than it needs to be: 2. No filtering in permission dialogs: Vaults with many users/groups suffer from a lack of search or filtering options when assigning permissions to run or edit tasks 3. Increase or remove the character limit for Text content in notifications. 4. Custom notification text (email or dialog): Custom notification text in SOLIDWORKS PDM tasks supports HTML, but the current character limit severely restricts how much formatting or content can be included. This makes it difficult to implement even basic branding or effective communication practices. For example, adding structured sections, links to support resources, or styled text is often impossible due to these constraints. This is especially limiting when trying to deliver modern, user-friendly notifications similar to what users might expect from platforms like the 3DEXPERIENCE Marketplace, which uses rich HTML formatting to provide clear instructions, embedded links, and visually branded experiences. Adding to the frustration, the PDM Inbox uses an ActiveX browser control, which limits rendering to legacy standards. However, newer versions of Windows and .NET support using the Microsoft Edge WebView2 control—a modern, Chromium-based browser component that supports full HTML5, CSS3, and JavaScript. 5. Parallel Execution for the Same Task Type One of the long-standing limitations in SOLIDWORKS PDM is that tasks of the same type can only run one at a time per Task Host. For example, if you trigger ten Convert to PDF operations, they will be executed sequentially, even if the machine has 16 cores and plenty of RAM.This creates a bottleneck, especially for organizations running high volumes of repeatable, lightweight operations like: if you love SOLIDWORKS PDM tasks, imagine how much more powerful they could be with parallel execution. What if administrators could specify how many instances of the same task type are allowed to run in parallel on the same host? Imagine a “Maximum Concurrency” setting in the task definition that allows 2, 3, or more simultaneous executions of that task—on the same machine. Of course, allowing multiple task instances on the same machine introduces complexity: That said, these are solvable problems—especially for tasks that are stateless and read-only. And in some environments, admins would gladly accept the risk in exchange for faster throughput.