Skip to main content

Doorflow Access Control Integration

Overview

Doorflow is a cloud-based access control platform that enables flexible, secure physical access management for modern workspaces. The Nexudus integration with Doorflow automates credential provisioning and access group assignments based on customer contracts, passes, bookings, and desk assignments.

Key Features

  • Cloud-based management: Manage access from anywhere through Doorflow’s web platform
  • Automatic provisioning: Access is granted and revoked automatically based on plan changes, bookings, and pass assignments
  • Check-in tracking: Optionally use door events to check customers in/out
  • RFID card support: Physical access cards with PIN code support
  • Group-based permissions: Map your inventory (passes, resources, desks) to Doorflow groups
  • Booking-based temporary access: Automatic access during reservation windows
  • Multi-site support: Manage access across multiple physical locations

Integration Type

Cloud-based — Doorflow operates entirely in the cloud with no on-premises server requirements. API endpoints are hosted at api.doorflow.com.

Capabilities

FeatureSupportedNotes
Pass-based access✅ YesCustomers receive access based on their active passes
Plan-based access✅ IndirectPlans grant access through the passes they include
Resource-based access✅ YesGrants temporary access during reservations
Desk/unit-based access✅ YesIncludes support for team billing contracts
Visitor access❌ NoNot supported by this integration
Booking guest access✅ YesCustomers added as booking guests can access spaces during booking windows
Check-in tracking✅ YesDoor events trigger automatic check-ins
Mobile app access❌ NoPhysical cards/PIN codes required for access
Remote door unlock❌ NoUnlike cloud systems like ACT365, Doorflow requires physical credentials

How It Works

Access Control Model

Doorflow uses a group-based model to manage access permissions:
  • People represent individuals in the system (mapped to Nexudus customers)
  • Groups define collections of doors that people can access
  • Sites organize door controllers within your Doorflow account
  • Controllers manage individual doors or access points
  • Tokens are physical RFID cards assigned to people
When a customer’s access needs change in Nexudus (e.g., they purchase a pass, book a resource, or their contract renews), the integration automatically updates their person record in Doorflow with the appropriate group memberships.

Multi-Door Support

Doorflow uses groups to grant permissions to multiple doors. Instead of mapping each door individually:
  1. In Doorflow, create a group (e.g., “24/7 Access”)
  2. Add the relevant doors to that group in Doorflow
  3. In Nexudus, map your pass/resource/desk to that group
  4. Customers with that pass automatically get access to all doors in the group
You must configure which doors belong to each group in the Doorflow platform. Nexudus assigns customers to groups, but the door-to-group mapping is managed in Doorflow.

Prerequisites

Before connecting Nexudus to Doorflow, ensure you have:
  1. Active Doorflow account with administrator access
  2. OAuth2 credentials from Doorflow (obtained during connection process)
  3. Doorflow system configured with door controllers installed and online
  4. Groups created in Doorflow for different access levels (e.g., 24/7 access, business hours only)
  5. Nexudus location configured with plans, passes, and resources
Doorflow uses OAuth2 for secure authentication. When you connect the integration, you’ll be redirected to Doorflow to authorize access. No manual API key entry is required.

Configuration

Step 1: Connect to Doorflow

  1. In the Nexudus dashboard, go to Settings > Integrations
  2. Find Doorflow in the list and click Connect
  3. You’ll be redirected to the Doorflow authorization page
  4. Sign in with your Doorflow administrator credentials
  5. Review the permissions requested by Nexudus:
    • Read account and person information
    • Manage people (create, update, delete)
    • Read events for check-in tracking
    • Read sites and controllers
  6. Click Authorize to grant access
  7. You’ll be redirected back to Nexudus with the connection established
Once connected, Nexudus can read your Doorflow sites, door controllers, and groups.
The OAuth2 connection uses secure tokens that are automatically refreshed. You won’t need to re-authorize unless you explicitly disconnect the integration or revoke access in Doorflow.

Step 2: Select Site for Check-in Tracking

If you want door events to trigger automatic check-ins, select which Doorflow site to monitor:
  1. In the Check in customers at dropdown, select the Doorflow site
  2. Leave blank if you don’t want automatic check-ins from door events
  3. If you have multiple sites, you can only track check-ins for one site at a time
Check-in tracking requires event processing. Nexudus syncs door events every 12 minutes and triggers the appropriate check-in action based on your controller configuration.

Step 3: Select Site for Configuration

Before mapping passes, resources, and desks, you must select which Doorflow site to configure:
  1. In the Doorflow site dropdown, select your site
  2. Once selected, the configuration panels for controllers, resources, passes, and desks will load
This step is necessary because Doorflow accounts can manage multiple sites, and each site has its own controllers and groups.

Step 4: Configure Presence Tracking (Optional)

Doorflow can trigger automatic check-ins when customers unlock specific doors.
  1. In the Presence tracking section, you’ll see all door controllers from your selected site
  2. For each controller, choose an action:
    • Nothing: Door access is tracked in Doorflow but doesn’t affect Nexudus
    • Check In: Unlocking this door checks the customer in
    • Check Out: Unlocking this door checks the customer out
    • Toggle: Unlocking switches between checked in and checked out
Common scenarios:
  • Set the main entrance to Check In
  • Set the exit door to Check Out
  • Set internal doors to Nothing (access granted but doesn’t affect presence)
Check-in tracking requires event processing. Nexudus syncs door events every 12 minutes. There may be a delay between a door unlock and the check-in appearing in Nexudus.

Step 5: Map Passes to Groups

Passes are the primary way customers receive access in Nexudus. Each pass can be mapped to a Doorflow group.
  1. In the Passes section, you’ll see all passes configured for this location
  2. For each pass, select the Doorflow access group from the dropdown
    • The dropdown shows all groups available in your Doorflow site
    • Leave blank if a pass should not grant physical access
How it works:
  • When a customer has an active contract on a plan that includes passes, they automatically receive those passes
  • If the pass is mapped to a Doorflow group, the customer is added to that group
  • When the pass expires or is consumed, access is revoked
  • Time-limited passes (e.g., day passes with validity windows) automatically grant and revoke access at the appropriate times
Example mapping:
Pass NameDoorflow GroupPurpose
24/7 Access Pass24/7 MembersRound-the-clock building access
Business Hours PassBusiness HoursAccess only during operating hours
Meeting Room PassMeeting RoomsAccess to meeting room zones
Plans are not directly mapped to groups. Instead:
  1. Plans include passes via the plan configuration
  2. Passes are what get mapped to Doorflow groups
  3. When a customer starts a contract on a plan, they receive the passes included in that plan
  4. Those passes then grant the associated Doorflow access

Step 6: Map Resources to Groups

Resources (meeting rooms, event spaces, etc.) can require specific access permissions for bookings.
  1. In the Resources section, you’ll see all resources configured for this location
  2. For each resource, select a Doorflow access group from the dropdown
  3. Leave blank if resource bookings should not grant physical access
How it works:
  • When a customer books a resource, Nexudus grants them access 15 minutes before the booking starts
  • Access is automatically revoked when the booking ends
  • If the booking is cancelled, access is removed immediately
Example mapping:
Resource NameDoorflow GroupPurpose
Conference Room AMeeting Room AAccess to specific meeting room
Event SpaceEvent HallAccess to event space for bookings
Private OfficePrivate OfficesAccess to private office area
Resource-based access is temporary and booking-specific. A customer only receives access during their booking window, even if they don’t hold a general access pass.

Step 7: Map Desks/Units to Groups

Floor plan desks and units can grant access to specific areas when included in a customer’s contract.
  1. In the Desks / Offices section, you’ll see all desks from your floor plans
  2. For each desk, select a Doorflow access group from the dropdown
  3. Leave blank if desk assignments should not grant physical access
How it works:
  • When a desk is added to a customer’s contract, they receive access to the mapped group
  • Access is granted when the contract starts and revoked when it ends
  • Team billing support: If a customer uses team billing (merged billing), they also receive access to desks included in the paying member’s contracts
Example mapping:
Desk/Unit NameDoorflow GroupPurpose
Private Office #101Private Office Floor 1Access to first-floor private office area
Dedicated Desk Zone ADesk Area AAccess to dedicated desk zone A
Studio #5Studio AccessAccess to individual studio unit
Desk access is based on contract assignments, not direct desk bookings. Customers must have the desk included in an active contract to receive access. Ad-hoc desk bookings (if using desk booking) do not automatically grant Doorflow access.

Step 8: Save Configuration

  1. Review all mappings to ensure they’re correct
  2. Click Save to apply the configuration
  3. Nexudus will immediately start provisioning access for customers based on the new mappings

How Access is Managed

When Access is Granted

Nexudus automatically grants Doorflow access when:
  1. Contract starts: Customer begins a contract on a plan → receives passes included in that plan → assigned to corresponding Doorflow groups
  2. Pass activated: Customer receives a pass directly (not via a contract) → assigned to the mapped Doorflow group
  3. Booking created: Customer books a resource → granted access to resource’s group 15 minutes before booking start time
  4. Desk added to contract: Desk is added to an active contract → customer receives access to the desk’s mapped group
  5. Booking guest added: Non-customer is added as a guest on a booking → granted access to resource’s group for the booking duration

When Access is Revoked

Nexudus automatically revokes Doorflow access when:
  1. Contract ends or cancelled: Customer loses passes from that contract → removed from corresponding Doorflow groups
  2. Pass expires: Pass validity ends or usage is consumed → removed from mapped Doorflow group
  3. Booking ends or cancelled: Booking time expires or is cancelled → access to resource’s group is removed
  4. Desk removed from contract: Desk is removed from contract → access to desk’s group is revoked
  5. Customer deactivated: Customer account is deactivated → all Doorflow access removed
  6. Check-in expires: If customer checks out or check-in expires, certain temporary access may be revoked

Access Update Timing

  • Immediate updates: Contract changes, pass assignments, and customer deactivations trigger access updates within seconds
  • Debouncing: Rapid changes to the same customer are batched together (5-second delay) to prevent excessive API calls
  • Booking lead time: Booking access is granted 15 minutes before the booking start time
  • Background processing: Access updates are queued in background jobs to handle high volumes efficiently
  • Event processing: Door events are synced every 12 minutes for check-in tracking
If a customer should have access but doesn’t, the system automatically retries access provisioning. Check the Business Checkup page for any integration errors.

RFID Card Management

Doorflow supports traditional RFID access cards with optional PIN code support. To assign cards to customers:
  1. Go to Operations > Customers
  2. Select the customer
  3. In their profile, enter card IDs in the Access Card ID field
  4. Separate multiple cards with commas: 123456,789012,345678 (up to 4 cards)
  5. Optionally, set a PIN code in the Access PIN Code field
  6. Save the customer profile
Card behavior:
  • No card: Person exists in Doorflow but cannot unlock doors (no physical credentials)
  • Card assigned: Customer can use physical RFID card to unlock doors
  • PIN code set: Customer can use card + PIN for enhanced security
  • Card removed: Physical access is revoked (person record remains in system)
Card numbering:
  • Only numeric card IDs are supported
  • Non-numeric cards are automatically filtered out
  • Cards are stored in the Doorflow person record
Unlike cloud-based systems like ACT365 that support mobile access via the Nexudus Passport app, Doorflow requires physical RFID cards or PIN codes. Customers cannot unlock doors remotely.

Troubleshooting

Possible causes:
  1. Pass not mapped: The passes included in the customer’s plan are not mapped to any Doorflow groups
    • Solution: Go to Settings > Integrations > Doorflow and select a group for the relevant passes
  2. Group no longer exists: The selected group was deleted from Doorflow
    • Solution: Select a different group or recreate the group in Doorflow, then reconnect the integration
  3. Pass expired or inactive: The customer’s pass has expired or hasn’t started yet
    • Solution: Check the customer’s passes under their profile to verify validity windows
  4. Person not created: The customer wasn’t created in Doorflow
    • Solution: Check the Business Checkup page for integration errors, or manually trigger an update by editing and saving the customer’s profile
  5. Group permissions: The Doorflow group exists but isn’t assigned to any doors
    • Solution: In Doorflow, verify the group includes the correct door controllers
  6. No card assigned: Customer exists in Doorflow but has no physical credentials
    • Solution: Assign an RFID card in the customer’s Access Card ID field
  7. Wrong site selected: The customer’s passes are mapped to groups in a different Doorflow site
    • Solution: Verify you’ve selected the correct site in the configuration
Possible causes:
  1. Resource not mapped: The booked resource is not mapped to a Doorflow group
    • Solution: Map the resource to a group in Settings > Integrations > Doorflow
  2. Booking too far in future: Access is only granted 15 minutes before booking start time
    • Solution: Wait until booking is within 15 minutes of start time
  3. Booking not confirmed: Some resources require booking confirmation
    • Solution: Confirm the booking if it’s in pending state
  4. Wrong site: Resource is mapped to a group in a different Doorflow site
    • Solution: Ensure resource is mapped to a group in the correct site
Possible causes:
  1. Controller action not configured: Door controller is set to “Nothing” instead of a check-in action
    • Solution: Configure the controller action in Settings > Integrations > Doorflow
  2. Wrong site selected for check-ins: The “Check in customers at” setting points to a different site
    • Solution: Ensure the correct site is selected for check-in tracking
  3. Sync delay: Background task runs every 12 minutes
    • Solution: Wait up to 12 minutes for the next event sync cycle
  4. Event processing disabled: Background processing may be temporarily paused
    • Solution: Wait for the next sync cycle or check server status
Possible causes:
  1. OAuth2 authorization failed: You denied permission or the authorization expired
    • Solution: Click Disconnect, then Connect again to restart the OAuth2 flow
  2. Doorflow account access: Your Doorflow account doesn’t have admin permissions
    • Solution: Ensure you’re signing in with an administrator account
  3. Network connectivity: Unable to reach Doorflow API servers
    • Solution: Check your internet connection and try again
  4. Authorization revoked in Doorflow: You manually revoked Nexudus access in Doorflow settings
    • Solution: Reconnect the integration from Nexudus
Possible causes:
  1. Site not selected: You haven’t selected a Doorflow site from the dropdown
    • Solution: Select your site from the “Doorflow site” dropdown
  2. No controllers or groups: The selected site has no controllers or groups configured
    • Solution: Configure controllers and groups in Doorflow, then refresh the integration
  3. Connection lost: OAuth2 token expired or was revoked
    • Solution: Disconnect and reconnect the integration
Possible causes:
  1. Email already exists in Doorflow: Another person in Doorflow already uses this email
    • Solution: Nexudus will automatically use a unique email (no-reply+doorflow_{customerId}@nexudus.com) to avoid conflicts
  2. Company and individual records: Customer has both company and individual records with the same email
    • Solution: Nexudus automatically prioritizes the individual record and skips company records

Monitoring Integration Errors

Nexudus monitors your access control integration and alerts you to any issues that need attention.

Business Checkup Dashboard

Access control integration errors are displayed on the Business Checkup page:
  1. Go to Home > Important Items in the dashboard, or
  2. Navigate directly to dashboard.nexudus.com/dashboards/checkup
  3. Look for the Access Control Integration tile
  4. If there are errors, the tile will be displayed in red

What Gets Flagged

  • Authentication failures: OAuth2 token expired or invalid
  • Provisioning errors: Failed attempts to create or update customer access
  • Configuration issues: Missing or invalid group mappings
  • Synchronization problems: Delays or failures in updating access permissions
  • API rate limiting: Too many requests to Doorflow API (30 requests per minute limit)
Each error includes:
  • The customer affected
  • The nature of the problem
  • When the error occurred
  • Suggested actions to resolve it
Nexudus automatically retries failed operations with exponential backoff. If errors persist, check the Business Checkup page for detailed information and follow the suggested resolution steps.

Security Considerations

Data Shared with Doorflow

When provisioning access, Nexudus shares the following information with Doorflow:
  • Customer data: First name, last name, email address, mobile phone
  • System ID: Nexudus customer ID prefixed with “NX” (used to link records between systems)
  • RFID cards: Card IDs from the Access Card ID field
  • PIN codes: Access PIN codes if configured
Nexudus does not share:
  • Billing information
  • Payment details
  • Contract specifics (only group assignments)
  • Personal notes or custom fields

External ID Management

  • Customers: SystemId set to NX{coworkerId} (e.g., NX12345)
  • Lookup: People are retrieved via system ID to prevent duplicates
  • Email conflicts: If email already exists in Doorflow, Nexudus uses no-reply+doorflow_{coworkerId}@nexudus.com

API Rate Limiting

  • Rate limit: 30 requests per minute per username
  • Distributed locking: Prevents concurrent updates to the same customer across multiple servers
  • Debouncing: Multiple rapid changes to a customer are batched together (5-second delay)
  • Background processing: Updates are queued to avoid overwhelming the Doorflow API

Best Practices

Group Organization

Create groups based on access levels, not products or plans:
  • Good: “24/7 Access”, “Business Hours”, “Meeting Rooms”, “Private Offices”
  • Avoid: “Hot Desk Plan”, “Dedicated Desk Plan” (these are billing products, not access types)
This approach lets you grant the same physical access through multiple plans.

Multi-Site Management

If you have multiple Doorflow sites:
  • Configure passes, resources, and desks separately for each site
  • Select the appropriate site before mapping inventory
  • Only one site can be monitored for check-in tracking at a time

Access Signature Tracking

  • Nexudus tracks an “access signature” for each customer (a hash of their group memberships)
  • Access updates are skipped if the signature hasn’t changed
  • This prevents unnecessary API calls and improves performance

Technical Details

API Architecture

  • Base URL: https://api.doorflow.com/api/3/ (OAuth2 version) or https://api.doorflow.com/api/2/ (Basic Auth version)
  • Authentication: OAuth2 Authorization Code flow (preferred) or Basic Authentication (legacy)
  • OAuth2 endpoints:
    • Authorization: https://admin.doorflow.com/oauth/authorize
    • Token: https://api.doorflow.com/oauth/token
  • Token type: Bearer token (OAuth2) or Basic Auth (username/password)
  • Rate limiting: 30 requests per minute per username (semaphore-based across multiple servers)
  • Scope: account.person.readonly account.person account.event.readonly account.site.readonly account.channel.readonly

Key Endpoints

  • People: /api/3/account/people (GET, POST, PUT, DELETE)
  • Groups: /api/3/account/groups (GET)
  • Sites: /api/3/account/sites (GET)
  • Controllers: /api/3/sites/{siteId}/channels (GET)
  • Events: /api/3/account/events?from={date}&limit=1000 (GET)
  • Person by System ID: /api/3/account/people?system_id={systemId} (GET)
  • Person by Email: /api/3/account/people?email={email} (GET)

Synchronization

  • Access updates: Debounced by 5 seconds per customer to batch rapid changes
  • Background task: Polls door events every 12 minutes for check-in tracking
  • Event query: Retrieves up to 1000 events from last sync date
  • Event limit: Maximum 1000 events per request
  • Distributed locking: Prevents race conditions in multi-server deployments (doorflow:coworker:{coworkerId})
  • User provisioning: Lazy creation on first inventory assignment
  • Person updates: Created/updated/deleted as inventory changes
  • Access signature hashing: Prevents unnecessary API calls when access hasn’t changed

External IDs

  • Customers: system_id set to NX{coworkerId} (e.g., NX12345)
  • Lookup: People retrieved via /api/3/account/people?system_id=NX{coworkerId}
  • Email conflicts: If email exists, fallback to no-reply+doorflow_{coworkerId}@nexudus.com

Person Model

{
  "id": 12345,
  "system_id": "NX67890",
  "first_name": "John",
  "last_name": "Doe",
  "email": "john@example.com",
  "mobile": "+1234567890",
  "groups": [1, 2, 3],
  "tokens": [
    {
      "number": "123456",
      "pin": "1234",
      "active_from": "2000-01-01",
      "active_until": "2500-01-01"
    }
  ]
}

RFID Card Management

  • Card ID field: Comma-separated numeric IDs in AccessCardID field (up to 4 cards)
  • Non-numeric cards: Automatically filtered out
  • No cards: Person exists in Doorflow but has no physical credentials
  • Card assignment: Tokens added to person record with validity dates

Business Settings Reference

SettingPurpose
DoorGuard.EnableIntegration enabled flag (“true”/“false”)
DoorGuard.ApiTokenAPI token for Basic Auth (legacy, V1 only)
DoorGuard.SpaceGroupIdLegacy setting (not used in V2)
Doorflow.CheckinSiteIdSite ID for check-in event processing
DoorGuard.Controller.Id_{doorId}.ActionCheck-in action per controller (Nothing/CheckIn/CheckOut/Toggle)
DoorGuard.LastEventDateLast processed event timestamp (ISO 8601)

OAuth2 Settings (App Config)

SettingPurpose
DoorFlow.ClientIdOAuth2 client ID
DoorFlow.SecretOAuth2 client secret
DoorFlow.CallbackUrlOAuth2 redirect URI

Contract-Based Desk Access

  • Desk access determined by active contracts: coworker.ActiveContracts().SelectMany(x => x.Desks)
  • Team billing support: Customer receives access to desks in paying member’s contracts
  • Multi-location organizations: Access groups managed per location
  • Desk mapping: Each desk mapped to a single group ID

Access Update Logic

  1. Passes: Active passes from contracts + shared passes from paying member
  2. Check-ins: Passes from open check-ins (maintains access during session)
  3. Bookings: Resources with bookings starting within 15 minutes
  4. Booking guests: Resources from bookings where customer is a visitor
  5. Desks: Desks from active contracts (own + team billing)
  6. Groups: Aggregated list of unique group IDs
  7. Person provisioning: Create/update person with aggregated groups
  8. Card status: Add/update tokens if cards exist

Event Processing

  • Event format: JSON array of event objects
  • Event date format: ISO 8601 (e.g., “2024-12-25T14:30:00Z”)
  • Event retention: Events processed from lastEventDate, limited to last 24 hours if gap > 1 day
  • Pagination: Results returned in batches of up to 1000
  • Check-in trigger: Only “open” events with matching controller configuration
  • Site filtering: Events filtered by Doorflow.CheckinSiteId setting

Error Handling

  • Authentication failures: OAuth2 tokens automatically refreshed
  • Provisioning errors: Automatic retry with exponential backoff (5 attempts, 60-second delays)
  • Business Checkup: Integration errors displayed on dashboard
  • Distributed locks: Prevent concurrent updates to same customer (doorflow:coworker:{coworkerId})
  • Rate limit handling: Requests queued with semaphore-based rate limiting

Background Jobs

  • Queue: doorflow (standard priority) or 1_critical (high priority)
  • Debouncing: 5-second debounce per customer to batch rapid changes
  • Retry policy: 5 attempts with 60-second delays between retries
  • Transaction scope: Each update runs in its own database transaction (read uncommitted isolation level)

Duplicate Email Handling

  • Primary lookup: By system ID (NX{coworkerId})
  • Secondary lookup: By email address
  • Conflict resolution: If email exists for different person, use no-reply+doorflow_{coworkerId}@nexudus.com
  • Company vs Individual: Individual records take precedence over company records

Company vs Individual Records

  • Check: If customer is a company and an individual record exists with same email
  • Behavior: Skip company record, schedule update for individual record instead
  • Delay: 5-second delay before processing individual record
  • Logging: Warning logged when company record is skipped