Workplace data integration is the practice of connecting your booking, badge, HRIS, sensor, and visitor systems so they share data instead of hoarding it. Done well, it gives you a single source of truth for how your space is actually used. Done poorly (or not at all), you end up with five dashboards that tell five different stories, and nobody trusts any of them.

Why workplace data integration matters

The average enterprise manages over 1,000 applications, with employees touching dozens of tools daily. Your workplace stack is a microcosm of that sprawl. You've got an HRIS for employee records, a calendar for meetings, a badge system for access, sensors for occupancy, and a visitor platform for guests. Each one generates useful data. None of them talk to each other by default.

That silence is expensive. Poor data quality costs organizations an average of $12.9 million per year. In workplace operations, the cost shows up differently: you're paying for space nobody uses, making lease decisions based on booking data that doesn't match actual attendance, and manually reconciling spreadsheets that should reconcile themselves.

The fix isn't buying more tools. It's connecting the ones you have. This guide walks through the five integrations that matter most, the architectural patterns behind them, and the decisions you'll need to make at each step. If you're at the planning stage of a workplace technology rollout, this is the plumbing blueprint.

The five must-have workplace integrations

Not every integration is equally urgent. Some are foundational (nothing works without them), and some are optimization layers you can add later. Here's the priority order, based on dependency chains:

1. HRIS → workplace platform (identity and permissions)
2. Calendar → booking system (room and desk scheduling)
3. Badge system → analytics (attendance ground truth)
4. Sensors → analytics (occupancy reality)
5. Visitor management → notifications (host alerts and audit trails)

Think of these as layers. Layer 1 (HRIS) is the foundation. Without knowing who your employees are, where they sit in the org chart, and which office they're assigned to, every other integration is guessing. Layer 2 (calendar) is where employees interact with the system daily. Layers 3 and 4 provide the ground truth that validates (or contradicts) what layers 1 and 2 say. Layer 5 handles the external-facing edge.

Let's walk through each one.

Integration #1: HRIS → workplace platform

Your HRIS is the master record. It knows who works for you, what team they're on, who their manager is, and which location they're assigned to. Every other workplace system needs some subset of that information.

What data flows:

• Employee name, email, department, manager
• Office location assignment
• Employment status (active, on leave, terminated)
• Cost center (useful for chargeback models)

How it flows:

The cleanest pattern is SCIM 2.0 provisioning. SCIM (System for Cross-domain Identity Management) is a standard protocol that automates user lifecycle management. When someone joins the company, SCIM creates their account in your workplace platform. When they transfer teams, SCIM updates their department. When they leave, SCIM deactivates them. No manual CSV uploads. No stale accounts lingering for months.

If your HRIS supports SCIM (most modern ones do: Workday, BambooHR, Rippling, HiBob), this integration is straightforward. If it doesn't, you'll need a middleware layer or a custom API integration that polls the HRIS on a schedule.

Direction: Push from HRIS to workplace platform. The HRIS is the source of truth; the workplace platform is the consumer.

Cadence: Near-real-time for new hires and terminations (you don't want a terminated employee retaining building access for 48 hours). Daily batch sync is acceptable for department changes and manager updates.

Build vs. buy: Buy. SCIM support is table stakes for any workplace platform worth evaluating. If you're writing a workplace technology RFP, SCIM 2.0 support should be a hard requirement, not a nice-to-have.

Integration #2: Calendar → booking system

Employees live in their calendars. Outlook, Google Calendar; that's where they schedule meetings, block focus time, and coordinate with colleagues. If your booking system doesn't sync with the calendar, you're asking people to manage their schedule in two places. They won't.

What data flows:

• Meeting invitations (time, attendees, room preference)
• Room availability status
• Booking confirmations and cancellations
• Desk reservations (synced as calendar events for visibility)

How it flows:

Calendar integration is bidirectional. When an employee books a room through the workplace platform, it creates a calendar event. When they schedule a meeting in Outlook and select a room, the workplace platform registers the reservation. Both systems need to stay in sync, which means this integration must be real-time.

Why webhooks, not polling:

Calendar changes happen constantly. Someone moves a meeting from 2pm to 3pm. Someone cancels. Someone adds a room. If your integration polls the calendar API every 15 minutes, you'll have 15 minutes of stale data where the floor map shows a room as booked when it's actually free (or vice versa). Webhooks push changes the moment they happen. For calendar sync, webhooks are the better choice because even minutes of latency create real friction.

The ghost booking problem:

Calendar sync alone doesn't solve ghost bookings, where someone books a room and never shows up. That's where integration #3 (badge data) comes in. But calendar sync gives you the baseline: what was intended. Badge data gives you what actually happened. The gap between the two is where your optimization opportunities live.

Build vs. buy: Buy. Both Microsoft Graph API and Google Calendar API are well-documented and stable. Any mature workplace platform handles this natively. If you're evaluating tools, check whether the integration supports AI-powered room scheduling features like auto-release of no-show bookings.

Integration #3: Badge system → occupancy analytics

Badge swipes are the closest thing you have to attendance ground truth. They tell you who entered the building, when, and (depending on your system) which floor or zone they accessed. This is the data that validates or contradicts your booking data.

What data flows:

• Badge-in and badge-out timestamps
• Employee identifier (mapped to HRIS record)
• Entry point (building, floor, zone)
• Access denials (useful for security audits)

How it flows:

Most modern access control systems (Brivo, Verkada, Genetec) expose APIs that your workplace platform can pull from. The typical pattern is a batch pull: every 15 to 60 minutes, the workplace platform queries the badge system for new swipe events and ingests them into the analytics layer.

Real-time isn't strictly necessary here. You're not using badge data to make instant decisions (that's what the badge system itself does at the turnstile). You're using it for analytics: who actually showed up today, what's the peak arrival time, which floors are busiest. A 15-minute delay is fine for those use cases.

The reconciliation challenge:

Here's where it gets interesting. Your booking system says 200 desks were reserved today. Your badge system says 180 people entered the building. Your sensors (integration #4) say 160 desks were actually occupied at peak. Which number do you report to leadership?

All three. But you need a reconciliation layer that explains the gaps. Twenty people booked but didn't badge in (no-shows or worked from home). Twenty people badged in but weren't at their desks at peak (in meetings, at the café, roaming). This reconciliation is the core value of workplace analytics, and it's impossible without integrating badge data.

If you're running Brivo specifically, Gable's Brivo integration combines badging and room booking data into a single view.

Build vs. buy: Mixed. If your badge vendor has a well-documented API and your workplace platform supports it natively, buy. If you're running a legacy access control system with no API, you may need a custom middleware layer that reads badge logs from a database or file export. Budget 4 to 8 weeks of engineering time for legacy systems.

Integration #4: Occupancy sensors → workplace analytics

Sensors measure what's actually happening in your space, independent of what anyone booked or badged. They count bodies in rooms, detect whether desks are occupied, and track utilization patterns across zones. They're the most objective data source you have.

What data flows:

• Real-time or near-real-time occupancy counts (per room, per zone, per floor)
• Desk occupancy status (occupied/vacant)
• Historical utilization patterns (hourly, daily, weekly)
• Environmental data (some sensors also capture temperature, noise, CO2)

How it flows:

Sensor vendors typically expose REST APIs that deliver occupancy data in JSON format. The integration pattern depends on your use case:

• Real-time feed (webhooks or streaming): For auto-releasing unused meeting rooms. If a room is booked but sensors detect zero occupancy after 10 minutes, the system releases the room back to the pool.
• Batch pull (polling every 5 to 15 minutes): For dashboard updates and utilization reporting. This is the more common pattern and puts less load on both systems.
• Historical export (daily or weekly): For trend analysis, space planning, and lease decisions.

Privacy by design:

Sensors count; they don't identify. A well-designed sensor integration ingests aggregate occupancy numbers (3 people in Room 4B), not individual identities. This is a critical distinction for workplace data privacy compliance. If your sensor vendor's API returns personally identifiable information, that's a red flag.

For a deeper dive on sensor selection and deployment, the smart office sensors guide covers the hardware side of this equation.

Build vs. buy: Usually buy. Sensor vendors have invested heavily in their APIs because the data is only valuable when it flows somewhere else. The integration is typically straightforward: authenticate, subscribe to a data feed, map sensor zones to your floor plan. Custom builds are only necessary when you're aggregating data from multiple sensor vendors into a single analytics layer.

Integration #5: Visitor management → notifications

When a visitor checks in at the lobby, their host needs to know. Immediately. Not via a phone call from the front desk. Not via an email that sits unread for 20 minutes. Via a Slack message, a Teams notification, or a push alert that says "Your 2pm guest has arrived."

What data flows:

• Visitor pre-registration details (name, company, host, purpose of visit)
• Check-in timestamp and method (QR code, kiosk, front desk)
• Host notification trigger
• Badge issuance (temporary access credentials)
• Check-out timestamp
• Visitor data retention and deletion schedules

How it flows:

This is a classic event-driven integration. The visitor checks in (event). The visitor management system fires a webhook. The webhook triggers a notification in Slack, Teams, or email. The host confirms. Optionally, the system also triggers a temporary badge credential in the access control system.

The notification leg is simple: a webhook to Slack's or Teams' incoming webhook URL. The badge credential leg is more complex and depends on your access control vendor's API capabilities.

Cadence: Real-time only. There's no batch use case for visitor notifications. If your visitor system doesn't support webhooks for check-in events, it's not ready for integration.

Build vs. buy: Buy for the notification flow (it's a solved problem). Consider building if you need custom logic, like routing different visitor types to different notification channels, or triggering different badge access levels based on visitor category.

Integration patterns: Real-time vs. batch, push vs. pull

Now that you know what to integrate, let's talk about how. Every integration follows one of a few architectural patterns. Choosing the right one for each data flow saves you engineering time and prevents performance headaches.

Real-time (webhooks):

Best for: calendar changes, visitor check-ins, booking confirmations, room auto-release.

How it works: the source system sends an HTTP POST to your endpoint whenever an event occurs. No polling, no delay.

Trade-off: you need to build and maintain a webhook receiver, handle retries for failed deliveries, and manage webhook secret rotation.

Batch (scheduled polling):

Best for: badge swipe ingestion, sensor utilization reports, HRIS sync for non-urgent changes.

How it works: your system calls the source API on a schedule (every 15 minutes, hourly, daily) and pulls new records since the last sync.

Trade-off: simpler to implement, but you accept latency. A 15-minute polling interval means up to 15 minutes of stale data.

Push (API push from your system):

Best for: sending booking data to wayfinding displays, pushing utilization reports to BI tools, syncing desk assignments to digital signage.

How it works: your workplace platform calls an external API to push data outward.

Trade-off: you own the delivery logic, including retries and error handling.

Pull (external systems query your API):

Best for: BI tools (Tableau, Power BI, Looker) pulling utilization data, finance systems pulling chargeback data, HRIS pulling attendance summaries.

How it works: external systems call your workplace platform's API on their own schedule.

Trade-off: you need a well-documented, stable API with proper authentication and rate limiting.

A practical mapping:

Authentication and identity: SSO, SCIM, and OAuth

Identity is the foundation layer. If you get this wrong, every other integration inherits the problem.

SSO (Single Sign-On):

Employees should authenticate to your workplace platform using the same credentials they use for everything else. That means SSO via your identity provider (Okta, Azure AD, Google Workspace). No separate username and password. No "forgot password" flows for a desk booking tool.

SSO isn't just a convenience feature. It's a security requirement. When someone leaves the company and their IdP account is deactivated, their access to the workplace platform should terminate automatically. Without SSO, you're relying on manual deprovisioning, which means former employees retain access until someone remembers to revoke it.

SCIM 2.0 provisioning:

SSO handles authentication (proving who you are). SCIM handles provisioning (creating and managing your account). They're complementary.

With SCIM, your IdP automatically creates user accounts in the workplace platform when employees join, updates them when roles change, and deactivates them when employees leave. The SCIM 2.0 specification defines a standard schema for user objects (name, email, groups, active status) and a standard API for CRUD operations.

When evaluating workplace platforms, ask: "Do you support SCIM 2.0 for automated user provisioning?" If the answer is no, you'll be managing user accounts manually or building a custom sync. Neither is a good use of your team's time.

OAuth 2.0 for API-to-API communication:

When your workplace platform talks to the calendar API, the badge system API, or the sensor API, it needs to authenticate. OAuth 2.0 is the standard. Specifically, the client credentials grant (for server-to-server communication) and the authorization code grant (for user-delegated access, like reading someone's calendar).

Best practices:

• Use short-lived access tokens (1 hour or less) with refresh tokens
• Scope tokens to the minimum permissions needed (least privilege)
• Rotate client secrets on a regular schedule
• Store tokens in a secrets manager, not in environment variables or code

Data quality and reconciliation

You now have data flowing from five systems. The hard part isn't getting the data; it's making it agree.

The three-source problem:

Your booking system says 200 desks were reserved on Tuesday. Your badge system says 175 people entered the building. Your sensors say 155 desks were occupied at peak. Which number is "right"?

They all are, for different questions:

• Booked (200): How much demand did employees express?
• Badged (175): How many people physically entered the building?
• Sensed (155): How many desks were actually used at peak?

The gaps between these numbers are where the insights live:

• 200 booked minus 175 badged = 25 no-shows (people who booked but didn't come in)
• 175 badged minus 155 sensed at peak = 20 people who were in the building but not at a desk (in meetings, common areas, or left early)

Reconciliation strategies:

1. Establish a hierarchy of trust. Badge data is more reliable than booking data for attendance. Sensor data is more reliable than badge data for space utilization. Booking data is most reliable for demand forecasting.
2. Normalize timestamps. Badge systems, sensors, and booking platforms may use different time zones or timestamp formats. Normalize everything to UTC before comparing.
3. Define matching rules. An employee's badge swipe at 9:03am and their desk booking starting at 9:00am are the same event. Define a tolerance window (e.g., plus or minus 30 minutes) for matching badge events to bookings.
4. Flag anomalies, don't auto-correct. If someone badged in but has no booking, flag it for review rather than auto-creating a booking. The goal is visibility, not automation of assumptions.
5. Report all three numbers. When you build your office utilization report, show booked, badged, and sensed side by side. Leadership needs to understand the difference, not receive a single blended number that hides the gaps.

Build vs. buy at each integration point

The build-vs-buy decision is different for each integration. Here's a practical framework.

HRIS integration: Buy.

SCIM is a standard. Any workplace platform that doesn't support it natively is asking you to build something that should be a checkbox. If you're evaluating platforms, this is a disqualifier.

Calendar sync: Buy.

Microsoft Graph API and Google Calendar API are mature, well-documented, and stable. The bidirectional sync logic is complex (conflict resolution, recurring events, timezone handling). Don't build this unless you have a very unusual calendar setup.

Badge integration: Buy if possible, build for legacy.

Modern access control vendors (Brivo, Verkada, Genetec) have APIs. If your workplace platform supports your badge vendor natively, use the native integration. If you're running a legacy system with no API, you may need to build a middleware layer that reads badge logs from a database export or flat file. This is the most common "build" scenario in workplace integration projects.

Sensor integration: Buy.

Sensor vendors design their products to export data. The APIs are typically clean and well-documented. The main complexity is mapping sensor zones to your floor plan, which is a configuration task, not a development task.

Visitor → notification: Buy.

Slack and Teams both support incoming webhooks. The visitor check-in event triggers a webhook. Done. If you need complex routing logic (different visitor types go to different channels), a lightweight automation tool (Zapier, Make, or a simple Lambda function) handles it.

For a more detailed framework on the build vs. buy decision, including cost modeling and vendor evaluation criteria, we've published a dedicated guide.

A rough cost comparison:

The math is straightforward. If your workplace platform handles four of these five integrations natively, you're saving 15 to 25 weeks of engineering time. At a fully loaded engineering cost of $150 to $200 per hour, that's $90,000 to $200,000 in avoided build cost. And that's before you account for ongoing maintenance, which typically runs 15 to 20% of initial build cost per year.

Phasing your integration rollout

You don't need to do all five integrations at once. In fact, you shouldn't. Here's a phased approach that manages risk and delivers value incrementally.

Phase 1 (weeks 1-4): Identity and calendar.

Stand up SSO and SCIM provisioning. Get calendar sync working. These two integrations cover the daily employee experience: logging in and booking space. They're also the foundation for everything else.

Phase 2 (weeks 5-8): Badge integration.

Connect your access control system. Start comparing badge data to booking data. This is where you'll first see the gap between intended and actual attendance, and it's the data that justifies (or challenges) your current space allocation.

Phase 3 (weeks 9-12): Sensors and visitor management.

Layer in sensor data for granular utilization insights. Connect visitor check-in to host notifications. These are optimization layers that build on the foundation you've already established.

Phase 4 (ongoing): Reconciliation and reporting.

Build your reconciliation logic. Create dashboards that show booked vs. badged vs. sensed. Start using the integrated data for space planning decisions.

Each phase should include a validation step: does the data flowing through the integration match what you'd expect? Spot-check a sample of records manually before trusting the automated flow.

What good looks like after integration

When all five integrations are running, your workplace data tells a coherent story. Here's what changes:

Before integration: You know 200 desks were booked on Tuesday. You think the office was busy. You're not sure whether to add more desks or reduce your footprint.

After integration: You know 200 desks were booked, 175 people badged in, and sensors detected peak occupancy of 155 desks at 11am. You know that Tuesdays and Wednesdays are your peak days, that the east wing is consistently underutilized, and that meeting rooms on the 3rd floor are double-booked 30% of the time while rooms on the 5th floor sit empty.

That's the difference between data and intelligence. The integrations provide the data. The reconciliation provides the intelligence. And the intelligence drives decisions: consolidate the east wing, add bookable rooms on the 3rd floor, convert 5th floor meeting rooms to focus pods.

Workplace analytics only works when the underlying data is connected. Without integration, you're making million-dollar real estate decisions based on partial information.

The bottom line on workplace data integration

Workplace data integration isn't a technology project. It's an infrastructure decision that determines whether your workplace team operates on facts or assumptions. The five integrations covered here, HRIS, calendar, badge, sensor, and visitor, form a complete picture of how your space is used. Skip any one of them and you've got a blind spot.

Start with identity and calendar. Layer in badge and sensor data. Connect visitor management last. Use webhooks where latency matters and batch sync where it doesn't. Reconcile the three sources of truth (booked, badged, sensed) instead of picking one and ignoring the others.

The companies that get this right don't just save money on real estate. They make faster, more confident decisions about where to invest in space and where to pull back. That's the payoff.