Field operations

Field operations is the set of registers that carry the daily record of a job: requests for information, submittals, transmittals, observations, punch, inspections, daily logs, photos, safety, meetings, schedule, and reports.

Every one of them is scoped to the current project. Switching projects switches the register; nothing here reads across a portfolio.

The pages below cover each register in turn. The rest of this page covers the conventions they share, so the other pages do not repeat them.

The registers

Register	What it is for
RFIs	Ask a question formally, route it, and record the answer that counts
Submittals	Route product data and shop drawings through a review chain to a disposition
Transmittals	Issue documents to an outside party with a cover sheet and a record of who got it
Observations	Log what you saw on a walk, then tell the team about it as a separate act
Punch list	Track corrective work through assignee, manager, and final approver
Inspections	Run a checklist, capture signatures, and promote failures into punch or observations
Daily logs	Record what happened on site each day
Photos	Site photography, albums, and share links
Safety	Incidents and toolbox talks
Meetings	Agendas, minutes, business items, and attendance
Schedule	Activities, dependencies, and the look-ahead board
Reports	Canned exports across the modules above

Ball-in-court

Most of these registers show a Ball-in-court column. It answers one question: whose move is it right now.

Ball-in-court is derived from the record's state and its participants every time the record is read. It is not a field anybody sets, and there is no way to hand somebody the ball without making the state change that puts it there. That is why it cannot drift: change the assignees on a punch item and the ball moves with them, because it was never stored in the first place.

Each register documents its own rule. As a shape, the ball sits with the person being asked to act, and returns to the manager or reviewer once they have acted.

Logging something and telling people are separate acts

Two registers deliberately split creation from distribution:

• An observation is created unsent. Nobody is notified until you send it, and the register shows a Date Notified column that reads Not sent rather than sitting blank.
• A punch item created without issuing it sits in Draft. Drafts notify nobody. Issuing it is a separate action.
• A transmittal is composed first and sent second, through a different endpoint with a higher permission level.

This is the point of those modules, not an oversight. You can walk a site logging items on a phone and review them once from a desk, instead of firing half-written notices from the middle of a walk-through.

What a send actually records

Where a register sends something to people, it records a per-recipient outcome rather than one success flag for the whole action. Transmittals expose all five values directly:

Outcome	What the record says
Not sent yet	Composed, no attempt made
Sent	The mail transport accepted it
Email is disabled in this environment	Nothing was sent, and nothing will be
Failed	The transport refused it
No email on file	That contact has no address in the project directory

Two of those are worth reading carefully. The disabled outcome means no message was attempted, and the record says so instead of showing a green success state. The no-email outcome is reported rather than skipped, because "it went to the whole distribution" is false if one recipient was silently dropped.

Elsewhere, distribution writes an in-app notification to each recipient. A send that reached nobody is reported as a failure and the record stays undistributed: observations, for example, will not stamp Date Notified unless at least one person actually holds the notification.

Email delivery is controlled separately from the in-app notification, and is off unless the environment enables it. Check the recorded outcome on the record rather than assuming a message left the building.

Private records return "not found"

Several registers carry a Private flag: RFIs, submittals, observations, punch items, inspections, and meetings. A private record is visible to tool admins and to the record's own participants (creator, manager, assignees, distribution, and the final approver or point of contact where those exist).

To everyone else, the API answers 404 Not found, not 403. That is deliberate: a 403 would confirm a record with that id exists on the project, which is exactly what the flag exists to withhold.

The practical consequence: a colleague who sends you a link to a private record you are not on will hear that the link is broken. It is not. Ask to be added to the record's distribution, or ask an admin to open it.

RFIs add a second, narrower rule. A project setting called "Only show official response to Standard and Read Only users" is on by default, so a non-privileged viewer sees only the replies marked official. The record says the thread was narrowed rather than quietly showing a short one.

Empty tables never guess

Six of these registers implement the same rule for an empty table. There are five distinct states and each one says something different:

1. Loading. A skeleton, never an empty table.
2. Genuinely empty. This project has no records of this kind.
3. Filtered to none. Records exist; your filters excluded all of them.
4. Truncated. The read hit the register's ceiling, so the list is not the whole project. A truncated list never prints the definitive "this project has none" sentence, and the readout says the list stopped at the limit.
5. Cannot be read. The storage behind the register did not answer, so the register says so instead of rendering zero rows.

The last one matters most on a correspondence log. A register that printed "No transmittals" while the server could not read them would be asserting that nothing was ever issued on the job, which is exactly the claim somebody later disputes.

Filters and sorting say what they can do

Register filters come in two scopes. Server filters become query parameters and narrow the whole project before pagination. Client filters have no endpoint parameter and can only narrow rows already loaded. Whenever a client filter is active and pages remain unloaded, the readout says so rather than implying a complete result.

Sorting follows the same rule. Each register can order only a handful of its columns on the server (five on observations, three on RFIs) and re-queries from page one when you sort by one of those. Any other column sorts the rows already loaded, and the register tells you that is what happened. Do not treat a sort on a partially loaded register as a project-wide ranking.

Native projects and Autodesk-linked projects

A project with no Autodesk link is native: records are written to Struxen and Struxen is the system of record.

A project linked to Autodesk Construction Cloud mirrors from Autodesk, and two registers branch on that link:

• RFIs. On a linked project, creating an RFI creates it in ACC on your behalf using your own Autodesk connection, then mirrors the result locally. Attachments are refused on that path with a message telling you to attach the file to the RFI in ACC instead.
• Observations. Same shape: a linked project creates the issue in ACC and mirrors it; a native project writes to Struxen and gets the full observation lifecycle, taxonomy, and send mechanic.

Submittals, transmittals, punch, and inspections are Struxen-native on every project. There is no Autodesk branch in those modules.

Edits never push back to Autodesk. See Integrations for what the link does and does not do.

Permissions

Access is per tool, at four levels: NONE, READ_ONLY, STANDARD, ADMIN. Each page below names the level an action needs. Two are worth knowing up front because they are not where you would guess:

• Transmittals borrow the Documents tool. Reading needs READ_ONLY on Documents; composing and sending need STANDARD. Listing a submittal on a transmittal additionally needs READ_ONLY on Submittals.
• Safety borrows the Observations tool.

STANDARD means "act on the records you participate in", not "moderate other people's records". Editing somebody else's record generally needs ADMIN.

See Permissions for the full model.

Exports

The RFI, submittal, and punch logs each export as PDF or CSV, and the export applies the same filters the register is showing, so "export what I am looking at" is literally true. Submittals and punch export from their own register header; the RFI log exports from Reports. Ask for any other format and the request is refused with a message rather than quietly returning a PDF.

An export that hits the read ceiling is served short and stamped: a warning band on page one of the PDF, and a trailing note in the CSV. A partial log forwarded to an owner as though it were complete is the failure mode those stamps exist to prevent.

Individual records export as PDF on RFIs, transmittals (the cover sheet), and inspections.

Each register enforces its own caps on rows, attachments, and comments. Every page below lists its own; Limits collects them in one place.

AI actions cost credits

A few field actions run a model: drafting an observation from a photo, describing a punch item from a photo, summarizing an inspection's deficiencies, and the AI pre-review step on a submittal. Each is metered against the project's credits and appears on the project's credit usage. Everything else in these registers, including every read, every status change, and every export, costs nothing.

With a zero balance the AI actions are blocked and the rest of the registers keep working normally.

Demo projects are read only

On the demo project every create, transition, and send control is disabled and labelled. You can browse, filter, open records, and export.