Why I Still Love SOLIDWORKS PDM Tasks (And What Needs to Change)

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:

• Right-clicking a failed task in the Task List
• Selecting Task Details

Unfortunately, the current implementation has some frustrating limitations:

❌ Current Pain Points:

• The window does not resize properly
• Error messages are often cut off, especially long ones
• There is no clear distinction between PDM errors and custom add-in errors
• The OK and Help buttons are not anchored—they remain static regardless of resizing

✅ Suggested Improvements:

• Make the window resizable
  • Set FormBorderStyle = Sizable
  • Apply a minimum size (e.g., 500×400)
  • Anchor controls properly so they adjust with the window
• Use multi-line, scrollable text boxes for errors and logs
• Group metadata fields clearly: Started by, Executed by, Start Time, End Time
• Use clear section headers and consistent alignment for labels and values
• Add keyboard navigation support (Tab, Enter)
• Add a “Copy to Clipboard” button for error messages

🌐 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:

1. Searching for PDM Administration in the Start Menu
2. Launching the tool
3. Logging in to the vault (every time)
4. Navigating to the Task List

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:

• Add Task List access to the vault tray icon (edmserver.exe / blueberry icon)

• When a task succeeds, clear any residual error messages. The error message The method was executed successfully does not make any sense:
  

• Add a search box in the completed and pending tasks lists
• Add a column for the filename or folder the task was run on

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:

• Locate the edmserver.exe (the blueberry icon) in your system tray.
  • If it’s not visible, you’ll need to log in to your vault via File Explorer first.
• Right-click the icon and select Task Host Configuration.

• Choose the appropriate vault from the dropdown and check Permit.

Unfortunately, these steps are time-consuming and not immediately obvious.

✅ Suggested Improvements:

• Ideally, the Task Host Configuration should be accessible directly from the Execution Method section—though integration into the setup dialog is unlikely.
• A more practical solution would be to add a “Permit Add-in” checkbox within the task setup UI, allowing the user to enable the associated add-in on the current machine.
• Alternatively—and most feasibly—a button could be added next to the Refresh button to launch the Task Host Configuration dialog directly. This would likely be the most intuitive and effective improvement.

Here are a few miscellaneous issues that make working with tasks harder than it needs to be:

1. Tasks can’t be scheduled directly on selected files, folders, or search. This limits automation flexibility and makes batch tasks more complex

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:

• File conversion (PDF, STEP, DXF, etc.)
• Custom printing
• Metadata extraction or stamping

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.

• Select 10 drawings
• Trigger Convert to PDF
• Instead of queuing 10 tasks in a long line, 3 launch in parallel, the rest queue behind them
• Machine resources are better utilized, and users get results faster

Of course, allowing multiple task instances on the same machine introduces complexity:

• Resource contention: If two tasks write to the same temp path or use shared registry keys, results may conflict.
• Add-in architecture: Existing tasks are not designed to be reentrant or isolated—changes may be needed at the add-in level.
• Error handling and logging: Separate logs per instance would be required to prevent overlap.

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.