WorksManager

Good day, everyone.

I have a feeling this may be a lengthy post, but there is quite a bit to unpack. I want to clearly lay out the workflow problems I am experiencing with WorksManager and see whether others in the heavy-civil and infrastructure side of the industry are running into the same issues.

Let's talk about the elephant in the room: TCC is gone.

As someone who generally embraces technology shifts and change, I can appreciate the desire to rebuild, modernize, and improve existing infrastructure. By trade, most of us in this community do that every day. We tear down what is outdated and replace it with something intended to work better.

However, improvements must be tested, stressed, and measured against real-world use. If a replacement adds steps, removes administrative control, separates previously connected workflows, and increases the opportunity for human error, then we need to ask whether the process has actually improved.

At its current build, WorksManager has made the process of creating, distributing, retrieving, reviewing, and archiving survey data significantly more cumbersome for my operation.

This is specific to my workflow, but I believe many people working in heavy civil and infrastructure likely operate in a similar manner.

My operational environment

I manage multiple surveyors working on different projects across three states.

Each project has its own job folder. Within each job folder is a Survey Requests directory, with the requests cataloged in numerical order.

Each survey request contains the full history of that work, including:

• The original survey request
• Office calculations
• Design data sent to the field
• Data returned from the field
• Any supporting documentation or revisions

Our basic folder structure includes:

• Survey Request
• Office Calculations
• Data to the Field
• Data from the Field
• Year
• Month

This is not simply an organizational preference.

When a conflict occurs, installed work must be verified, or an audit is performed months or years later, I need to be able to locate the original request, identify exactly what design was created, determine what data was sent to the field, and compare it against the data returned by the surveyor.

Each of my surveyors may create three to seven work orders per day. Those work orders must be cataloged into their respective survey-request folders and compared against the design data used to perform the layout.

That review process allows me to verify what was staked, identify discrepancies, maintain traceability, and help prevent rework.

The previous TCC design workflow

Under TCC, the design side of the workflow was straightforward.

I would:

1. Complete the layout calculations or design preparation in TBC.
2. Export the VCL into the applicable survey request's Data to the Field folder.
3. Create the field design through SCS Data Manager.
4. Place the completed design file directly into the appropriate data collector through TCC's File Manager structure.

The design stored in the survey-request folder served as the office record of exactly what was prepared and sent to the field.

The same desktop-based file structure handled both the project archive and the delivery of the design to the data collector.

If the design was placed into the correct collector folder, I knew where it was going. The archived office file and the field-delivery process were directly connected through a familiar file-management structure.

The current WorksManager design workflow

I can still export the VCL from TBC into the applicable Data to the Field folder, but that now only satisfies the office-record side of the process.

It does not complete the delivery of the design to the field.

To actually get that design to the surveyor, I must then:

1. Open WorksManager in a web browser.
2. Log in.
3. Complete two-factor authentication.
4. Navigate to the correct WorksManager project.
5. Locate or verify the intended data collector.
6. Confirm that the collector is associated with the correct project.
7. Create the design in WorksManager.
8. Upload or associate the required files.
9. Publish the design.
10. Confirm that I published it to the correct collector.

The office archive and the field-delivery platform are now two separate workflows that must be maintained independently.

That adds time, but the larger concern is the number of new failure points it creates.

A design can be properly stored in the survey-request folder but published to the wrong data collector. It can be created under the wrong WorksManager project. The intended collector may not be associated with the project. A surveyor may have moved to another project, or the wrong device may be selected during publication.

When managing several projects, surveyors, and data collectors across multiple states, these are not insignificant risks.

The previous workflow was largely file-path driven. The current workflow depends on browser navigation, project associations, device assignments, design creation, publication selections, and verification that the correct device is currently available within the selected project.

This also creates duplicated administrative work.

The design still has to be stored in our formal survey-request folder for project records, traceability, and auditing. I then have to separately recreate and publish that design through WorksManager.

Confirming what was archived in the project folder does not, by itself, confirm what was actually published to the field.

The previous TCC return-data workflow

The return-data process under TCC was also direct.

Once the surveyor completed the fieldwork:

1. The returned data became available through the connected project and collector structure.
2. I accessed the files through File Explorer.
3. I moved or copied the data into the applicable survey request's Data from the Field folder.
4. I compared the returned data against the office calculations and the design stored within the same survey-request directory.
5. The complete record remained in a logical and searchable project structure.

The original request, calculations, design, field files, and returned data all remained tied together.

The current WorksManager return-data workflow

WorksManager has replaced that file-based process with a browser-based system centered around individual projects, devices, designs, and work orders.

When I download completed work orders, they arrive in a compressed Work Orders package.

That package must then be:

1. Downloaded.
2. Extracted.
3. Opened.
4. Reviewed.
5. Identified by project, surveyor, device, or request number.
6. Manually routed into the correct project and survey-request folder.

That may not sound significant when discussing one work order.

It becomes significant when several surveyors are each producing three to seven work orders per day across multiple projects.

Survey-request numbers can also repeat between projects. SR1001 on one project has no relationship to SR1001 on another project.

The request number alone is therefore not enough to determine where the returned data belongs. The project, surveyor, device, or another identifying component must also be considered.

Surveyors also move between projects, meaning a surveyor or collector cannot always be permanently tied to one project for routing purposes.

I have implemented a work-order naming convention to help compensate for this:

Survey Request Number + Layout/As-Built/Control + Date + Surveyor Initials

For example:

1001L260523TM

That naming structure helps me identify and route the work order after it is downloaded, but it is still a locally developed workaround for administrative and archival functions that should already be supported by the platform.

Where the current process breaks down

The issue is not simply that WorksManager looks or operates differently from TCC.

The problem is that a previously connected workflow has been separated into multiple independent processes for archiving, design creation, publication, device management, retrieval, and record retention.

The main issues I am encountering include:

• The office archive and field-delivery platform are now separate systems.
• Exporting and correctly filing a VCL no longer completes the design-delivery process.
• Every design requires a separate browser-based creation and publication workflow.
• Two-factor authentication interrupts a process that may need to be repeated several times throughout the day.
• Designs must be created under the correct WorksManager project.
• Designs must be published to the correct collector.
• The correct collector must already be associated with the correct project.
• Surveyors and collectors may move between projects.
• Project and device associations create additional opportunities to publish data to the wrong location.
• There is no simple file-path relationship between the archived office design and the design published through WorksManager.
• Confirming what was archived does not confirm what was published.
• There does not appear to be a clear record connecting the exact archived VCL to the exact design distributed to the field.
• Returned work orders must be downloaded as a compressed package.
• The package must be extracted, reviewed, identified, and manually filed.
• Data from multiple projects, devices, and surveyors must be manually routed into the correct archive.
• TBC only exposes the devices and work orders associated with the currently connected WorksManager project.
• TBC can read or import work-order data, but it does not provide the administrative tools needed to fully manage, archive, reassign, or remove it.
• Cleaning completed work orders from multiple collectors requires navigating through the devices rather than managing them from one consolidated account-level location.
• There does not appear to be an efficient bulk-management process for completed work orders.
• The system does not naturally integrate with an established SharePoint or File Explorer project-record structure.
• The current process creates more opportunities for data to be published incorrectly, misplaced, duplicated, or left unarchived.

Each individual step may appear minor when viewed by itself.

At the scale of several projects, surveyors, collectors, designs, and daily work orders, those steps accumulate into a substantial administrative burden.

More importantly, every additional selection, project association, manual download, extraction, and routing decision introduces another opportunity for human error.

Functionality that would substantially improve WorksManager

For WorksManager to properly support a heavy-civil survey department, I believe it needs the following:

1. A supported desktop synchronization utility or File Explorer integration.
2. A consolidated account-level view of all projects, devices, designs, and work orders.
3. Bulk selection, download, archive, reassignment, and deletion of completed work orders.
4. The ability to manage devices across projects from one location.
5. A clearer relationship between the design archived in the office and the design published to the field.
6. A publication record identifying exactly which design revision was sent to each collector.
7. Revision control and the ability to confirm which design is currently active on each device.
8. The ability to export work orders while preserving project, device, surveyor, design, date, and work-order metadata.
9. Configurable automatic routing based on project, device, work-order name, surveyor, or request number.
10. Direct integration with SharePoint, OneDrive, or another designated project archive.
11. A clear distinction between active, completed, and archived work orders.
12. Administrative tools within TBC rather than read-and-import access only.
13. Search and filtering across all projects instead of requiring the user to connect to each project individually.
14. A documented long-term workflow for retaining survey records after designs and work orders are removed from active devices.
15. A more direct method of publishing an exported TBC design without recreating the delivery process through a separate browser workflow.

What are other users doing?

I understand that my workflow may not represent every WorksManager user. However, I suspect many survey managers supporting heavy-civil and infrastructure projects have similar requirements for quality control, traceability, auditing, and long-term record retention.

I would genuinely like to hear how others are handling this.

• How are you archiving completed work orders?
• How are you managing returned data from several projects and collectors?
• How are you tying the exact design stored in your office records to the design actually published through WorksManager?
• How are you verifying that the correct design revision was sent to the correct device?
• Have you found a bulk-management tool that I am overlooking?
• Is there a supported way to automatically route downloaded work orders into an existing project-folder structure?
• Is there an easier method of moving collectors between projects and managing those associations?
• What is Trimble's intended workflow for organizations that must retain and audit years of survey-request data?
• Is there a planned desktop application or synchronization utility that will restore some of the functionality lost with TCC?

I am completely open to learning that I have overlooked existing functionality or that there is a more efficient workflow available.

However, based on my current use of WorksManager, the transition from TCC has not improved this part of our operation.

It has replaced a direct, file-based workflow with separate systems that require more manual handling, more repeated steps, and more administrative oversight while providing less centralized control.

WorksManager appears to function well as a method of delivering files and work orders to individual devices. What it does not currently appear to provide is a complete data-management workflow for the people responsible for creating, reviewing, distributing, auditing, organizing, and retaining that information.

I hope Trimble will evaluate WorksManager not only from the perspective of getting a file onto a data collector, but from the perspective of the survey managers and administrators responsible for the entire lifecycle of that data.

------------------------------
Thomas Moncrief
------------------------------