Here's a scene every superintendent knows. You update the three-week look-ahead in one system on Monday morning. Then payroll wants hours coded by activity, so someone re-keys the same crew assignments into the time app. The PM pulls labor into the accounting system by hand for the pay app. By Wednesday the three copies disagree, and nobody's sure which one the owner is looking at. That gap between systems is where jobs quietly bleed hours.
Integration is the fix, but it's also where a lot of tech dollars go to die. The goal isn't a slick diagram of everything connected to everything. It's practical: enter a piece of information once, and have it show up correctly everywhere it's needed. Below is how the connections actually work on a real project, where they break, and which ones are worth chasing first.
Why This Is Worth Doing (and Where the Hype Oversells It)
The honest case for integration is boring and real: you kill double-entry, and you cut the arguments about whose number is right. When your crew assignments, hours, and cost codes come from a single source, the field, the office, and the owner are finally reading the same page.
The dishonest case is "one connected ecosystem where all your data flows seamlessly." In practice, every connection you add is another thing that can break at 6 a.m. when payroll is due. A dead integration that silently stops syncing is worse than no integration, because people trust it and stop checking. So the rule of thumb: connect the handful of systems where re-entry actually hurts, and leave the rest alone until they earn their place.
The Master Schedule Connection — Handle With Care
The link people ask about first is tying the weekly and three- or four-week look-ahead back to the master CPM schedule in Primavera P6 or MS Project. It sounds obvious. It's the one I'd tell you to be most careful with.
The look-ahead and the master schedule are two different tools doing two different jobs. The master schedule is the contractual, logic-driven backbone — hundreds or thousands of activities, critical path, float. The look-ahead is the field's promise for what actually gets done in the next few weeks, broken down by location and crew at a resolution the master schedule never has. One master activity like "Level 3 rough-in" might be fifteen rows on your weekly work plan, split by wing and by trade.
That's why full two-way sync between them is a trap for most teams. If every field tweak writes back into the CPM, you'll corrupt the logic and float that your delay claims depend on, and your scheduler will hate you. What you actually want is a controlled relationship:
- One-way, master-to-look-ahead: pull the current master activities and dates in as the boundaries your weekly plan has to live inside. The field plans freely below that ceiling.
- Roll actual progress up on a cadence: feed percent-complete and start/finish actuals back to the scheduler on a weekly statusing rhythm, not live. The scheduler reviews it and updates the CPM deliberately.
Keep a clean mapping so each look-ahead row knows its parent master activity ID. That's what lets you answer "is what the crews are doing this week actually moving the critical path?" — which is the whole point. A look-ahead tool built for the field, like LookAheadWall, is meant to sit at this resolution below the master schedule rather than replace it; the master stays the system of record for contract dates, and the weekly plan stays the system of record for what the crews are really doing.
Time, Labor, and the Cost-Code Problem
The integration that pays for itself fastest is scheduling to time tracking. When a crew's assignment for the day already carries the activity and the cost code, the foreman's time entry inherits it. You get hours captured at the activity level instead of a lump daily total, and that's the difference between knowing "we burned 40 hours yesterday" and knowing "we burned 40 hours and 28 of them went to a change-order area nobody's billing for yet."
Here's the catch that sinks these projects: the cost codes have to line up. Your scheduling tool, your time app, and your accounting/job-cost system each have their own list of codes, and if they don't match exactly, the sync either fails or — worse — posts hours to the wrong code and looks fine. I've watched a job carry a healthy labor budget on paper for a month because framing hours were landing on a drywall code. Nobody noticed until the drywall sub's actuals came in at triple the estimate.
Before you wire anything together, do the unglamorous work: sit down with the office and reconcile one master list of cost codes, crew names, and subcontractor names across all three systems. Same spelling, same numbers, same structure. That data-mapping session is 80% of what makes a labor integration succeed, and it's the step everyone wants to skip.
Financials — Feed It, Don't Let It Drive
Once labor flows cleanly, connecting to job costing and pay applications gets much easier because it's riding on the same coded data. Progress from the field supports the monthly pay app, and earned-value comparisons against budget start to mean something instead of being a spreadsheet somebody backfilled the night before the owner meeting.
Two guardrails. First, keep the direction of trust clear: the field schedule and time data feed the financial system, not the other way around. Accounting is the system of record for money; scheduling is the system of record for work. Second, don't try to make your look-ahead tool into an accounting package. If a vendor is pitching you full job-costing built into the scheduling app, be skeptical — that's rarely where their strength is, and you'll end up fighting two half-good tools instead of connecting two good ones.
Documents, RFIs, and Safety
These are the "nice when it's there" connections. Linking an activity to the relevant drawing, spec section, or open RFI means the foreman planning next week's work can see that the detail he needs is still stuck in an unanswered RFI — before he schedules the crew and finds out at 7 a.m. that they can't proceed. That's a real save. But it's a convenience layer, not the backbone, and I wouldn't hold up a rollout waiting for it.
Safety integration is the one worth a little more effort. Tying the schedule to certification tracking so the system flags when you've assigned a crew member to work that needs a cert he doesn't have — hot work, confined space, a specific lift — catches a genuine failure mode before it becomes an incident or a stop-work. Linking incidents back to the scheduled activity where they happened also gives you honest data on which operations actually hurt people, which is more useful than any generic safety dashboard.
How the Plumbing Actually Connects
You'll run into three approaches, and it's worth knowing what you're signing up for with each:
- Pre-built connectors. The vendor already built and maintains the link to a specific system (a common ERP, a payroll provider, P6). When one exists for the systems you run, take it — it's the least effort and the vendor keeps it alive through version changes. The catch is you get what they built; if your fields don't fit their mapping, you're stuck.
- API integration. A modern scheduling tool should expose a documented REST API so your team (or a developer) can build a custom connection. This is the flexible path. Before you count on it, actually look at the API docs and check the rate limits — an API capped at a few hundred calls an hour can't support the "real-time" sync the salesperson promised across a thousand-activity job.
- Middleware. Platforms like Zapier or a custom integration layer sit between systems that don't talk directly. Fine for lower-volume, non-critical flows. For anything payroll-grade, understand that you've now got a third party in the critical path who also has to stay up.
Real-Time Isn't Always the Goal
Everyone asks for real-time sync. For a lot of construction data you don't want it. A nightly or hourly batch sync is often more reliable and more forgiving — if a batch fails, you see the error and re-run it before anyone downstream is affected. A real-time sync that fails mid-write can leave two systems disagreeing with no obvious sign.
Match the timing to the need. Cost codes and crew rosters change rarely — sync them daily. Time entries need to land before payroll cutoff — daily batch is plenty. Live schedule status for a shared field view — that's a fair case for real-time. Don't pay the complexity cost of real-time where a batch does the job.
Plan for the Day It Breaks
Every integration fails eventually — an API changes, a password expires, a vendor pushes an update. What separates a minor annoyance from a bad week is whether you planned for it:
- Loud failures. The sync must alert a real person when it breaks. Silent failure is the enemy — that's how you discover in week three that nothing has synced since week one.
- A manual path. You must be able to enter the data by hand when the connection is down. If the integration is the only way information moves, an outage stops the job.
- Retry logic. Transient hiccups should retry on their own so a two-minute network blip doesn't require a human.
- Owned by a name. Someone is responsible for integration health, and it gets re-checked whenever any connected system updates. "Everybody's job" means nobody's.
What to Ask a Vendor Before You Buy
Evaluate integration capability before you sign, not after. Get specific answers, not marketing:
- Is there a documented REST API, and can I see the docs and rate limits now?
- Do you have a pre-built connector for the exact systems I run — my payroll provider, my accounting package, P6 or MS Project — or just "we integrate with ERPs" in general?
- Show me a project like mine where this was integrated and what it took to stand up.
- When the connected system updates its version, who fixes the integration, and how fast?
- What happens, concretely, when a sync fails?
Do It in the Right Order
You don't connect everything at once, and you don't connect everything at all. Rank by pain: whatever you're re-keying most, and whatever errors cost you real money, goes first. For most jobs that's schedule-to-time and time-to-cost, because that's where hours leak. Get one integration working, prove it in production, then add the next. Test every connection against real data before you trust it live — push a full week's hours through and reconcile them by hand once, so you catch the cost-code mismatch before it hides for a month.
Done this way, integration stops being a buzzword and becomes what it should be: you plan the week once, and the hours, the costs, and the master schedule all stay honest without anyone re-typing a thing. That's a few hours a week back for your foremen and one less source of the "whose number is right" argument that eats project meetings. Connect the flows that hurt, ignore the ones that don't, and keep a person watching the ones you rely on.