Daily Work Record Automation

Daily workforce reporting required the same source information to be reconciled into a workbook and then entered in Procore. Personnel rules and reporting dates made it more than a copying task. I built and operate a workflow that turns those decisions into a repeatable reporting process.

One reporting model, two outputs

A connected workforce workbook and an approved journal feed an Excel builder through Power Query. The model applies personnel and location rules before producing the report layout and Procore queue. A visible review surface lets me inspect the result before publication.

The saved upstream workbook must be refreshed before the builder. The source's business-date cutoff is distinct from the date the report describes. Keeping those concepts separate prevents a fresh-looking workbook from producing the wrong day's record.

Guard the daily run

The PowerShell launcher checks source freshness and reconciled workforce totals. It stages and validates the workbook and JSON queue before publishing the output set. Run state advances only after all required outputs have been published.

The queue contains only explicitly requested reporting dates. Source fingerprints help identify stale or unchanged input. These controls make a failed refresh visible before it becomes an official reporting artifact.

Carry approved values into Procore

The Edge extension, ProCore Genie, reads the generated queue and enters manpower values through the authenticated browser interface. It does not infer missing dates or invent reporting values. Comments remain within the destination's length limit.

A create action is attempted once. If its result is uncertain, the workflow requires verification before continuing rather than repeating an action that could create a duplicate. The final workbook attachment remains a manual step.

Operating scope

This is a tool I operate as part of my paid OEG responsibilities. It is not an organization-wide deployment. Recent output-layout refinements still require a final full-launcher verification; they do not change the established reporting model.

What this demonstrates

• Translation of operational reporting rules into an inspectable data model
• Excel and Power Query integration with PowerShell output control
• Browser automation constrained by approved data and explicit dates
• Failure handling that protects records and avoids duplicate entry