Engineering Productivity
Digital Workflow for Structural Engineering Teams
A practical digital workflow for structural teams: files, names, permissions, transmittals, and how analysis, CAD and PDFs stay on the same revision without a maze of folders.
A digital workflow is not a platform purchase. It is an agreement about where the live file lives, what it is called, who may edit it, and which PDF was actually sent. Structural teams bleed time in that agreement’s absence: two STAAD files both called FINAL, a CAD folder called NEW-NEW, and a transmittal that points at a path nobody can open from the shop. Fixing this is unglamorous and worth more than another analysis licence sitting unused because nobody can find last issue.
Small teams think they can keep it in their heads. They can, until someone is ill on issue day. Multi-office teams think a shared drive is a workflow. It is a place. Without names and permissions it is a faster way to overwrite. The same failure mode appears in PEB work, conventional steel and mixed BIM offices. The file types change; the need for one live copy and one issued copy does not, and emailing a desktop file around the problem only hides it for a week.
This article stays at team scale: folders, names, issue packs, and how analysis, CAD and drawings stay related. It complements the detailing process and PEB design workflow. Tools such as Staad2CAD, Excel Programs and the MBS Approval Package only help if their outputs land in the same issue pack as the PDF the reviewer received. A clever export into the wrong folder is another FINAL-FINAL, and the shop will quote whichever file arrived last in the inbox that morning from whoever plotted it.
Two copies, always
| Copy | Who edits | Who trusts it |
|---|---|---|
| Working | Assigned authors | Nobody outside the team |
| Issued / frozen | Nobody (or document control only) | Reviewer, shop, future you |
| Superseded | Nobody | Archive; do not plot |
| Personal scratch | One person, not on the server job path | Never the shop |
Files, folders and names
Pick a shallow tree and keep it. Project / discipline / working or issue / date or revision is enough. Deep trees of ‘CAD/steel/peb/latest/from-ahmed’ are search problems. Names should sort: project, type, number, revision. Spaces and “final” are how people pick the wrong file.
- No FINAL, NEW, or today’s initials in the filename of a live working file
- Revision in the issued PDF name, matching the title block
- Analysis files named with the same job number as the drawings
- One current working folder; old attempts go to a named archive, not a sibling called ‘old old’
Who can edit what
Permissions are a workflow. If everyone can edit the issued folder, it is not issued. If only one person can edit CAD, you have a queue. Typical split: authors write in working; a lead or document controller copies a freeze into issue; the shop sees issue only.
Issue and transmittal
An issue is a folder plus a transmittal: what was sent, revision, purpose (for approval, for information, for fabrication), and holds. The approval submission checklist is the steel-specific version. Digitally, also list native files if they were part of the contract.
Transmittals should quote the drawing numbering system so the receiver can file sheets. A dump of sixty PDFs named by plot time is not an issue.
Combining analysis, CAD and PDF
Store the analysis file that produced the issue next to the drawings, or in an analysis folder with the same revision tag. If geometry was transferred, store the export. If reactions were tabulated, store the raw import. MBS output quality checks belong in that bundle when MBS is the source.
| If you issued… | Also freeze… | Otherwise later you cannot… |
|---|---|---|
| Reaction sheet | Raw listing + analysis file | Prove which load case was used |
| CAD plans from an export | The export and the model it came from | Diff the next run |
| Approval PDFs | The DWGs and the data table for titles | Regenerate without guessing |
| Shop NC | The model revision identifier | Know which PDF the machine matched |
Small-team versus multi-office
A five-person office can run this with a shared drive and discipline. Multi-office work needs the same names plus a clock: whose 5 p.m. freeze is the issue, and who may overwrite working files overnight. Time zones do not cause errors; unowned files do.
Small team
One working folder, one issue folder per revision, one person who copies the freeze. That person can still be the CAD lead. The role has to exist.
Multi-office
Same tree, plus a written ‘who authors which zone’ and a daily or issue-cycle freeze. Do not let two offices share a working DWG without a check-out rule.
A practical workflow
- Create the project tree before the first analysis file is saved.
- Publish the naming pattern and the ‘no FINAL’ rule.
- Assign authors and an issue copier.
- Work only in working folders.
- At issue, freeze natives and PDFs into a revision folder with a transmittal.
- Send from that folder. Do not send from working.
- Move superseded issue folders to archive; do not delete.
Engineering tips
- If a file is worth attaching to an email, it is worth putting in issue first.
- Keep a one-line project readme: path, naming, who issues. New staff should not have to ask around.
- Same job number on invoices, analysis, CAD and PDFs. Future searches depend on it.
- Backup is not archive. Backup restores disasters; archive answers ‘what did we send in March?’
Common mistakes
Working inside last issue’s folder
You will overwrite the record. Copy to working, then freeze a new issue.
Desktop copies ‘just for tonight’
Tonight becomes the live file. Tomorrow the server is stale. Work on the path or check out formally.
Transmittal without a file list
The receiver cannot confirm they have the set. List numbers and revisions.
Deleting superseded PDFs to ‘avoid confusion’
You will need them when a shop query quotes Rev B. Archive; do not delete.
Checklist
- Project tree exists before production starts
- Naming pattern written
- Working versus issue separated
- Authors and issue copier named
- Analysis and exports stored with the revision they fed
- Transmittal lists files and purpose
- Send is from issue, not working
- Superseded packs archived
Frequently asked questions
Do we need a formal EDMS?
Only when volume, audit or multi-office permissions outgrow a disciplined drive. Many structural teams never need a named system. All of them need working versus issued.
Where should LISP and Excel templates live?
In an office standards path, not inside a project. Projects may copy a version in; they should not each evolve a private dialect. See LISP Programs and Excel Programs.
How long do we keep native files?
At least as long as the contract and your liability period require, and at least as long as the shop might query a mark. PDFs without natives are a weak archive for a team that may have to revise.
What about BIM 360 / ACC / similar clouds?
They are still working versus issued. Permission the issued view, name the revision, and do not treat a live model as the pack you sent last Tuesday.
Where this leaves the work
Digital workflow for structural teams is a shallow tree, honest names, and a freeze you can point at when the shop calls. Tools sit inside that freeze. They cannot create it.
When the pack is an approval set, use the submission checklist. When the pack includes analysis-derived tables, keep the quality habit from MBS output checks even if the source is STAAD or another program: raw file, dated export, issued PDF, same revision.
This article provides general educational information. Project-specific structural design, calculations and drawings should be reviewed by appropriately qualified engineering professionals and checked against applicable project requirements and standards. StruTools does not replace engineering judgement or professional design review.